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 Macedon
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 TubeNix, 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. Hellery, Chico, and James Andrews-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,
PsyTransfer, 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.