Back to the talks Previous by track: GNU Emacs Greader (Gnamù Reader) mode is the best Emacs mode in existence Next by track: Sunday opening remarks Track: General

Open session

Participants

Format: 74-min talk ; Q&A: BigBlueButton conference room Etherpad: https://pad.emacsconf.org/2025-open-mic
Etherpad: https://pad.emacsconf.org/2025-open-mic
Status: TO_INDEX_QA

Talk

Duration: 1:13:00 minutes

Q&A

Description

Discussion / notes

this is shoshin here I'm pretty sure, with links to various stuff of his https://cicadas.surf/~shoshin/ oh, also, shoshin spotted again here https://mathstodon.xyz/@shoshin@buzz.cicadas.surf
Q: What are some of the efforts going on to make more "modern UIs" in Emacs? By "modern UIs" I mean not just text-based. Kind of like webpages.
- I think quite a few talks on the dev track were concerned with that.
I ask because sometimes I get jealous of my VSCode / Cursor friends when I look at their screen and see all kinds of interactive content. Also in the future, if AI models start returning interactive outputs instead of just text then Emacs will be at a disadvantage because it won't be able to render them.
I encourge Emacs Carnival entries this month: https://curious.port111.com/2025/11/01/emacs-carnival-december-the-people.html
- I welcome your submission this month. Some of the most interesting people I've known are emacs people. I'm betting that's true for others too.

Transcript (unedited)

All right, so yes, we have a little bit of time while we are waiting for the dev track to finish, and we could just declare this as a break, or if anyone's got any interesting last-minute stuff, you can come and share it here, where Karthik is also hanging out. I think every time I read one of your long blog posts, Karthik, I'm like, mm, life goals. Someday I want to write something with nice diagrams and, you know, deep Emacs interestingness. I have not yet gotten the hang of even using avy to nearly the extent that you do. But yes, I have, I have always looked at your diagrams very longingly and wondered how you make them. With a lot of sweat and cursing, unfortunately. It's all very nice. Yeah. And I, I, I've seen your interactive SVGs, which is just wizardry. I have no idea how you do that. You can hover over different elements in the SVG and do interesting things. Yeah, so it turns out if you just think of them as XML, which Emacs will let you because you can just control C, control C, and it'll switch back to text mode, right? Then you can be like, oh, yeah, I can work with this using the DOM Emacs list library. And then you can add title elements to it to get the hovers, or you can add hyperlinks. So in fact, the emacs-conf schedule is very naturally generated from emacs-lisp itself, because there was no way I was going to handle two track schedules by hand. And that's just SVG so that you can then have the hovers. The important thing is that when you're exporting it to HTML, it has to be an inline SVG to get the fancy behaviors. If you're linking it in as an image, then it doesn't work. It has to be inline. So for example, for my org mode, I have my exports for images checked first if it's an SVG. And unless I have an attribute on it that says, no, just link to it because it's large and not interactive, it actually inlines all of that markup into the exported HTML, if that makes sense. That does, that does make sense. It's a little less mysterious now. On the plus side, once it is in there as inline HTML, well, inline, you know, it's an inline markup, you can actually play around with it using JavaScript or CSS. That's really neat. I had a question about some other SVG wizardry I've seen you do. You have these SVGs that grow, right? Like they accumulate elements, almost like a slideshow. Am I remembering that correctly? Yeah, yeah, yeah. I started using that for one of the EmacsConf presentations. Well, the one EmacsConf presentation I've done in recent history, because it's nice to be able to add things gradually, right? Especially as you're giving a presentation. And that's also done with Emacs Lisp. What I do is, first I make the image, and then in Inkscape, I can group together the elements that I want to appear at the same time. And then I can use Emacs to, I think I just changed the, I just add some CSS to them to make them dimmer. and you just iterate through the different groups in that level, and you write out the intermediate SVG files, and then you can use Inkscape to convert them into PNGs if you want, like images of each step that are in PNG format instead of SVG. But the basic idea is you group the elements together that you want in one step, and then you can manipulate it using the Emacs DOM.EL library, because it's just an XML document. So you can say, all right, hide everything or have everything visible and then remove the last one or something like that, you know, iterated. Show them one at a time and then write your resulting document object model to a new file each step. Do you have, that makes sense. So do you just write the e-list, like is this on a case-by-case basis? Like every time you need to do this, do you write fresh e-list to step through the SVG this way? Or do you have some kind of package or library to do this more? Let me go see if this is the one. It's probably just buried in my config. If I do it again, I'm sure I will find another thing that I've completely forgotten about and therefore have to recode or fix or whatever. But let me go see. Can you see my screen? Yep. OK. So, oh, yeah, yeah, this one. Nice, I remember that one. OK, so we get this SVG, and then this animateSVGPaths is just a function I have. It takes the file name. It makes an output there. It adds one path back at a time. And it just creates a lot of these numbered frames. So as you can see here, I'm just saying, OK, take the whole thing. And then I think, yeah, maybe I said it like, you know, take the whole thing, make everything transparent, and then one at a time, make them opaque and save that, save that to the frame, to the image. So this theoretically is a somewhat reusable function that takes the SVG and just fills the directory with it. What's the order in which it reveals things? Top to bottom or bottom to top, it's whatever the SVG has. And so if you're grouping things together, you can rearrange things in Inkscape. If you've given them IDs, which I have another function for in Emacs list that just highlights something and lets me put an ID for it, then you can rearrange them yourself by looking at the markup, I guess. Or I think I actually have some code also that will rearrange the path based on a list of IDs that I give it. and sequence so this one is animating one element at a time here um it's kind of like interesting effect but for larger things like for this one i can split this up into groups because i don't want to necessarily animate them letter by letter and that one Oh yes, this is the function that I have for identifying the paths and it highlights it and then it asks me for a name. And this is the one that reorders it. So I can say, this is the sequence that I want it animated in. And it will, yeah, good. So you don't actually need Inkscape at all, right? Because you have an elisp function that will let you assign the order interactively. Yeah, so if you're doing just all the elements one after the other, Inkscape is helpful for combining the different shapes, well, breaking it apart, because when I get the PDF and I convert it, it's like one big element that has a very complex path. And if I want to animate it element by element, I have to break it apart and then recombine it so that, you know, so that this O looks like it's hollow instead of like a circle. So there's a little bit of Inkscape cleaning up before then, but I really dislike the mouse heavy stuff of Inkscape for assigning IDs and things like that. I haven't quite gotten the hang of it. So this is what it looks like before you group the elements together and you combine paths, which is what you have to do Inkscape for, because I can't make sense of the numbers in Emacs someday. So just combine, combine, combine. But once it's there, I don't like having to set the ID in this object properties on the right side, because there's a lot of clicking. press escape and tab and tab, it's not reliable. So that's why I have this function and it lets me identify the paths and animate them from within Emacs, because Emacs is a text editor. Yeah, in name only, but anyway. So the groups, if you've already assigned groups in Inkscape, Then when you run it through this function in Emacs, you can assign an ordering to the groups, the order in which it will be revealed. Yeah. What I did was I gave it all IDs. So I gave each group an ID. And then when I have the ID, I can say, you know, maybe when I group it, I'm doing it in a bit of a haphazard way, not grouping the first thing first, and then the second thing, and the third thing. So it's a bit of a mess. And this one just resorts it by, I think, just looking everything up, storing it, and then putting it back in order. I probably have the code for this somewhere, and if it's not, it's in the source code. There should be a source. Yes, so this is an org source for this post, and if it's not in there, then it should be in my config, the definition of this function. We are to pass. Here we are. Yeah, there you go. So there, it just, it takes it, it looks for it, and it adds it to the first layer. Okay, you've just explained the magic, which makes it less magical, but also something I could try. Yeah, this is interesting. Yeah, S2G is surprisingly powerful. Yeah, I know. I know it can do a lot more than what we typically use it for. So you also had this feature where, I think you used CSS, where if you mouse over something in the SVG, something is highlighted in your webpage. Oh yeah, yeah, yeah. Like in the organizer's notebook. So I have a draft schedule here. Yeah, we've been doing all this stuff live, that schedule, where if you have, let's pick someone's talk. Oh, yeah, highlight. I think, oh, maybe it's the other way around. I need to put this stuff here first. Oh yeah, okay. So you'll notice here how if I add some JavaScript, it takes a look at what's in the URL. And if so, then it can highlight a specific thing using just, maybe CSS might be it. Actually, I think it's JavaScript setting the CSS style on it. But yeah, you can play around with CSS. See, this one has a slightly darker, slightly thicker background. So SVGs are great for that. And if you inspect it, which I don't think I have shared here, but if you inspect it, I will share my inspect. I have too many windows open, so I don't want to share my whole thing. But one of these, oh, I don't even know which, how do I find, okay, it's the developer tools window. Do I even have developer tools? Oh, I can't see it. OK. If you inspect the page on the developer thingy, then it will show the SVG element. Yeah. And unfortunately, I can't share it easily right now. Maybe just say inspect. Oh, this is actually, I think, how also the individual talks have current ones, right? So I just have this image over here, and then you just have that one, that specific talk styled differently. How did you generate this SVG, the one showing the schedule? Oh, okay, okay. Emacs. Book, book, book, book. Emacs publish, I think. Let me share it. Emacs conf pub. One of these windows. Okay, let's see. Slow down, look at all the windows. Okay, I'm just gonna share the whole screen. Screen two, no, screen one. All right, and okay. I think this is the one. Is it sharing my screen? It is not sharing my screen. I'm going to try this again. Okay. All right. So, the schedule. The schedule. This is the actual function that creates the SVG rectangles for the talks. Oops. My screen share ended. Let me do that again. All right, and as you can see, it's just a little bit of math for the X, the Y, we color it differently depending on whether I'm making the schedule for the public view. So we just, you know, do we do developer, development talk or general talk as colors, or if I want to color it for the backstage view, I can keep track of the talk's status. Anyway, so SDG track takes the track and all the talk information, and it makes all the little rectangles. And this is the thing that adds a little hover for the times and titles as well. So, Emacs's API for dealing with this is actually pretty good. Oh, and of course, I have a hook here that modifies it. You can just run through a different function, different functions to tweak it. So I could say, okay, color it in case my time constraints are, you know, not being met. And then I can paint about this somewhere. And the nice thing about this is it's actually, it's, you can, hang on a second, let me do this carefully. All right, here you go. It's super nice to be able to refer to it within Emacs itself because Emacs has SVG support. So this is, for example, the organizer view inside an org mode file. And it just has all those SVGs. It don't have the hover things, because it's just an image in it. But yeah, SVGs, Emacs, awesome. Oh, that's very cool. You're actually drawing the rectangles from scratch. It took a little bit of figuring out, especially since I realized I wanted horizontal on the wiki pages so that it fits on people's screens, but I wanted vertical in my organized review so that I don't have to keep tilting my head sideways. and this is the code for that. See, I'm just directly adding G nodes for groups or A nodes for the hyperlinks and rep as well. I think the SVG library also has functions for adding rectangles and things like that, but sometimes I vaguely remember sometimes you can't return the node that I'm expecting. So, it's okay to just use the DOM functions directly. And then the whole thing gets SVG printed afterwards. So I can just say SVG printed, and then it's good to go. Let me see. Actually, do I have SVG? Let's schedule for track SVG. It's a shame that you can't visually interact with parts of an SVG in Emacs the way you can in Emacs. Oh, some people have some interesting experiments with that. I haven't dug into it much, but people have figured out how to use the mouse events and then figure out what the, like there's LEC draw, right? So lecdraw is a package that lets you draw SVGs and you can drag things and whatever. So that's very cool. And there's also an org related package that lets you visualize your schedule as boxes. I'd like, yeah, that's a thing also. So people have experimented with mouse interaction and it's cool, but I haven't had the brain space to do that yet, but it would be nice. Yeah, you're right. I remember using easy draw and being surprised at what it can do. The only thing I think I discovered is that it ends up creating lots of new SVGs, kind of the way that you do when you show elements one by one, you are essentially creating one SVG for each state, one full SVG for each intermediate state of the presentation, let's say. That's kind of what ELEasyDraw does. And I thought that's not good for performance. And it is kind of on the slow side, if you compare it to like Inkscape or anything else. But yeah, what it can do is pretty amazing. you can dynamically modify an SVG object, and it will automatically get updated in Emacs, which is a technique that I use a lot in FFNS in subbed. So for example, if I have waveform show all in this, it will, like, it's very easy to just move one element, for example, or make an element larger or smaller. And that's the... It might be pretty efficient, I don't know, but I'm certainly not like writing it to disk each time and reloading it. Eric and I demoed in 2020 EmacsConf for Dungeon Mode Works, where we demonstrated, you know, showing parts of the map and then, you know, different characters have different abilities that show, that allow you to see different dungeon features. And then if your last character, you know, of that class or race dies, then you suddenly can't see secret doors or whatever anymore. And so just make that disappear between one turn and the next is just working with just simply update the SVG and there goes the screen. No, no, no bus, no bus. It's pretty awesome. So this is an example of how I'm using it to kind of show where we are in the, in the track. And then here's mouse, mouse interaction, right? I can change my timestamp right from there. Which is fine. So, I'm curious how this works exactly. To effect any kind of change in the SVG, you have to use the DOM library, right? Yes. Okay, so, but that means that it's going to be, anytime you make a change, it's going to read in the XML, convert it to an Elisp DOM, right? And then you modify that tree. Yeah, you keep the DOM, like, well, in this case, for example, I'm actually constructing it using Emacs list objects directly. If you were working with an external SVG, you would parse it first, yes, using XML parse file or something like that. and then you would have it in memory. When you insert the image, you insert the list document object model that you have, and then any changes you make to that document object model automatically get updated in the image somehow. Oh, that's fantastic. Yeah. Yeah. I'll show you the code. Yeah. So I was under the impression that there's a round trip to XML involved to do anything like to go from displayed to in-memory to in-memory modified back to display all around trip. Yeah. So let me see where's my thing that changes it. So when it's the time. It's probably some kind of hook that I'm listening to here. Playback position hook. Oh, it's this update current bar. All right, so what update current bar does is it moves the bar to the right place. And you see here how this SVG, I'm actually just reading it off the text property so that I know which one is the current one in the overlay. I remove the old one, just the element. I don't have to mess around with the image. I removed the old one for some reason, just to make sure, I guess. You can actually just update the attribute on it. Oh, I think this is just so that I don't have to worry about whether there is one or there isn't. And then I add a bar at the right position and then it makes that little animated sweeping thingy. So you see how I'm not recreating the SVG at this point. I'm just getting it from the overlay. Yeah, that's very interesting. I wonder what it's doing. what it's actually doing under the hood when you run SVG removal. Yeah, I don't know, too. I think it's RSVG is tied into the display engine, so to speak. Yeah, that it is. But RSVG, the library, can only deal with actual SVGs, right, like XML SVGs, but we're dealing with the ELISP DOM of an SVG. So the display engine can re-enter the LISP. I do know that the display engine can re-enter the LISP engine, so I think that may be the answer. Yeah, you can just SVG insert image the object itself. So here, for example, SVG create just creates, it actually just creates a DOM model. So this is Lisp, and it's not, it doesn't get printed to string representation or anything. And then you can SVG insert image, or you can set the display and, you know, and use pass it like as an SVG image. SVG image gives you an image object if you want to do the like the regular sort of display thingy. Actually, that one says it turns it into a string representation. Or at least maybe that's just how it gets retrained. Anyhow, some kind of magic happens, but I don't have to worry about it. It just stays on my side. Yeah, but I was thinking about it because I expect that if it's converting to XML all the time, every time you make a change, then that's going to be the bottleneck for any kind of heavy interactive SVG editing or modification in Emacs. The kind that ELEasyDraw does. But maybe if we make it compelling enough, then the folks upstream can say, all right, like the way that JSON got a lot faster. Who knows? Maybe we can get that to be faster too. Yeah. I see a lot of potential for better UIs in Emacs with using SVGs. Yeah. Nicolas Rougier has all those experiments, right? Yeah, but all of those, I think, are bound by the limitations of how deeply SVGs are embedded in the display engine, because that's kind of what we're discussing. We want to avoid going to XML, I mean, going from XML to Elisp DOM to modified Elisp DOM back to XML. We want to avoid that round trip. Yeah, for sure. Or make that as fast as possible, yeah. Does anyone else have anything they want to share? I've always got stuff I can share, but I pretty happily defer. I've already seen what I made. Karthik? Oh, I'm a fly on a wall here. I'm not. Okay. I didn't come in with the intent to share anything. Yeah. How about you, Sacha? Do you have other stuff you haven't shown off recently? Aside from all the panicking about getting EmacsConf together this year? I just wanted to bring it up. Yeah, let's see, what do I have in my recent, like, fiddled with? So I have a project called... I have a project called Ufta, which is a little bit fun. Let me pull it up here before I share. You can see my messy, messy desktop. Okay, there it is. And that's supposed to want a shell. Probably that one. And we'll just bootroot. keeping in mind that graphics is going to end in about five minutes. Ooh, perfect. That'll keep me from from being my normal long-winded self. Have you already made contact with Emmanuel? I was not. Okay, I'm going to quickly do a check in. Okay, sounds good. Did you hear back from him? Assume that's a yes. All right, I'll go ahead and share screen here and just take a look, a very brief look at this. Assuming I can present. I had a question for Sacha. I had a question for Sacha and you, Corbin. Hello. Yeah, you're good. Go for it. Yeah, yeah. So in past years, in the EmacsConf, there was a talk by someone, usually John Wheatley, or I think Philip last year, about new developments in Emacs. Yes, and that is kind of at the whim of the Emacs developers, whether that is included in the in the conference. It's kind of up to the, you know, how busy folks are and whether somebody can follow up the time to prepare it. I see. Yeah, I noticed that there wasn't one for this year. And I know of at least one improvement or one change to Emacs. It's small, but I'm guessing it's very crucial for a certain class of Emacs users. And I can talk about that, just that one thing. But you can, you can, you can go right. So I can't share anything and we've got about one minute. So have that. Okay. Um, so the change is that, uh, in the development version of Emacs, sorry, child frames are now supported in terminal in the terminal. And I suspect that not many people know about it yet, but basically this means something like Corfu is going to work fine when you're running Emacs in a terminal, as well as pause frames or anything that shows like a little pop-up window that previously did not work in Terminal Emacs. That's it. That's the update. Cool. Okay, there I have a share screen button. We'll see if I think we're just about to cut away, but I'll go ahead and see if I can get this going. I'll just share my whole screen and this will be a little ugly as it comes in. So this is a project that I think is a little bit fun. It's called Oopda. And basically what this does, you can see it on my source site, that's sr.ht tilde mplscorewin slash Oopda. O-F-D-A, and this is a very simple approach to using an org file as a replacement for SQLite. It's very simple, but it does support like a dot style path and notation. So you can get at deeply nested data and just gives a little, there's a shell script wrapper that comes with it. All right. Theoretically, this is the Q&A for the graphics talk. Oops, I have to unmute over here. Sorry. All right, I had a little audio bleed through, my apologies, can you still hear me? All right, I'm gonna guess, because I still see us live on the screen that we're still live. All right, so I'll just press on. So what we're looking at here is a project called Upta. Here's the Emacs Lisp source port. You can see it's not real impressive even with all of its boilerplate. It's under 200 lines of code. And this is kind of a proof of concept, giving us the ability to use a org.org file as a flat file database. The intention here is to get a kind of transition from SQLite, which is using a flat text file as a database, to being able to have more of a literate database where we can intermix documentation about the data with the data itself, and then by giving a path on the command line. I'll go back to the README, just take a look at that. And you can see there's a couple of kind of examples here where we're, here we would be querying a path. We can also provide a value and that'll set data into the file. It also has an optional first parameter to specify the specific org file by default. It looks for a file called data.org. And of course that can be used inside Emacs as well, although the value of that may be a little bit limited compared to more sophisticated technologies like org-element. This is not an implementation that mirrors all of org-element or any of the more complex functionality of org. It's really as simple as possible proof of concept to just to be able to kind of work with the data inside an org file and get it back out on the command line. So we'll see if we can make it work here. Corwin, could you increase the font size? I surely will. All right. How's that? That's my picture. Yeah. Okay. Cool. So, let's see if we do have a, well, we can probably make it. Let's do this. All right, and then in theory, this just works. So we'll cut. So we'll just create a data file called data.org. Make sure that works. Looks reasonable. Let's try adding some data to it. Hmm, not so happy. Okay, let's try it the hard way. I'll come back over here to my usage and we'll just try running it. Is Emacs, is finding Emacs really the issue? It seems to me it's not, it's not liking my path. It's not finding out that I do EO and PWD. It wants it to be on the log. I see. So I may have to even mess with that further, but we'll just try it. So this should retrieve the value if it works. Oh, and let's take a take a simple Yeah, add-to-list takes a symbol. We're going to have issues with bash quoting, so you should escape the quoting side. Gotcha. You're kidding. I'm not letting go. Whoa. That might work. I got my parents right. Never demo live. How exciting. OK. Without batch, though, we may not get our output. OK. Well, that's as far as I'm going to take it. I should have prepped a demo environment. I wasn't really prepared to demo. No worries. Couple of questions about this feature. The first question is, do you use it? I do use it, yeah. I should have gotten onto the environment where I'm using it. It's a little messy. It gets into another project that's way too complicated to get into. Yeah, but what kinds of things do you use it for? It's sort of hard to answer that without getting into my other project, but essentially I've got a web development tool chain that is kind of a web-based REPL that is kind of a literate compute environment, if you will, allowing me to use a bunch of virtual machines as one big computer. That project is called Ghost Wheel. And so in order to show off the homepage, So on this page, you can see the list of machines, and then you'll also see there's these state indicators. And right now, as a matter of fact, what I've been hacking on is trying to get support for org tables. Right now, I support only changing all of the data within some heading, subheading, or whatever. What I'd like to be able to do is specify, using org table fm syntax, the particular row column. So find a particular named table, find a particular row, you know, column one, you know, row two, column one, and then set the value from the command. Currently, I just use it for very simple stuff. I don't really want to show that off. I've got another page that lists all of the DNS names that are associated that are hosted on Ghostwheel. And so I use that to add items to the list. Does it make sense? Yeah, it sounds useful. So one thing that I would like, I guess it's easy enough to write, but is a tool exactly like this where I can query my org files from the command line? Yeah, that's exactly what it says. Yeah, but it's going to be more like a database query where, you know, I say select, select all headings where, you know, that contain this string or that have this tag, right? The kinds of things that you can do with org-ql from outside, from inside Emacs, right? To be able to do those from the command line with, I'm going to invoke SQL here, like SQL SELECT statements, but it doesn't have to be that syntax, right? Just that capability. Yeah, I can see that being useful as a command line tool. And I don't even care about write, like the ability to write or manipulate the file. Just query. the command line that sounds yeah yeah exactly to be able to dig a piece of data out of an org file as well for my purpose it's very useful to be able to replace it because then i can deal with submit the form you know and that might be like a sign up form and then i just add the user add up an entry into the org file for that user right what it doesn't do is a relational data So everything, it's essentially a document data store. Like a Mongo kind of. True. So over on IRC, ScrewLisp asks, what does it mean to query an ARC file? Is the data in a table? Is it in an ELISP nested list view of a table that has a name in ARC? And my answer to that is that if you ever used RQL, written by Alpha Papa, then that's the kind of thing I'm talking about. So, you query based on one of a set of attributes. And these attributes are anything that's recognized by ARC. For example, the to-do status, the dates, the outline path, the headings, a full text search. There are several more. The presence or absence of certain properties. using any combination of those if you want to dig down and find some data in an art file. That's the kind of query I'm talking about. It is somewhat equivalent to being able to write SQL queries where you match on things just for your art files. Okay. I think we might have figured out our problem. It was DOS encoding. See if that works. I switched the development track over to just watching the gen track since I couldn't find it. Also, Eludo wants to mention the Emacs Carnival theme for December. Yes, the people of Emacs, of which you are all very awesome. Thank you so much for your patience. Today has been very interesting. But yes, at some point we can show that too. And we can basically wrap up anytime we like or hang out for as much time as we like also. okay so this is okay at least i got as far as a working demo here so now you can kind of see what's going on um and i'll just wrap that into uh into a little prettier output And you can see that it modified the value. So it's pretty darn simple. Again, all it's doing is completely replacing all of this content with whatever new value is given as its final argument after naming the data path. So the one refinement we can do just to get a little more complex example going. We'll deepen our structure a little bit. And try that. So here now we'll say test two. And we can take a look at the data file and see that it has adjusted that because test2 was completely unique, that worked fine. If that were not the case, we would have had to specify the path using dot notation like this. And that's pretty much it. It took me much longer to figure out why it wasn't just working than it did to demo it. And again, what I really like about this program, besides the fact that I find it quite useful to just be able to stuff values into an org file from the command line using shell script, is what I really like about this is that it's a whopping 190 lines of code, including all the boilerplate. And I will share the project into the chat. So, Corwin, you're not using org-element for this, are you? No. Yeah, that's a great question. Let's just dig a little into the code here. Or maybe it would be more fun to actually So the only real requires here, I do use cl-lib mostly. I'm directly using the macros from org. Particularly, I'm extremely fond of this function. I'd love to see this just promoted to promoted somewhere deeper into Emacs proper, so that I don't have to load all of the org macros to get to this particularly useful one, which just tells me whether ignoring whitespace a string has any characters, has greater than zero length. Isn't that just string blank B? So this is a little different. This deals with... I may struggle to remember the details, and it's possible that the non-org specific version has even been improved or I didn't use it correctly, but I believe my experience was it didn't handle new lines, for example, quite the same way. So getting into what this actually does, most of the program is finding the relevant part of the file. You'll see that we start out by doing a depth-based search, capture the value that we're looking for. And then finally, we widen the buffer and keep handling the case where we might be being called from within Emacs in a narrowed buffer. This is another what should be documented at the top. So that is obviously going to load org. Just double-check that. Yeah, it is going to load org. And we can see that because it didn't find the function. until I loaded Org and then it did when I did C-h f to get definition of a function. So, widen the buffer and then I just start looking for the search. You can see I'm doing simple regular expression based searches here. Looking for lines, ultimately, that start with a star. That was a little simpler format that didn't quite work out. So I'm searching for, here this is a little tricky, but I'm searching for a number of stars equal to the depth that I want. The depth that I want being calculated based on the number of dots that were in the query string. from there, you know, kind of skipping some stuff, right? Once we find our starting position, then we're going to have to find the end of that, the section that we're going to read or replace. Text a tiny bit smaller. So I checked org-string nwp, and it's the same as string blank p. exactly the same code or the same result? No, it's the same result. Well, it's the same check, but string blank p will return a match object, like a string match object, whereas the org version will return the string itself if it finds a match, as in if it's blank. I don't remember that. As a Boolean check, they are the same. If you use it as, you know, is it blank or not. So, um, yeah, I've talked for way longer. I thought I literally thought this would be a five minute thing. I'm not sure if there are any questions on it, but just to simply answer your question. No, it doesn't use org element. This is pure regex based work. So, the advantage of not using... Right. So, the advantage of not using arg element is that you don't have to load arg or arg element, right? And so, it's going to be faster. And it's going to be faster both because you don't have to load arg element and because you don't have to run arg element, like the arg parser. But on the other hand, you end up loading all of org anyway. So at that point, it might just be better to use org element because it's more robust. For example, if you have a bunch of leading stars inside a source block or something, you don't want to misclassify that. Matter of fact, I believe I had to do some flossing with it to deal with not just that, but drawers and things like that. right yeah so at the end of the day that was just an extra 10 or 20 characters in the regular expression so i just shrugged and wrote them you can see there are a number of i i happen to like writing regular expressions and find them relatively readable so So it didn't bother me doing that. I've also done a bunch of work with org-element with the dungeon project, which of course uses that extensively to pull data out of tables and so on. And indeed, I think that may ultimately be my solution. I've been kind of distracted on a side quest to improve the org-table-fm parser. There's a post on my blog about the work that I've done there, and recently started talking to Ihor, the new org maintainer, who took over in the last year or so from Bastien. Just about what it would take to pick that up, or at least get it to a point where somebody else could work on it. It's pretty dense right now. So this thing is a bit of a monster, but at the end of the day, our goal is to extend the syntax, is to be able to use this Org Table FM syntax in other contexts. So if you haven't looked at board table FM, these I bar or these I markers are telling us to look for the table separator. So positioning based on the location of a table separator. I find that a little bit brittle just because it's really easy to go in and decide, oh, it'll look better with an additional line separator in there. And then all of these formulas break everywhere. So it would be a little more fun to have at least variables in there. And that's kind of part of the scope. If we look, and here you get kind of a hint of the new syntax I'd like to support, things like $star, $underscore. Keyword it's it's probably a half-hour talk just to get into what every single one of these would do But this post does does give some some context of that And more importantly there is a as a complete test program that Worked the last time I was playing with it And this gives you complete examples of all the syntax that the work in progress does currently support. You'll see some of these items are commented out. Those aren't supported yet and before I would implement them now, especially now that we're talking in terms of trying to take org itself this direction, you know, of kind of beefing up the the TableFM format parsing so that it could be used in other contexts besides specifically within a formula. I wouldn't want to add features to it without discussing those. So this is just a simple, basically a literate test file if you want to call it that. The perhaps key improvement here is naming all of the different capture groups. which just, if you're working with really huge regular expressions, which this is, let me just make sure the whole pagex is right in here so we can see it, yeah. So here's the actual rewrite, scale it a little bit, so you can see it's kind of a monster. And that's all using Rx. So hopefully that looks pretty familiar. Dollars for specifying a column, at sign to specify a row. And we also have the keys. Anybody else want to show and tell? We're going to cut over to the automated introduction for the Saturday closing remarks in like four minutes. Oh, but quick, quick, quick mention of the Emacs Carnival. So the Emacs Carnival is a shared blogging theme. where lots of people write about a specific theme, and then if you write about it, you can send your link to whoever's hosting the carnival. And it's a great way to discover other people's cool stuff. So if I take presenter, hang on a second, take presenter. Oh, actually, haha, I know, I'm going to make Elladom present it. Haha, you are now in charge. Okay, take it away. So I've been using Emacs for like 46 years now, back to TECO Emacs. And as I just said in the chat, I've found that the people who use Emacs tend to be interesting people in many different ways. And so this month, I'm just saying, let's give a shout out to some of the interesting people we've met along the way. And including some of the people that are putting on this conference are some of the most interesting and helpful people I've ever met. So thank you. You're very kind. Thank you. I'll say more than that. Maybe I will. I completely agree with you and I couldn't agree more. I think that's how Sacha and Amin and Leo really dragged me into this, you know, into being a volunteer. And I really, I'm sure we'll talk about this in the closing remarks, but I can't recommend volunteering for this project enough. It's just so fun to talk backstage with the presenters I don't know. It's an extremely engaging community. It's really thoughtful. I like the way y'all are so patient and awesome and I can be just quietly having my little freak out here and everyone's fine and will even help debug things live as needed. So this is all good. Anyway, so if people want to participate, you basically write a blog post. If you don't have a blog yet, there are any number of packages in Emacs, as well as web-based services, but really, you can get something going with Emacs. or exporting to HTML and maybe even figure out RSS, or you can use a static site generator like Hugo, or you can find, if you can set up WordPress, that's another way to do it. Or you can email me your thing and I'll post it on my blog and let me know how you want to be credited for it. Anyway, so you can share your story or share your story about somebody else's story and celebrate Emacs community. And we can send it to George also. We'll then make links in that blog post. And on the subject of community, I also heartily recommend the IRC community on Emacs. Pound Emacs is another one of those things that I just personally can't get enough of, and I hear a lot of stories about just how it's helped people. All right, we are now having the automated introduction and then it's going to rejoin over here very soon. Hang on a second. Wow, that's going. Saturday close and let's arrange our screen nicely. All right, we made it to the end of the first day! Woohoo! Thank you for joining us for the first day of EmacsConf 2025. Feel free to spread the word because there is still another day of fun talks tomorrow. So hashtag EmacsConf and hashtag Emacs. If you do hashtag Emacs on Mastodon or Blue Sky or other places, we'll probably find it. Or if I don't, you can just let me know also. The prerecorded talks should be up on the talk pages already. The live talks, we'll probably actually get them up within the next week or two. I think they've already started processing, so I just had to sit down and then work with our wonderful army of volunteer captioners to get them all nicely captioned. But anyway, so the prerecorded talks are also up on YouTube, and I will eventually also upload them to ToobNix, which is a PeerTube instance. We will work on extracting live talks. If you'd like updates, please subscribe to the EmacsConf Discuss mailing list. If you've got ideas for making things better, we have so many ideas. I always end up with a very long to-do list after these things. Please add them to the pad. I'd love to hear from you on how we can make it even smoother next year. There are about 100 people watching in gen and 100 people watching in devs, which is really awesome. It's amazing to think that we can have an Emacs party for a lot of people. And we can only do this because of all the wonderful speakers, volunteers, participants, and very patient people in our lives who make it possible through all the time and support. So this year, Corwin did most of the hosting. I mean, also dropped by earlier, so that's great. I hope Leo is okay. You know, we managed. And I'm Sasha, by the way. I was running around backstage and occasionally dropping in to go on the stream. There are lots of other volunteers who are not on air. So, for example, during the proposal review process, we got a lot of wonderful comments from J.C. Helary, Triko, and James Endres Howell, captions from Amitav and Rodion and other people have actually started also helping with the captions as well. So jay_bird just sent in some stuff today too. We are slowly working on getting a mirror in the EU set up so it'll be a little faster for people. So thanks to Yang3 for lending us a server. Babin and Michael and Ian and Jamie and Eeyore and Floyd Coulter have also helped out as well. Thanks to the Free Software Foundation for the mailing list, the media server, and of course, GNU Emacs itself, for which an astonishing amount of the scripting is done in Emacs. It's great. Thanks to Ry P for the server that we're using for OBS so that we can just VNC into it and I can manage two tracks without making my computer melt. It's great. And of course, to all the users and contributors and project teams that work on all the free software that this stuff is built on. Emacs, Org Mode, ERC, Tramp, Magit, BigBlueButton, Etherpad, IkiWiki, IceCast, OBS, The Lounge, LiberaChat, FFmpeg, OpenAI Whisper, WhisperX, the Aeneas forced alignment tool, PsiTransfer, SubEd, SubSeg, Mozilla Firefox, MPV, and Tampermonkey, and other things I probably forgot to mention. Thanks to Shoshin for the music, and thanks to people also who've donated through the Working Together program, like Scott and Jonathan and other anonymous donors. So that's a quick thanks. There's more tomorrow, but Corwin, do you have any parting words? You know, my parting words, Sacha are a thanks to you and not just a thanks for the hundreds of hours that you put into preparing this conference, you know, over the years and probably just this year, but also for all that you do for the community you are. You are a real unsung hero, even though I do hear your praises sung. They really can't be sung enough. In fact, I just this last week recommended to two different people your blog as a place to get a first introduction to Emacs. Your Emacs news is an incredible contribution, and just I want you to hear us thanking you. Thank you, Sacha. Emacs is a lot of fun, and Emacs people are a lot of fun, so it's all very wonderful. Yeah, we can wrap up here. People can keep hanging out if they want. I have a kiddo who is probably going to be back home soon and will pounce on me for more hugs, so I will see y'all tomorrow. uh, for more probably the same kind of stuff. Shut it down, save our energy for tomorrow. Uh, we do like to run into like hours long closing tomorrow. So we'll work on resisting that. Um, I suggest we, we look, we go get some rest and come, come back at it fresh tomorrow. Anybody else, any concerns with that or shall we go for it? Sounds good to me. If you've got ideas, pop them into the etherpad. And thank you so much for sharing this time with us. See you tomorrow.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org

Back to the talks Previous by track: GNU Emacs Greader (Gnamù Reader) mode is the best Emacs mode in existence Next by track: Sunday opening remarks Track: General