Leo? I'm doing well as well and I'm so happy to have seen your
talk because the interaction with Emacs is always
something that I find very interesting, and stuff like
Transient, stuff like Hydra before, I think they really
improve the user experience of users, and I'm really glad
that I've seen you talk. Perhaps just starting with the
first question, do you have anything else that you'd like to
add on your talk? Because we are pretty stringent with the
amount of time that we give for talks, but is there anything
that you would have liked to mention to people that you
weren't able to fit into the talk? I think probably one of the
design considerations I've done is that many of the
commands that I've exposed through my casual interfaces
have been in Emacs. They've been in there forever, but very
few people uh, myself included really know that they're
there, uh, because they're just not discoverable through,
uh, basically the existing mechanisms, you know, prior to
transient and which key to, to even know that those, those
functions are there. Yeah. So I think I'm going to start
asking you questions whilst people start writing them in a
pad. But yeah, I also think that discoverability is a very
huge point that having stuff like the stuff that you've
showed today actually allows. One example that I'd like to
give that many people tend to forget, and you've already
mentioned it in your presentation, is that I've learned so
much about using git in general thanks to maggots for the
reason that it shows you so many options that you might not be
aware of for instance like i like to really think about when
you think about logging in git maggots allows you to
discover so many of the finer options like oh I only want to
see the first comet since the merge or oh I only want to
consider this subsection of comets going from master or
main to the point of your branch. So many things like this
that you get to discover thanks to Transient. So do you have
any similar experience on your end? Uh, oh yeah, uh, far too
many. Uh, I think, uh, particularly with EditKit, uh, you
know, having access to these commands, uh, um,
particularly with different granularity on, like, uh, S
expressions, sentences, words, uh, probably the most
surprising thing I found was just how How compelling the S
expression would be as a unit of text for working with. I
found that in most contexts, or in many places, it did what I
wanted. I found that to be very surprising.
So unless you've got anything else to add, I think we can just
jump into questions. Okay, certainly. I'll be reading them
for you so that it's easier for you. So the first question is,
I wonder whether casual can only be used with the packages
you mentioned or whether it can be used with whatever
packages you like. I think it's really the latter. I'm not
quite sure what the... What the question was really
pointing at, you know, is the question asking for why I chose
the packages or the different modes that I did? Or is it, are
they looking at it from a developer perspective of, can we
integrate casual with other packages? I mean, since we've
got a little bit of time ahead of us, feel free to answer both
questions. Um, I think the answer is, uh. Well, for the 1st,
1, I've, I've generally tried to stick with using. The modes
that are already packaged in, um, and so there was a. A big
refactoring of it where. Initially, I made separate repos
for the different modes that I supported. And then through a
discussion, which I won't go into here, that got changed
where I consolidated all of the different transient menus
for modes that are built in for behavior that's built into
the Emacs. I put that into a single package called casual.
And then integrations with other third party packages that
are not built in were given the same standalone repo here. In
terms of folks wanting to integrate that, it's the beauty of
open source. They can get the repo and uh, and basically
study that the code base, uh, actually, if they even install
it through, uh, you know, the package manager in this case,
uh, coming from the Melbourne distribution, um, they can
inspect that code and, and, um, make modifications or even.
uh, you know, integrate that with their other packages and,
uh, do that to their heart's content. Um, I think one of the
things that I need to, or at least, uh, you know, that I, I, I
planned on sort of elaborating further on in the
documentation is, is that transient already has built in
mechanisms for modifying an existing transient. So you can
add commands or, uh, re redefine the bindings. And so. That
mechanism is available for users if they're not happy with
those bindings or they want to add their own commands to a
menu. Yeah, and people are... I'm personally familiar with
this, again, with Magit, because sometimes, even though
you have a lot of discoverability for functions that you may
not know, sometimes you also happen to realize that
something is missing in the list of available options. I'm
not sure if Casual actually supports something similar to
Magit, which is levels of options being displayed.
Actually, I'm not sure if it's transient native or if it's
just something that Magit adds over this. No, transient
supports levels. I've decided
in large part, I've tried to avoid that just to avoid the
added complexity of trying to define those levels. Yeah, I
was going to say that perhaps it doesn't gel very well with
the notion of casualness that you seem to be introducing the
package. On one end, you've got something that is supposed
to be very casual, very easy to use, and on the other end, you
add levels for stuff that is fairly advanced. So advanced
versus casual, kind of makes sense that you check this over.
Alright, moving to the second question which is related to
the previous one. Are there any patterns emerging such that
it would be impossible, sorry, such that it would be
possible to once systematize and to automate the mapping of
mode commands to keyboard-driven menus, possibly even
have an auto-casual wrapper for an uncovered mode? Does it
make sense to you? Yes, and I've gotten these comments from a
number of different folks who really want to see some sort
of design rule to, or basically, what is it? Some sort of
design system to be able to generate the UI.
Conceptually, I think it's doable, but on the flip side, it
just requires so much coordination that it makes it really
untenable. In this case, I have very strong opinions. I
think we're better off trying to handcraft the user
interface to get basically the best user experience. To try
to emulate that with a design system, good luck, but I'm not
I'm not interested in working on that. Right, yeah. I think
if I try to think a little more about this, it feels like
there's a notion of intention that is very important when
you are designing UI and UX. And to have this intention, it
feels like you cannot just base yourself of a design idea to
organize the options. You cannot just work off a pattern. I
think you need to have the trace of human understanding in
order to have a UX that really works. And judging by the
option that you've picked in the demos that you've showed
today, I don't think it'd be particularly easy to organize
them in a UX just casually for any mode. I think you need some
human introspection to understand this, if that makes
sense.
Moving to the next question, which is related to something
we discussed about with Magit. Does Casual have a log where
you can see what commands were invoked? This is always
available via MetaXView Lossage or via the Common Log mode,
but I'm wondering if it can do for Emacs command what Magit
Process Buffer does for learning Git commands. And for
everyone who's currently in Emacs, whenever you're
running a command in Magit, it's always printing the exact
command that was run in a shell, inside this dollar sign
menu. So does Casual actually provide something similar,
Charles? I don't know. In general, because I'm building off
of transient, it would have to be a mechanism that's
available through transient. And You know, I would let
Jonas speak more on that capability, because to be honest, I
mean, even to my knowledge of transient is not that deep,
actually.
Well, it's funny that you say this because even though you
say your knowledge might not be that big, you still managed
to develop a whole suite of tools on top of it. So as far as
people who do not know transient a whole lot, you're doing a
pretty damn good job. Let me tell you that much. Thank you.
Yeah, I think sort of what I bring to the table is, you know,
quite a considerable career in software development on
other software ecosystems. And as of late, I've spent
basically the past decade working on iOS apps. Right. I
think it's refreshing to be able to go back to something that
looks like Emacs after iOS.
Well, that's perhaps another longer conversation there.
Speaking of longer conversation, we have only about 10
minutes left until we need to move on to the next talk. But
thank you everyone for all the questions you're asking. I'm
not saying this because we finished, but it's good to see so
many people writing in the chat and asking questions. It
always shows that you're interested and that's always
lovely to us. And you've mentioned Jonas. Obviously, we're
talking about Jonas Bernoulli, i.e. Tarsius, the
maintainer of transient. And what Charles just mentioned
about having a transient tooling to print the lossage,
basically, of which sex were run by which command, feels
like this is something that would be interesting. So,
perhaps, I'm not sure if Tarsius is still on the chat
currently, but he was definitely around earlier today, so
we'll make sure that the ID lands on his lap later on. All
right, moving to the next question. Is there a setting to
close menu after executing a command? By default, it will.
There is a There's a slot that you can define in a transient
prefix called colon transient. And if you set that to true,
then it will persist the menu after executing the command.
But by default, it will actually dismiss the menu. This
feels... Did you actually get to play with Hydra before
playing with transients? To be honest, no. Yeah, I kind of
slept on Hydra or at least, you know, I really wasn't all that
ambitious with working with different packages until
about like, a little less than 2 years ago or so.
And then the other part was also, um. You know, not not really
a technical. Start a comparison because I really don't want
to upset folks here, but, uh. But more along the lines of just
going with the notion that transient was being built in or
packaged as a built in package for Emacs. I went with using
that for my implementation. Cool. And I don't think there's
anything controversial with what you're saying right now
because, you know, we had earlier today, Euro Rechenko, the
new maintainer of Augment, mentioning that he'd like to
have a better integration with Transient because
Transient is, it looks like it's here to stay for a long time
and might even land in core at some point. So, it definitely
feels comparing Hydra because for me, most of my UI needs in
Emacs prior to Transient were done via Hydra because it was a
very convenient tooling. For people who do not know, Hydra
is written by AboAbo. who's also authored packages like
Lispy, an interactive Lisp mode, also for Ivy, which you
might know as the counterpart of Helm, maybe five years ago.
So all those packages, they were very innovative for the
time and it's cool to see that some of the ideas which were
introduced by IV and Helm and all this are then taken by tools
like Transient and done perhaps with a little more
hindsight now that people have experienced a little more of
it. Okay, we have still a little bit of time. Moving on to the
next question. What modes are you working on at the moment
for Casual or are you excited to explore?
Well, so I just recently published one for calendar. And so I
think the calendar interface has a lot of really
interesting behavior, particularly its support for
non-Gregorian events, which is, you know, for folks who'd
like, in my case, looking at the lunar calendar, it's great
to have tooling to be able to not have to leave Emacs to figure
out when a lunar date is.
Then, I think, you know, for the most part, My work on casual
was really kind of my summer of code for Emacs here. And so in
many ways, the velocity of casual development is going to
slow down where I've got a big bulk of the modes that I really
wanted to take care of. Um, I think one experimental thing
that I think is very unbaked, but I would, you know, if folks
are interested, uh, maybe looking at it is, uh, taking a look
at edebug and trying to make that an easier thing to do. Um,
that is ambitious. Uh, yeah, so maybe too ambitious.
Uh, other things are like really scary projects. And so not
to say that I've, I really have a desire to do it, but another
one would be Edith. Right. Okay. Relitigating it's
interface, um, to have a transient menu. Um, but, um, I say
these things, but I'm also scared of those things. Yeah, I
mean, I think it's a lovely way to tackle the project,
really, because you are fully aware that edebug and ediffs
are mastodons when it comes to Emacs. They work very well. If
you've ever tried to do a conflict resolution in maggot and
you've pressed E, that usually opens edith for you and if you
happen to know how it works it's amazing but if you do not know
it works the interface is a little it's a it's a lot to take in
at the moment and you know you have to like know a b w I can, and I
can never remember which one is the lower and which one is the
upper. Like, it constantly goes in different directions. I
can never remember which is the commit I'm trying to merge,
which is the commit I'm currently being on. It has nothing to
do with the Git. It's merely Git and the way they conceive
this. And probably, there might be a very nice way to
remember it, but I still haven't found it after 10 years as a
software developer. So, I guess I need to dig a little
deeper. But what I find lovely about the approach is that for
you, working on the interface to those tools is actually
something that allows you to discover how they work, but
also how to make it more easy for people to understand how
those tools work. So you're doing the work of
understanding, of digesting a lot of the commands, so that
people do not have to go through the same pain as you have. So I
find this a very noble endeavor in a way. Uh, yeah, I, you
know, in so many ways, uh, as perhaps I've, uh, uh, mentioned
in my talk, um, I'm getting older. Uh, I, I can't remember all
these damn commands and my hand dexterity is failing. I
mean, there's so many. Like, you know, multiple keystroke
bindings, which I absolutely loathe. Um, you know, at most,
like I can, I can only physically handle like, you know, two
characters. uh, three, maybe right at a time. So maybe
that's, that's just me, but, and others, you know, may, may
feel differently, but at the same time, um, you know, the,
the work that I've invested here is, has been very personal
for me because I just don't want to work that hard and I want to
keep using Emacs. Yeah, and that's again a very good
endeavor, I think, to have. And there's one last thing that
I'd like to mention, because you've mentioned this project
of yours, Casual, being some kind of summer of code, with the
implication that you've worked a whole lot of it during the
summer or during this period. and perhaps investment will
die down a little bit now. But I think it's completely fine to
have moments when you feel particularly excited and you do a
lot of work, and sometimes it dies down a little bit.
Personally, I've been... Four years ago, I was working a lot
on Org Roam and I had my Summer of Code on Org Roam. And that was
great. I was able to do a lot of things, to get a lot of things
out of my head. But eventually, you know, you have to go make
some money to survive or you have to take care of family and
stuff like this. So, life tends to get in the way of your
hobbies, especially when, you know, it's so... It's
hobbies that involve so much of your time to get things
right, like programming does. But, you know, we appreciate
all the work you've done, Charles, and the fact that you've
put it out there for people to enjoy. It's already a victory.
You don't need to feel compelled to keep working on it
because ultimately, as you said, the beauty of open source
is that people can just send PRs and get the project going
again. Yeah. I mean, and if anything, you know, folks have
expressed to me that, you know, in many ways, a lot of this
stuff should be, you know, sort of folded in the core. And,
you know, I would love to see at least the ideals of, or at
least an openness into thinking, rethinking the interface
for Emacs. So, you know, it doesn't have to be, basically
work the way it worked for basically the last half of the 20th
century here. Yeah, Emacs is flexible enough to have
different approaches and, you know, transient is one
approach, but at the same time, you know, the ability to
reimagine the user interface for, you know, the computing
needs, you know, for basically users needs today, whether
you write or code or anything of that nature, I think is an
exciting and great thing. Yeah, well, thank you so much for
this conclusion. So I'm a little sorry, because sadly, we
needed to move the stream to the next talk. So we've lost
about 20 seconds of what you said. But don't worry, whatever
you've said will be available on the website. I didn't want
to interrupt, sadly, because I didn't want to be rude. But I
think we did a great job answering the questions. So thank
you so much for taking the time. I'll need to get going,
because we might have a problem with the next talk. So thank
you so much, Charles. Certainly. Take care. Thank you.
Appreciate it. Bye.