Back to the talks Previous by track: Emacs as a shell Next by track: New in hyperdrive.el: quick install, peer graph, transclusion! Track: General

Re-imagining the Emacs User Experience with Casual Suite

Charles Choi (he/him) - Pronunciation: Che, IRC: kickingvegas, http://yummymelon.com/devnull/ , Mastodon: https://sfba.social/@kickingvegas

Format: 19-min talk ; Q&A: BigBlueButton conference room
Status: TO_CAPTION_QA

Talk

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

Duration: 18:24 minutes

Q&A

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

Listen to just the audio:
Duration: 22:12 minutes

Description

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!

Transcript

[00:00:00.000] introduction
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 to different modes offered in Emacs. Before I get into describing Casual in detail, let's first talk about the existing Emacs user experience. To make Emacs go, people can either invoke commands by name with execute-extended-command, run a command directly with a pre-assigned key binding, finally, use a mouse menu if it's available.
[00:00:43.800] Recall vs recognition
From human-computer interface research, there is a concept of recall versus recognition in user interface design. Let's show their distinction by example. A common recall interface is password entry. Absent any historical affordances, a user must directly remember information to succeed with this interface. In contrast, menus offer immediate visual cues on what commands are available. This allows a user to recognize familiar behavior to support successful selection of it. From user interface research, the key finding is this. Interfaces emphasizing recognition are much easier to use than those relying on recall. In this light, we see that the Emacs user experience leans too much towards recall. Completion in history can help tip the scales towards recognition, but only by a little bit. This reliance on recall is discouraging to users both new and old, and that's a shame because Emacs has so many useful commands. But the kicker is that most of them are infrequently used. You can't recall them all. At least I can't. So, a conundrum. While I've been using Emacs since the early 90s, truthfully, it's been only in this past decade that I've leveled up in using it. Org Mode, Magit, Eglot, Avy, and many other packages have transformed how I use it. I can only deal with so much cognitive load and physically straining key bindings. So, what to do about it?
[00:02:34.800] Emacs with keyboard-driven menus
Let's bring back an old ideal. Keyboard-driven menus have been around since TTY video terminals with mainframes. If you're old enough to recall working with such interfaces, these terms will seem familiar. They all worked with the limitations of text-based video displays. With keyboard-driven menus, if a command exists but nobody can find it, it's not really useful. A well-designed menu can make a command discoverable. If the command is infrequently used, making it recognizable helps a lot. And for working primarily with text, having keyboard-only interactions encourages flow. Given the above, the next steps seem natural: augment Emacs with keyboard-driven menus. This is not saying that I want to obsolete name commands, keybindings, and mouse menus. They all can happily coexist. Emacs is large. It can contain multitudes.
[00:03:43.400] Transient
Conveniently, Emacs has a built-in library for building such menus. It's called Transient, and it's been around since Emacs 28. Developed primarily by Jonas Bernoulli as a UI toolkit for Magit, Transient has an essential feature for building great keyboard-driven interfaces.
[00:04:08.200] A Transient menu can be pinned
A transient menu can be pinned and their state updated as commands are issued from them. This lets us build interfaces that reflect internal state changes made by commands issued from the user. This is great because many modes have stateful behavior, and guess what? Emacs has a lot of modes.
[00:04:29.303] Modes are apps, really
If you think about it, Emacs modes are akin to the ecosystem of apps that we see today, but with far less structure and packaging. A mode, like an app, focuses on delivering specific behavior to the user. There are many built-in modes in Emacs, and these modes are complex with dozens, if not hundreds, of commands. Calc itself has over 1,000 of them. It's frustrating to know that these commands are there, but I really can't access them via recall.
[00:04:59.527] Transient all the modes!
So I decided to do something about it, and that was to transient all the modes, or at least the most major ones. This past summer, I had the time and resources to start building Transient interfaces for modes that I wanted to more elegantly use. I decided to call this work Casual. Given its definition, it seemed like a good fit for the vibe that I wanted these interfaces to embody.
[00:05:28.040] Casual design principles
Design principles that I embraced up front were handcrafted information architecture and layout. This is largely an exercise in mapping a mode's command set to a hierarchical menu structure. I wanted these menus to make sense to most people. Ideally, users would not have to read documentation to get at the command that they wanted. Early on, I quickly learned that it was impossible to maintain the existing default key bindings when mapping them over to a hierarchical menu. Also, some bindings I just flat out disagreed with. I resolved to be friendly, but not beholden to them. In all of the above, I've gone out of my way to make clear that my design decisions are opinionated.
[00:06:17.960] Casual design conventions
Using casual. To reinforce habit, a common key binding is used per mode to raise a main menu. This key binding is left to user preference. For me, that binding is C-o. Command bindings are mnemonic when possible. Mode-specific settings are given their own menu. Since transient menus can be pinned, we can support repeat or stateful behavior in a mode. As of this writing, there are 11 modes supported by Casual, with several more on the way.
[00:07:04.366] Casual Dired
Let's look at the Casual menu for Dired to highlight the design conventions previously mentioned. In a Dired Emacs window, the user can invoke their preferred key binding to call a top-level Casual main menu. This main menu is displayed at the bottom of the Emacs frame. Zooming into this menu, we see the commands offered in it categorized into different sections. Each command has a key binding, usually a single character shown before its label. The File section holds commands that act upon the currently selected item or marked items. The Directory section holds commands that affect the current directory or its subdirs within it. The Mark section has marking commands that allow for aggregate operations. The Navigation section shows commands that move the point in a direct buffer. The quick section provides access to bookmark and buffer list commands. Search and replace commands are grouped in the search section. New directory and file creation are given their own section. Finally, at the bottom of the menu are commands dedicated to Casual menu navigation. Casual is conformant to Transient conventions where the key binding C-g for dismiss one and C-q to dismiss all menus are honored. Another transient convention is to reserve the key binding q to quit the current mode. For most main menus, casual uses the , key binding to invoke a mode-specific settings menu. Casual also adopts the common UI convention of using ... > symbols to denote required input and submenus respectively.
[00:09:06.640] Casual EditKit
Some commands are more global or non-mode specific in nature. A great deal of these commands relate to editing, which I find to be a prime motivation for using Emacs. Let's examine one such menu that supports this. The main menu for Casual EditKit is designed to provide easy access to editing and editing-related commands. Like the previous Dired menu, it organizes commands into different sections. Commands related to file and buffer operations are in the File section. Commands for editing text are in the Edit section. S- or balanced expression commands are given a dedicated section for their own. More often than not, in many 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 you haven't used them, it's never too late to start. Emacs window management commands are given this section. Commands for search and replace, macros, and projects can be accessed from here. Finally, the menu navigation section. Note that register commands can be accessed from here.
[00:10:36.200] EditKit demo
Okay, enough screenshots. Let's look at Casual in action with a demo of the EditKit menus. Let's start our demo of casual-editkit with raising the menu, which is bound to C-o. You'll see the menu pop up here. In particular, we want to look at the edit operation. We'll press e and we'll see a number of menu items that allow you to make editing transformations to the text, be it marking, copying, killing, transposing, transforming, moving, or deleting the text. You'll see also that there is a submenu for rectangle operations. Let's first...
[00:11:31.997] Marking and moving
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 can mark. You can mark a word, a sentence, a paragraph, and balanced expression. If we go back, you'll see a similar pattern for copying as well as killing. Transposing. Let's go and try to move a sentence. We have the point there at hello there. We'll move that sentence around. If we press s, we can move it backward or forward. In this case, let's move it forward. We'll press f. You'll see hello there move up a sentence. Then we can also press b to move it back. Then press RET to dismiss. Also, if we wanted to, we can... In this menu particularly, you'll see that we also have cursor navigation, so we can move the point there. That's not in all the menus, but in a good part number of the menus in Casual Edit Kit, you'll see that here. Let's press RET to dismiss that.
[00:12:53.140] Rectangles
Let's actually look at some rectangle operations here. In this case, we have a list with items x, y, and z. Let's say we wanted to prefix each item here with a string. We'll say we want to put in there hello. One way of doing that is to make a rectangle. So if we go into our rectangle menu, first off, what we need to do is define that rectangle region. We'll press m to mark where the point is right there. Then we can use our cursor operation to move the point to define the rectangle. In this case, it's right at the start there. We can use the string insert command, i, to insert hello, colon, and then we'll put a space there to make it look a little nicer. Sure enough, that's in there. We can have access to a number of rectangle commands here.
[00:14:04.976] Numbering
If we wanted to, let's say, number, we can go through that same operation here, define a region, a rectangle region that is, and press n. You'll see that it has incremented a number for each item in that rectangle region. We can also tap u to undo these operations and leave that at that. Sorting. If we select a region here, And we go back. You'll see that the sort submenu is now enabled. Sorting won't work unless you have a region started. That's one of the nice things about transient is that it allows you to visually enable or disable command items with regards to whatever the current state or context is here. In this case is whether or not you have a region highlighted. Let's say we want to sort these two columns of numbers and so there's a command called n here which is numeric fields. Let's choose that here. Sure enough we get that. But there's a nice twist there. 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 of pretend that this region is actually a paragraph and mark that. We'll go and select our sorting routine. But now we need to figure out how to make numeric fields sort on the second column. In transient, if we press a ?, that gives us basically a intermediate help section where, if we press a key binding, it will tell us or load the docstring for the command that's there. That command in this case is sort-numeric-fields. It requires an argument. That argument can be passed using the prefix argument, C-u. Press q. Let's do that. In this case, we want 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 not available to me because they were too hard to recall or I could not discover them. Making Casual has changed that, letting me reimagine more positively my user experience with Emacs. If you're interested in any of what I've shown today, I invite you to try out Casual.
[00:17:34.451] Thanks and acknowledgements
Before I leave, my thanks and acknowledgments go out to the following people. First, to Jonas Bernoulli for making Transient and Magit. Casual would not be possible without your work. Next, to Psionic-k for writing Transient Showcase. It showed me how I could build casual. To all the casual users and their support, I am genuinely appreciative. Finally, to Jon Snader for writing the kind posts on Casual on the Irreal website. Thank you. Casual can be found on MELPA, and its repository is hosted on GitHub.

Captioner: sachac

Q&A transcript (unedited)

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 Magit, for the reason that it shows you so many options that you might not be aware of. For instance, I like to really think about when you think about logging in git, Magit allows you to discover so many of the finer options, like I only want to see the first commit since the merge, or I only want to consider this subsection of commits 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? Oh yeah, far too many, particularly with EditKit, having access to these commands, particularly with different granularity on S-expressions, sentences, words... 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,
[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 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.
[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 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.
[00:09:19.606] Q: Does Casual have a log where you can see what commands were invoked?
Does Casual have a log where you can see what commands were invoked? This is always available via M-x view-lossage or via the command-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 $ 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.
[00:12:00.204] Q: Is there a setting to close menu after executing command?
Is there a setting to close menu after executing a command? By default, it will. There's a slot that you can define in a transient prefix 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. 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.
[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 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 really have a desire to do it, but another one would be ediff. Right. Okay. Relitigating it's interface, um, to have a transient menu. 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 Magit and you've pressed e, that usually opens ediff for you. 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 lot to take in at the moment. You have to 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 Magit. 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.
[00:18:14.280] Getting older
In so many ways, as perhaps I've mentioned in my talk, I'm getting older. I can't remember all these damn commands and my hand dexterity is failing. I mean, there's so many. Like multiple keystroke bindings, which I absolutely loathe. At most, like I can, I can only physically handle like, two characters, three maybe, at a time. So maybe that's just me, and others may feel differently, but at the same time, 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.

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

Back to the talks Previous by track: Emacs as a shell Next by track: New in hyperdrive.el: quick install, peer graph, transclusion! Track: General