00:00.000 introduction
00:43.800 Recall vs recognition
02:34.800 Emacs with keyboard-driven menus
03:43.400 Transient
04:08.200 A Transient menu can be pinned
04:29.303 Modes are apps, really
04:59.527 Transient all the modes!
05:28.040 Casual design principles
06:17.960 Casual design conventions
07:04.366 Casual Dired
09:06.640 Casual EditKit
10:36.200 EditKit demo
11:31.997 Marking and moving
12:53.140 Rectangles
14:04.976 Numbering
14:36.600 Sorting
17:02.640 Casual has transformed my user experience with Emacs
17:34.451 Thanks and acknowledgements
00:00.000 Opening
03:13.600 Q: I wonder whether casual can only be used with the packages you
07:10.854 Q: Are there any patterns emerging, such that it would seem possible to 1) systematize 2) automate(?) the mapping of mode commands to keyboard-driven menus? Possibly even have an auto casual wrapper for an uncovered mode?
09:19.606 Q: Does Casual have a log where you can see what commands were invoked?
12:00.204 Q: Is there a setting to close menu after executing command?
14:40.282 Q: What modes are you working on at the moment for casual / are excited to explore?
18:14.280 Getting older
To date, the predominant interaction model for Emacs has been to use keybindings or the mini-buffer prompt to issue commands. These commands are drawn from a vast ecosystem of packages (both core and third party) designed to extend Emacs. When these commands are used in aggregate, the aforementioned interaction model places a high cognitive load on the user. It also sets a very steep learning curve for Emacs.
The inclusion of the Transient model package in Emacs facilitates a different interaction model using keyboard-driven menu interfaces. Menu interfaces excel at discovery and recognition, neither of which are well supported with keybindings and a prompt. Menu interfaces also can be made contextual to allow the user to focus on a task at hand.
Casual Suite is a personal effort to re-imagine the Emacs user experience by using keyboard-driven Transient menus as its primary interaction model.
This talk describes Casual Suite, detailing its implementation and operation.
About the speaker:
Charles Choi has been an Emacs user since 1989 but did not get around to learning Elisp until 2022. He possesses formal knowledge of computers with a Ph.D. in Computer Engineering received from the University of Virginia in 1997. He is from and continues to live in San Francisco.
Discussion
Questions and answers
Q: I wonder whether casual can only be used with the packages you
mentioned or whether it can be used with whatever package you like?
e.g., can I use causal with AUCTeX?
A: More the latter; can the questioner clarify the question?
People are free to fork and iterate over casual
transient.el already has mechanism for modifying an existing
transient to redefine the bindings over the definition
Q: [related to the previous] Are there any patterns emerging, such
that it would seem possible to 1) systematize 2) automate(?) the
mapping of mode commands to keyboard-driven menus? Possibly even
have an auto casual wrapper for an uncovered mode?
A:
Q: Does Casual have a log where you can see what commands were
invoked? This is always available via M-x view-lossage or via
command-log-mode, but I\'m wondering if it can do for Emacs commands
what Magit\'s process buffer (\$) does for learning Git commands.
(Leo just spoke about this.)
A: That just works. (But try keycast-log-mode instead of
view-lossage.)
Q: Is there a setting to close menu after executing command?
A:
Q: What modes are you working on at the moment for casual / are excited to explore?
A:
Q: Why not improve which-key (which seems to be included in Emacs 30
by default) to accommodate for your very slight differences instead
of reinventing the same thing from scratch in an incompatible way?
\@majorgnu on YouTube: This is great! Emacs\'s plethora of powerful
functionality really needs a better way to surface itself to users
and this is a great step in that dirrection. I do have a few
thoughts, though:
Is there a convenient way for a user in a transient to get more
information about a menu entries? Specifically: the normal
keybindings (if available) and command documentation.
It could be useful to gather and display statistics about menu
usage. Imagine being able to generate a personalized keybinding
cheat sheet with the menu items you use the most!
Q: Is there a way to update a part of a transient menu?
A: menus can be refreshed
But that refreshes the whole menu
Okay, I thought so. I've been calling (transient-setup) in transient infixes where required, but occasionally it's slow. And in every case it throws away the values of all the other infixes that have been set
Notes and feedback
You can also use the menu from the keyboard with F10 and arrow keys. I turn the menu off, but I sometimes use it anyway with F10.
is that fvwm?
I disagree that searching for stuff in menus is easier than remembering commands. It's probably easier to learn, but not easier to use once you know them.
worst of all: searching in a hierarchical effing hamburger
Hamburger menus make sense on extremely small screens, not on other screens.
yeah, I don't think updates are that granular
2 hour Calc talk when?
I'm really wowed by your talk
this was such a great talk
I want casual support for more modes guess I need to do that, then
The enthusiasm around casual always surprises me, because all the stuff is documented and easy to find if you read the manual and use the help system
and can remember it all! with casual, you don't need to
(and in time, use will nail it into an aging memory)
I don't use casual, but the obvious problem with the manual/help system is that you still have to memorize it all
Even if it just means memorizing that it exists in the first place
yeah. I use org like a savage because I only need it a few times a month and I can only remember about 5% of its capabilities...
and I bet most people are like that for most modes they only use occasionally.
You can look a lot of commands up using apropos, you don't need to memorise everything?
But I also set transient-show-popup to nil
apropos is so clumsy compared to transient though
there's a nice benefit to having it there and callable by one more keystroke
but then I grew up with WordStar and have long missed its menu/keybinding stuff
Consider less commonly used commands like transpose-region or repunctuate-sentences. How would the user think to even look for commands that do these things? If they do remember, then they have to look up the keybindings every time they use them until it becomes muscle memory. For rarely used commands like these it might never become muscle memory.
But a question of mine is do you use and make use of transient-default-level?
There's a repunctuate-sentences?!
Case in point. if repunctuate-sentences was in the casual editkit menu on text operations there would be no discovery or memorization issue.
Yes, it is very useful when arguing for double-spacing.
oooh, useful! I'm a newbie though, only been using emacs since 1992 so of course I hadn't discovered that yet
in my case, overriding my single-space muscle memory when contributing to double-space-end GNU projects
that's a little like why I want some kind of embark/cmap thing too, so I can have friendly menus that are scoped to the type of thing at point
to the extent post-its still serve a function for much simpler things for most people, contextual surfacing of what's possible serves (and not the firehose, the select few) makes similar sense to me.
I want to push back on the point that Transient gives you discoverability for free. Perhaps I am too much of a zoomer, but a big menu with a lot of options is just too much information at once for me. The irony is that I often cannot use isearch/occur to search the text buffer as one would expect from Emacs to.
Similarly, I do find that with my embark menus, I occasionally use C-h to then search for a command with completion
I'm with you on the disadvantages of transient -- it breaks the unspoken Emacs contract of treating every buffer the same. But that's unrelated to the fact that it helps many people with the discoverability and memorization issues.
I think the poweruser vs casual user optimization was answered in the naming choice by Charles
doesn't vertico also break this unspoken contract, karthik?
For me that speaks to a deeper contradiction in Emacs..
yes I much prefer vertico's predecessor for that reason, but it's dead
to a much lesser extent. The minibuffer prompt itself works like a regular buffer
if casual is not dedicated to powerusers, it's unfortunate that it does not help its users to become powerusers by disagreeing with some key bindings, i.e. it has different bindings from default emacs
that argument wouldn't go far with the Doom/Spacemacs people though, with their "non-default" default bindings and such
I played around with an experiment to write a small alternative to Casual that would re-use my quick-help "framework" to extract recommended bindings from the current keymap.
NullNix: i mean, for vertico, this is just the default. you can easily tell vertico to use a buffer instead.
You can isearch inside the minibuffer prompt when using Vertico for instance
can you?! new feature in the last year, perhaps? will look again
not the first time my ignorance has torpedoed me
ok i agree with your latest point but still minibuffer is different than other normal buffers imho
Why is it different? The minibuffer is just a buffer, no reason it should break the Emacs contract.
Vertico does not take over the "event loop" like transient does -- not sure how to describe this correctly. So most Emacs commands will work from inside Vertico, especially once you enable recursive-minibuffers
I meant you can run regular emacs commands on the prompt "line" in the minibuffer when using Vertico
mct looks interesting...
karthik: M-x C-s does not behave like i-search in a normal buffer for me, using vertico
+1 for edebug, that would be great
wonders about gud and gdb interfaces -- would definitely benefit
(poke has already gained a transient menu system )
Doesn't Ediff present a help buffer at the bottom?
yes, but it's so small it's easily overlooked on modern big screens
yes, ironically ediff has an anemic one already, and I don't see people criticizing it
Heh, modern screens means big, right? On the other hand, on non-modern screens (small) transient buffers take over too much of the screen
honestly I wonder if I should rejig ediff to use transient
I can recommend (setopt ediff-window-setup-function 'ediff-setup-windows-plain)!
yeah, did that a loong time ago, but most people haven't...
The memory and cognitively impaired if merely due to aging thank you Charles, that's not just you
hear hear
there are also menus
If you use Avy, try using an Avy command when running find-file using Vertico. You'll see Avy jump candidates in the current text of the minibuffer prompt, and you can jump there.
Indeed, but Charles addressed this in clarification of where Casual stands in the design space (vs menus, M-x, etc), namely context-specific keyboard-driven interactive use where some toggling of args can stick while you build a command (i.e. Transient)
menus are also context-specific actually
that said, I agree that transient is an alternative interface with various advantages
it is just not the only way to learn Emacs commands
And menus are also keyboard driven, as M-x tmm-menubar shows
Indeed, I just wanted to point out that if ever Transient fills an interesting/useful point in design space, so those its generalized application to other modes (vs Magit)
that said, I agree that transient is an alternative interface with various advantages
it is just not the only way to learn Emacs commands
And menus are also keyboard driven, as M-x tmm-menubar shows
time for a keyboard upgrade, i can't be bothered to type C-c c or M-x anymore either
YouTube comment: Great presentation! I've been using Casual since it arrived and have been very happy with it; it makes working with emacs much easier. I now also create transients for commands I use, neatly grouped in categories. Transients: life saver.
YouTube comment: This is great! Emacs's plethora of powerful functionality really needs a better way to surface itself to users and this is a great step in that direction. I do have a few thoughts, though:
Q: Is there a convenient way for a user in a transient to get more information about a menu entries? Specifically: the normal keybindings (if available) and command documentation.
It could be useful to gather and display statistics about menu usage. Imagine being able to generate a personalized keybinding cheat sheet with the menu items you use the most!
Hello, my name is Charles Choi and welcome to my talk:"Reimagining the Emacs user experience with Casual Suite."Casual Suite is a set of opinionated user interfaces todifferent modes offered in Emacs. Before I get intodescribing Casual in detail, let's first talk about theexisting Emacs user experience. To make Emacs go, peoplecan either invoke commands by name withexecute-extended-command,run a command directly with a pre-assignedkey binding, finally, use a mouse menu if it's available.
From human-computer interface research, there is aconcept of recall versus recognition in user interfacedesign. Let's show their distinction by example. A commonrecall interface is password entry. Absent any historicalaffordances, a user must directly remember information tosucceed with this interface. In contrast, menus offerimmediate visual cues on what commands are available. Thisallows a user to recognize familiar behavior to supportsuccessful selection of it. From user interface research,the key finding is this. Interfaces emphasizingrecognition are much easier to use than those relying onrecall. In this light, we see that the Emacs user experienceleans too much towards recall. Completion in history canhelp tip the scales towards recognition, but only by alittle bit.This reliance on recall is discouraging to users both newand old, and that's a shame because Emacs has so many usefulcommands. But the kicker is that most of them areinfrequently used. You can't recall them all. At least Ican't. So, a conundrum. While I've been using Emacs sincethe early 90s, truthfully, it's been only in this pastdecade that I've leveled up in using it. Org Mode, Magit,Eglot, Avy, and many other packages have transformed how Iuse it. I can only deal with so much cognitive load andphysically straining key bindings. So, what to do about it?
Let's bring back an old ideal.Keyboard-driven menus have been around since TTY videoterminals with mainframes. If you're old enough to recallworking with such interfaces, these terms will seemfamiliar. They all worked with the limitations oftext-based video displays.With keyboard-driven menus, if a command exists but nobodycan find it, it's not really useful. A well-designed menucan make a command discoverable. If the command isinfrequently used, making it recognizable helps a lot. Andfor working primarily with text, having keyboard-onlyinteractions encourages flow. Given the above, the nextsteps seem natural:augment Emacs with keyboard-driven menus. This is notsaying that I want to obsolete name commands, keybindings,and mouse menus. They all can happily coexist. Emacs islarge. It can contain multitudes.
Conveniently, Emacs has a built-in library for buildingsuch menus. It's called Transient, and it's been aroundsince Emacs 28. Developed primarily by Jonas Bernoulli as aUI toolkit for Magit, Transient has an essential featurefor building great keyboard-driven interfaces.
A transient menu can be pinned and their state updated ascommands are issued from them. This lets us buildinterfaces that reflect internal state changes made bycommands issued from the user. This is great because manymodes have stateful behavior, and guess what? Emacs has a lotof modes.
If you think about it, Emacs modes are akin to theecosystem of apps that we see today, but with far lessstructure and packaging. A mode, like an app, focuses ondelivering specific behavior to the user. There are manybuilt-in modes in Emacs, and these modes are complex withdozens, if not hundreds, of commands. Calc itself has over1,000 of them. It's frustrating to know that these commandsare there, but I really can't access them via recall.
So I decided to do something about it, and that was to transientall the modes, or at least the most major ones. This pastsummer, I had the time and resources to start buildingTransient interfaces for modes that I wanted to moreelegantly use. I decided to call this work Casual. Given itsdefinition, it seemed like a good fit for the vibe that Iwanted these interfaces to embody.
Design principles that I embraced up front werehandcrafted information architecture and layout. This islargely an exercise in mapping a mode's command set to ahierarchical menu structure. I wanted these menus to makesense to most people. Ideally, users would not have to readdocumentation to get at the command that they wanted. Earlyon, I quickly learned that it was impossible to maintain theexisting default key bindings when mapping them over to ahierarchical menu. Also, some bindings I just flat outdisagreed with. I resolved to be friendly, but notbeholden to them. In all of the above, I've gone out of my wayto make clear that my design decisions are opinionated.
Using casual.To reinforce habit, a common key binding is used per mode toraise a main menu. This key binding is left to userpreference. For me, that binding is C-o.Command bindings are mnemonic when possible.Mode-specific settings are given their own menu. Sincetransient menus can be pinned, we can support repeat orstateful behavior in a mode.As of this writing, there are 11 modes supported by Casual,with several more on the way.
Let's look at the Casual menufor Dired to highlight the design conventions previouslymentioned.In a Dired Emacs window, the user can invoke their preferredkey binding to call a top-level Casual main menu. This mainmenu is displayed at the bottom of the Emacs frame. Zoominginto this menu, we see the commands offered in itcategorized into different sections. Each command has akey binding, usually a single character shown before itslabel. The File section holds commands that act upon thecurrently selected item or marked items. The Directorysection holds commands that affect the current directoryor its subdirs within it. The Mark section has markingcommands that allow for aggregate operations. TheNavigation section shows commands that move the point in adirect buffer. The quick section provides access tobookmark and buffer list commands. Search and replacecommands are grouped in the search section. New directoryand file creation are given their own section. Finally, atthe bottom of the menu are commands dedicated to Casual menunavigation.Casual is conformant to Transient conventions where thekey binding C-g for dismiss one and C-q to dismiss allmenus are honored. Another transient convention is toreserve the key binding q to quit the current mode. For mostmain menus, casual uses the , key binding to invoke amode-specific settings menu. Casual also adopts thecommon UI convention of using ... >symbols to denote required input and submenusrespectively.
Some commands are more global or non-mode specific innature. A great deal of these commands relate to editing,which I find to be a prime motivation for using Emacs. Let'sexamine one such menu that supports this.The main menu for Casual EditKit is designed to provide easyaccess to editing and editing-related commands. Like theprevious Dired menu, it organizes commands into differentsections.Commands related to file and buffer operations are in theFile section. Commands for editing text are in the Editsection. S- or balanced expression commands are given adedicated section for their own. More often than not, inmany modes, I find them to do what I want.The tools section provides access to common tools.Bookmarks I consider to be an essential feature. If youhaven't used them, it's never too late to start. Emacswindow management commands are given this section.Commands for search and replace, macros, and projects canbe accessed from here. Finally, the menu navigationsection. Note that register commands can be accessed fromhere.
Okay, enough screenshots. Let's look at Casual in actionwith a demo of the EditKit menus. Let's start our demo ofcasual-editkit with raising the menu, which is bound toC-o. You'll see the menu pop up here. Inparticular, we want to look at the edit operation. We'llpress e and we'll see a number of menu items that allow you tomake editing transformations to the text, be it marking,copying, killing, transposing, transforming, moving, ordeleting the text. You'll see also that there is a submenufor rectangle operations. Let's first...
Let's actually dig through and look at what's in the Mark submenu.You'll see that there are increments of text in which you canmark. You can mark a word, a sentence, a paragraph, andbalanced expression. If we go back, you'll see a similarpattern for copying as well as killing. Transposing.Let's go and try to move a sentence. We have the point there athello there. We'll move that sentence around. If wepress s, we can move it backward or forward. In this case,let's move it forward. We'll press f. You'll see hellothere move up a sentence. Then we can also press b to moveit back. Then press RET to dismiss. Also, if we wantedto, we can... In this menu particularly, you'll see that wealso have cursor navigation, so we can move the point there.That's not in all the menus, but in a good part number of themenus in Casual Edit Kit, you'll see that here. Let's pressRET to dismiss that.
Let's actually look at some rectangle operations here.In this case, we have a list withitems x, y, and z. Let's say we wanted to prefix each itemhere with a string. We'll say we want to put in therehello. One way of doing that is to make a rectangle. Soif we go into our rectangle menu, first off, what we need to dois define that rectangle region. We'll press m to markwhere the point is right there. Then we can use our cursoroperation to move the point to define the rectangle. In thiscase, it's right at the start there. We can use the stringinsert command, i, to insert hello, colon, and then we'llput a space there to make it look a little nicer. Sureenough, that's in there.We can have access to a number of rectangle commands here.
If we wanted to, let's say, number, we can go through that sameoperation here, define a region, a rectangle region thatis, and press n. You'll see that it has incremented anumber for each item in that rectangle region. We can alsotap u to undo these operationsand leave that at that.
Sorting. If we select a region here, And we go back. You'llsee that the sort submenu is now enabled. Sorting won't workunless you have a region started. That's one of the nicethings about transient is that it allows you to visuallyenable or disable command items with regards to whateverthe current state or context is here. In this case iswhether or not you have a region highlighted. Let's say wewant to sort these two columns of numbers and so there's acommand called n here which is numeric fields. Let's choose thathere. Sure enough we get that. But there's a nice twistthere. Let's say we wanted to sort on the second column.Let's move our point back up to here and we'll mark that.Since everything is in a continuous line, we can sort ofpretend that this region is actually a paragraphand mark that.We'll go and select our sorting routine. But now we need tofigure out how to make numeric fields sort on the secondcolumn. In transient, if we press a ?, thatgives us basically a intermediate help section where, if wepress a key binding, it will tell us or load the docstring forthe command that's there. That command in this case issort-numeric-fields. It requires an argument. Thatargument can be passed using the prefix argument,C-u. Press q. Let's do that. In this case, wewant to check or use the value 2 and press n. Sure enough,that region is sorted with respect to the second column.
[00:17:04.340]Casual has transformed my user experience with Emacs
Before Casual, so many powerful Emacs commands were notavailable to me because they were too hard to recall or Icould not discover them. Making Casual has changed that,letting me reimagine more positively my user experiencewith Emacs. If you're interested in any of what I've showntoday, I invite you to try out Casual.
Before I leave, my thanks and acknowledgmentsgo out to the following people.First, to Jonas Bernoulli for making Transient and Magit.Casual would not be possible without your work. Next, toPsionic-k for writing Transient Showcase. It showed me how Icould build casual. To all the casual users and theirsupport, I am genuinely appreciative. Finally, to JonSnader for writing the kind posts on Casual on the Irrealwebsite. Thank you.Casual can be found on MELPA,and its repository is hosted on GitHub.
Leo? I'm doing well as well and I'm so happy to have seen yourtalk because the interaction with Emacs is alwayssomething that I find very interesting, and stuff likeTransient, stuff like Hydra before, I think they reallyimprove the user experience of users, and I'm really gladthat I've seen you talk. Perhaps just starting with thefirst question, do you have anything else that you'd like toadd on your talk? Because we are pretty stringent with theamount of time that we give for talks, but is there anythingthat you would have liked to mention to people that youweren't able to fit into the talk? I think probably one of thedesign considerations I've done is that many of thecommands that I've exposed through my casual interfaceshave been in Emacs. They've been in there forever, but veryfew people uh, myself included really know that they'rethere, uh, because they're just not discoverable through,uh, basically the existing mechanisms, you know, prior totransient and which key to, to even know that those, thosefunctions are there. Yeah. So I think I'm going to startasking you questions whilst people start writing them in apad. But yeah, I also think that discoverability is a veryhuge point that having stuff like the stuff that you'veshowed today actually allows. One example that I'd like togive that many people tend to forget, and you've alreadymentioned it in your presentation, is that I've learned somuch about using git in general thanks to Magit, for thereason that it shows you so many options that you might not beaware of. For instance, I like to really think about whenyou think about logging in git, Magit allows you todiscover so many of the finer options, like I only want tosee the first commit since the merge, or I only want toconsider this subsection of commits going from master ormain to the point of your branch. So many things like thisthat you get to discover thanks to Transient. So do you haveany similar experience on your end? Oh yeah, far toomany, particularly with EditKit,having access to these commands,particularly with different granularity onS-expressions, sentences, words...Probably the most surprising thing I foundwas just how how compelling theS-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 justjump into questions. Okay, certainly. I'll be reading themfor you so that it's easier for you. So the first question is,
[00:03:13.600]Q: I wonder whether casual can only be used with the packages you
I wonder whether casual can only be used with the packagesyou mentioned or whether it can be used with whateverpackages you like. I think it's really the latter. I'm notquite sure what the... What the question was reallypointing at, you know, is the question asking for why I chosethe packages or the different modes that I did? Or is it, arethey looking at it from a developer perspective of, can weintegrate casual with other packages? I mean, since we'vegot a little bit of time ahead of us, feel free to answer bothquestions. Um, I think the answer is, uh. Well, for the 1st,1, I've, I've generally tried to stick with using. The modesthat are already packaged in, um, and so there was a. A bigrefactoring of it where. Initially, I made separate reposfor the different modes that I supported. And then through adiscussion, which I won't go into here, that got changedwhere I consolidated all of the different transient menusfor modes that are built in for behavior that's built intothe Emacs. I put that into a single package called casual.And then integrations with other third party packages thatare not built in were given the same standalone repo here. Interms of folks wanting to integrate that, it's the beauty ofopen source. They can get the repo and uh, and basicallystudy that the code base, uh, actually, if they even installit through, uh, you know, the package manager in this case,uh, coming from the Melbourne distribution, um, they caninspect 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 thethings that I need to, or at least, uh, you know, that I, I, Iplanned on sort of elaborating further on in thedocumentation is, is that transient already has built inmechanisms for modifying an existing transient. So you canadd commands or, uh, re redefine the bindings. And so. Thatmechanism is available for users if they're not happy withthose bindings or they want to add their own commands to amenu. Yeah, and people are... I'm personally familiar withthis, again, with Magit, because sometimes, even thoughyou have a lot of discoverability for functions that you maynot know, sometimes you also happen to realize thatsomething is missing in the list of available options. I'mnot sure if Casual actually supports something similar toMagit, which is levels of options being displayed.Actually, I'm not sure if it's transient native or if it'sjust something that Magit adds over this. No, transientsupports levels. I've decidedin large part, I've tried to avoid that just to avoid theadded complexity of trying to define those levels. Yeah, Iwas going to say that perhaps it doesn't gel very well withthe notion of casualness that you seem to be introducing thepackage. On one end, you've got something that is supposedto be very casual, very easy to use, and on the other end, youadd levels for stuff that is fairly advanced. So advancedversus casual, kind of makes sense that you check this over.Alright, moving to the second question which is related tothe previous one.
[00:07:10.854]Q: Are there any patterns emerging, such that it would seem possible to 1) systematize 2) automate(?) the mapping of mode commands to keyboard-driven menus? Possibly even have an auto casual wrapper for an uncovered mode?
Are there any patterns emerging such thatit would be impossible, sorry, such that it would bepossible to once systematize and to automate the mapping ofmode commands to keyboard-driven menus, possibly evenhave an auto-casual wrapper for an uncovered mode? Does itmake sense to you? Yes, and I've gotten these comments from anumber of different folks who really want to see some sortof design rule to, or basically, what is it? Some sort ofdesign system to be able to generate the UI.Conceptually, I think it's doable, but on the flip side, itjust requires so much coordination that it makes it reallyuntenable. In this case, I have very strong opinions. Ithink we're better off trying to handcraft the userinterface to get basically the best user experience. To tryto emulate that with a design system, good luck, but I'm notI'm not interested in working on that. Right, yeah. I thinkif I try to think a little more about this, it feels likethere's a notion of intention that is very important whenyou are designing UI and UX. And to have this intention, itfeels like you cannot just base yourself of a design idea toorganize the options. You cannot just work off a pattern. Ithink you need to have the trace of human understanding inorder to have a UX that really works. And judging by theoption that you've picked in the demos that you've showedtoday, I don't think it'd be particularly easy to organizethem in a UX just casually for any mode. I think you need somehuman introspection to understand this, if that makessense.Moving to the next question, which is related to somethingwe discussed about with Magit.
[00:09:19.606]Q: Does Casual have a log where you can see what commands were invoked?
Does Casual have a log whereyou can see what commands were invoked? This is alwaysavailable via M-x view-lossage or via the command-log-mode,but I'm wondering if it can do for Emacs command whatmagit-process-buffer does for learning Git commands. And foreveryone who's currently in Emacs, whenever you'rerunning a command in Magit, it's always printing the exactcommand that was run in a shell, inside this $menu. So does Casual actually provide something similar,Charles? I don't know. In general, because I'm building offof transient, it would have to be a mechanism that'savailable through transient. And You know, I would letJonas speak more on that capability, because to be honest, Imean, even to my knowledge of transient is not that deep,actually.Well, it's funny that you say this because even though yousay your knowledge might not be that big, you still managedto develop a whole suite of tools on top of it. So as far aspeople who do not know transient a whole lot, you're doing apretty 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 onother software ecosystems. And as of late, I've spentbasically the past decade working on iOS apps. Right. Ithink it's refreshing to be able to go back to something thatlooks like Emacs after iOS.Well, that's perhaps another longer conversation there.Speaking of longer conversation, we have only about 10minutes left until we need to move on to the next talk. Butthank you everyone for all the questions you're asking. I'mnot saying this because we finished, but it's good to see somany people writing in the chat and asking questions. Italways shows that you're interested and that's alwayslovely to us. And you've mentioned Jonas. Obviously, we'retalking about Jonas Bernoulli, i.e. Tarsius, themaintainer of transient. And what Charles just mentionedabout having a transient tooling to print the lossage,basically, of which sex were run by which command, feelslike this is something that would be interesting. So,perhaps, I'm not sure if Tarsius is still on the chatcurrently, but he was definitely around earlier today, sowe'll make sure that the ID lands on his lap later on. Allright, moving to the next question.
[00:12:00.204]Q: Is there a setting to close menu after executing command?
Is there a setting toclose menu after executing a command? By default, it will.There's a slot that you can define in a transientprefix called :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. Thisfeels... Did you actually get to play with Hydra beforeplaying with transients? To be honest, no. Yeah, I kind ofslept on Hydra or at least, you know, I really wasn't all thatambitious with working with different packages untilabout like, a little less than 2 years ago or so.And then the other part was also, um. You know, not not reallya technical. Start a comparison because I really don't wantto upset folks here, but, uh. But more along the lines of justgoing with the notion that transient was being built in orpackaged as a built in package for Emacs. I went with usingthat for my implementation. Cool. And I don't think there'sanything controversial with what you're saying right nowbecause, you know, we had earlier today, Euro Rechenko, thenew maintainer of Augment, mentioning that he'd like tohave a better integration with Transient becauseTransient is, it looks like it's here to stay for a long timeand might even land in core at some point. So, it definitelyfeels comparing Hydra because for me, most of my UI needs inEmacs prior to Transient were done via Hydra because it was avery convenient tooling. For people who do not know, Hydrais written by AboAbo. who's also authored packages likeLispy, an interactive Lisp mode, also for Ivy, which youmight know as the counterpart of Helm, maybe five years ago.So all those packages, they were very innovative for thetime and it's cool to see that some of the ideas which wereintroduced by IV and Helm and all this are then taken by toolslike Transient and done perhaps with a little morehindsight now that people have experienced a little more ofit. Okay, we have still a little bit of time. Moving on to thenext question.
[00:14:40.282]Q: What modes are you working on at the moment for casual / are excited to explore?
What modes are you working on at the momentfor Casual or are you excited to explore?Well, so I just recently published one for calendar. And so Ithink the calendar interface has a lot of reallyinteresting behavior, particularly its support fornon-Gregorian events, which is, you know, for folks who'dlike, in my case, looking at the lunar calendar, it's greatto have tooling to be able to not have to leave Emacs to figureout when a lunar date is.Then, I think, you know, for the most part, My work on casualwas really kind of my summer of code for Emacs here. And so inmany ways, the velocity of casual development is going toslow down where I've got a big bulk of the modes that I reallywanted to take care of. Um, I think one experimental thingthat I think is very unbaked, but I would, you know, if folksare interested, uh, maybe looking at it is, uh, taking a lookat 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 thatI really have a desire to do it, but anotherone would be ediff. Right. Okay. Relitigating it'sinterface, um, to have a transient menu. I saythese things, but I'm also scared of those things. Yeah, Imean, I think it's a lovely way to tackle the project,really, because you are fully aware that edebug and ediffsare mastodons when it comes to Emacs. They work very well. Ifyou've ever tried to do a conflict resolution in Magit andyou've pressed e, that usually opens ediff for you. If youhappen to know how it works, it's amazing, but if you do not knowit works, the interface is a little... It's a lot to take inat the moment. You have to know a, b, w... I can, and Ican never remember which one is the lower and which one is theupper. Like, it constantly goes in different directions. Ican never remember which is the commit I'm trying to merge,which is the commit I'm currently being on. It has nothing todo with Magit. It's merely Git and the way they conceivethis. And probably, there might be a very nice way toremember it, but I still haven't found it after 10 years as asoftware developer. So, I guess I need to dig a littledeeper. But what I find lovely about the approach is that foryou, working on the interface to those tools is actuallysomething that allows you to discover how they work, butalso how to make it more easy for people to understand howthose tools work. So you're doing the work ofunderstanding, of digesting a lot of the commands, so thatpeople do not have to go through the same pain as you have. So Ifind this a very noble endeavor in a way.
In so many ways, as perhaps I've mentionedin my talk, I'm getting older. I can't remember allthese damn commands and my hand dexterity is failing. Imean, there's so many. Like multiple keystrokebindings, which I absolutely loathe. At most,like I can, I can only physically handle like, twocharacters, three maybe, at a time. So maybethat's just me, and others mayfeel differently, but at the same time,the work that I've invested here is has been very personalfor me because I just don't want to work that hard, and I want tokeep using Emacs. Yeah, and that's again a very goodendeavor, I think, to have. And there's one last thing thatI'd like to mention, because you've mentioned this projectof yours, Casual, being some kind of summer of code, with theimplication that you've worked a whole lot of it during thesummer or during this period. and perhaps investment willdie down a little bit now. But I think it's completely fine tohave moments when you feel particularly excited and you do alot of work, and sometimes it dies down a little bit.Personally, I've been... Four years ago, I was working a loton Org Roam and I had my Summer of Code on Org Roam. And that wasgreat. I was able to do a lot of things, to get a lot of thingsout of my head. But eventually, you know, you have to go makesome money to survive or you have to take care of family andstuff like this. So, life tends to get in the way of yourhobbies, especially when, you know, it's so... It'shobbies that involve so much of your time to get thingsright, like programming does. But, you know, we appreciateall the work you've done, Charles, and the fact that you'veput it out there for people to enjoy. It's already a victory.You don't need to feel compelled to keep working on itbecause ultimately, as you said, the beauty of open sourceis that people can just send PRs and get the project goingagain. Yeah. I mean, and if anything, you know, folks haveexpressed to me that, you know, in many ways, a lot of thisstuff should be, you know, sort of folded in the core. And,you know, I would love to see at least the ideals of, or atleast an openness into thinking, rethinking the interfacefor Emacs. So, you know, it doesn't have to be, basicallywork the way it worked for basically the last half of the 20thcentury here. Yeah, Emacs is flexible enough to havedifferent approaches and, you know, transient is oneapproach, but at the same time, you know, the ability toreimagine the user interface for, you know, the computingneeds, you know, for basically users needs today, whetheryou write or code or anything of that nature, I think is anexciting and great thing. Yeah, well, thank you so much forthis conclusion. So I'm a little sorry, because sadly, weneeded to move the stream to the next talk. So we've lostabout 20 seconds of what you said. But don't worry, whateveryou've said will be available on the website. I didn't wantto interrupt, sadly, because I didn't want to be rude. But Ithink we did a great job answering the questions. So thankyou so much for taking the time. I'll need to get going,because we might have a problem with the next talk. So thankyou so much, Charles. Certainly. Take care. Thank you.Appreciate it. Bye.