notes from /dev/null - emacs

Casual now available on NonGNU ELPA

2026-03-03T13:10:00-08:00

If you are an Emacs user who only uses 3rd party packages from ELPA or NonGNU ELPA, I’m happy to announce that Casual is now available on NonGNU ELPA. 🎉

If this is the first time you’ve heard of Casual, it is a project to re-imagine the primary user interface for Emacs using keyboard-driven menus. Casual’s design intent is to make the vast feature set of Emacs easier to discover and use in casual fashion. It does so by providing bespoke hand-crafted menus for different modes provided by Emacs. These menus are opinionated in that the design of what goes into those menus are editorially determined by yours truly. To understand more about what Casual has to offer, please peruse its User Guide.

In terms of implementation, Casual is built using the Transient library made by Jonas Bernoulli. This is the same library that powers the UI for Magit.

Development of Casual has been on-going for nearly two years now. Interested readers can read about Casual’s progress over that time from my blog posts here. Throughout it all I’ve learned a lot about Emacs, its ecosystem of modes, and the powerful features they bring. It has only reinforced my conviction that Casual makes these powerful features more usable beyond what is offered by default in Emacs.

To clarify, if you still get Casual from MELPA (or MELPA Stable), you do not have to change anything. The only difference is that users can now choose to install Casual from either MELPA or NonGNU ELPA. Updates to Casual will be distributed on both equally.

My thanks goes out to the NonGNU ELPA reviewers who have provided guidance in helping get Casual on there. Additional thanks goes out to all the Casual users whose input and support have kept me going at this since 2024.

Announcing Casual Org

2026-02-19T15:00:00-08:00

Most Emacs Org users would concur that Org mode is a magnificent tool for capturing and communicating thought. That said, Org mode’s vast set of features can be daunting to master. A common guidance for new users is to take it slow: incrementally learn a subset of Org’s features as you need them.

A big reason for Org mode’s steep learning curve is that it adopts Emacs’ unfortunate culture of compelling users to memorize keybindings. Learning a distinct keybinding for each Org command (remember I said vast feature set?) is onerous, so a different tack is made: reuse the same keybinding but have it possess different behavior based on context. This context is usually tied to the type of structure the point (aka cursor) is in. For example, if the point is in a source block, the binding C-c C-c would execute it, but if the point is on a checkbox item, then C-c C-c would toggle its checked state. Taking this approach lowers the effort to recall a keybinding at the cost of recalling what its contextual behavior would be. In practice, using such overloaded keybindings is…okay. But I’d argue that we could have a more usable interface, leading to the point of this post:

Announcing support for Org mode in the v2.14.0 update for Casual, now available on MELPA.

Readers of this blog will know that Casual is my project to re-imagine the primary user interface for Emacs using keyboard-driven menus. If this is new to you, I highly recommend reading this introduction to it.

Primary to the design of the Casual Org menus is to be context-sensitive, only showing a subset of Org mode commands that are relevant. This set of context-sensitive commands is opinionated, but seeks to provide utility to users both new and experienced with Org.

Shown below is a demo of Casual Org at work:

Your browser does not support HTML video. Link to video.

While the design of this UI has been months in the making, there is nothing like real-world use and feedback. Constructive input is appreciated, especially if you are relatively new to using Org.

A great deal of thanks goes out to the maintainers of and contributors to Org mode and to the community that uses it. If you are able, please support it. Also, if you find Casual useful, I’d appreciate a coffee as well.

—

Video music: Burna Boy - Last Last (JON REYES FINDAWAY BLEND) | Jon Reyes

Deburring Emacs Imenu GUI Configuration

2026-02-10T09:20:00-08:00

A while back, I made a post on Emacs Imenu configuration that made an unsafe assumption that any mode derived from prog-mode would support Imenu. Turns out, that’s not always true (for example, looking at you gnuplot-mode). This post shows how to deal with this using an error handler.

One such implementation of an error handler is the lambda expression shown below using condition-case.

(add-hook 'prog-mode-hook
          (lambda nil
            (condition-case err (imenu-add-menubar-index)
              (imenu-unavailable
               (let ((inhibit-message t))
                 (message "Warning: %s" (error-message-string err)))))))

A couple of observations:

The error handler is opportunistic in applying imenu-add-menubar-index to a mode derived from prog-mode.
If the error imenu-unavailable is caught, then a warning message is logged but not messaged to the mini-buffer.
- The variable inhibit-message is used to avoid sending a warning message to the minibuffer (it will still be logged in *Messages*) to avoid noise from modes that do not support Imenu. (Thanks to bpalmer for this guidance.)

If you use Emacs and this is the first time you’ve heard of Imenu, I highly recommend that you learn what it has to offer.

Using Casual to work with Emacs Registers, Rectangles, and Windows

2026-02-07T10:00:00-08:00

The features of registers, rectangles, and window management in Emacs are quite powerful yet prior to building Casual, I rarely used them because of the cognitive load of remembering each feature’s command sets, much less their bindings. Using keyboard-driven menus tailored for these three features changed that. Now I only have to recall three key bindings to get easy access to registers, rectangles, and window management. This post demonstrates how you can as well.

Provided you have Casual installed from MELPA, consider making the following global key bindings to your Emacs setup:

(keymap-global-set "C-c r" #'casual-editkit-rectangle-tmenu)
(keymap-global-set "C-c g" #'casual-editkit-registers-tmenu)
(keymap-global-set "C-c w" #'casual-editkit-windows-tmenu)

As always, you can adjust these bindings to your preference.

Each of these menus are detailed further below.

Rectangle Menu (casual-editkit-rectangle-tmenu)

The rectangle feature gives you the ability to mark (select) an arbitrary rectangle region in an Emacs buffer. There are many times where if the text is shaped like a rectangle, making transformations on them is exceptionally convenient. This menu provides you this.

Registers Menu (casual-editkit-registers-tmenu)

Registers provide users a way to temporarily keep track of Emacs run-time state like text clippings, cursor (point) positions, macros, and arrangement of windows.

Registers are a distinguishing feature of Emacs from other applications that support writing. It’s definitely a feature I miss when working outside of Emacs.

Windows Menu (casual-editkit-windows-tmenu)

In Emacs vernacular, a window is a visual organization of how a buffer is displayed. Emacs windows are not the same as what conventional GUIs (e.g. Wayland/X11, Apple macOS, Microsoft Windows) refer to as windows. In Emacs, GUI windows are referred to as frames.

Emacs provides a number of commands to manage windows throughout their entire life-cycle which Casual organizes into the menu shown below:

In practice, I’ve found this menu to be most useful when using a compact/laptop-style keyboard or accessing Emacs via TTY. But if you are using GUI Emacs with a keyboard that has a number-pad, consider making the following number-pad bindings, particularly for selecting focus and swapping windows.

;; Number pad bindings for window management.
;; Requires GUI Emacs.
(keymap-global-set "C-<kp-add>" #'enlarge-window)
(keymap-global-set "C-<kp-subtract>" #'shrink-window)
(keymap-global-set "M-<kp-add>" #'enlarge-window-horizontally)
(keymap-global-set "M-<kp-subtract>" #'shrink-window-horizontally)
(keymap-global-set "C-<kp-enter>" #'other-window)
(keymap-global-set "M-<kp-enter>" #'switch-to-buffer)
(keymap-global-set "C-<return>" #'other-window)

(keymap-global-set "C-<kp-8>" #'windmove-up)
(keymap-global-set "C-<kp-5>" #'windmove-down)
(keymap-global-set "C-<kp-2>" #'windmove-down)
(keymap-global-set "C-<kp-4>" #'windmove-left)
(keymap-global-set "C-<kp-6>" #'windmove-right)

(keymap-global-set "M-<kp-8>" #'windmove-swap-states-up)
(keymap-global-set "M-<kp-5>" #'windmove-swap-states-down)
(keymap-global-set "M-<kp-2>" #'windmove-swap-states-down)
(keymap-global-set "M-<kp-4>" #'windmove-swap-states-left)
(keymap-global-set "M-<kp-6>" #'windmove-swap-states-right)

;; These require the `ace-window' and `transpose-frame' packages.
(keymap-global-set "C-<kp-0>" #'ace-select-window)
(keymap-global-set "C-<kp-divide>" #'transpose-frame)

Note that the bindings for ace-select-window and transpose-frame require that you have the ace-window and transpose-frame packages installed.

Closing Thoughts

Registers, rectangles, and managing windows in Emacs are powerful features that are made easier to use with Casual. If you haven’t explored them, consider trying them out. I think you’ll be pleasantly surprised by what they offer and over time will consider them essential to your Emacs experience.

Getting Eshell nth History to Work

2026-01-26T22:15:00-08:00

As much as I enjoy using Eshell, it is not without its annoyances. In this case, I’m writing about the common shell convention of using !n to recall a previously entered command.

In Eshell, entering the history command will show you all of your previously entered commands alongside a number n.

The problem is in attempting to use !n to recall a specific command in Eshell as one would do in bash or zsh. By default it will not work as described in Info (eshell) History without configuring eshell-expand-input-functions first. (My current configuration is GNU Emacs 30.2.)

To get !n to work requires adding the function eshell-expand-history-references to the customizable variable eshell-expand-input-functions.

The following configuration Elisp will achieve this.

(add-to-list 'eshell-expand-input-functions
 #'eshell-expand-history-references)

A nice feature of eshell-expand-history-references is that it will expand using the content of an actual command instead of a number reference. So !foo will invoke the last command that you entered the string “foo” in.

It’s not clear to me whether coupling n^th history support to eshell-expand-history-references is intentional or a bug. If the former, then I’d consider this yet another example of staying “on brand” with Emacs’ tendency to ship with questionable defaults. That shade aside, Eshell is still an amazing package that I could not imagine using Emacs without.

Announcing Casual EWW

2026-01-22T14:20:00-08:00

I confess to taking a perverse delight in browsing the web from within Emacs. The EWW package that comes with the standard distribution of Emacs makes this possible. On paper, Emacs really has no business trying to support web browsing with its laughably threadbare support for layout and typography, much less its lack of support for multi-threaded operation. In practice though, I’ve found browsing the web from Emacs to be surprisingly useful. To enhance my usage of EWW, I wanted easy discovery of its features via Transient menus. With that motivation, I set out to build Casual EWW, now available on MELPA in the Casual v2.13.0 update.

EWW is a minimal browser in that no CSS nor JavaScript is supported. As such, EWW is best suited for websites that treat HTML as a document specification and not as a sub-system to a web application.

Features of Casual EWW include:

Support for in-page paragraph and link navigation.
Key bindings that match Safari and Chrome on macOS.

In particular M-[ and M-] for historical navigation and M-l for entering a URL to open are supported.
Menus for toggling and configuring the display of a web page (font, colors, images).
Support for document navigation.

This feature distinguishes EWW from other conventional web browsers for navigating websites that support the rel attribute. For example, Texinfo uses the rel attribute in generating HTML output.

Observations and Closing Thoughts

Some observations in using EWW:

The implementation of bookmarks in EWW is… underwhelming.

Note that EWW bookmarks are a different implementation from a regular Emacs bookmark. The EWW bookmark list does not provide a means for ordering a bookmark, much less for sorting and editing them.
The eww-readable command (bound to R) is your friend (when it works).

EWW provides a “reader” mode via the command eww-readable which attempts to display only the main content of a web page. If successful, I’ve found it to vastly improve EWW’s utility.

Setting the variable eww-readable-urls to include documentation from https://developer.mozilla.org will break the command css-lookup-symbol (accessible via Casual CSS) as that command expects the web page to not be in reader mode.

For Emacs users, the utility of EWW is very much a YMMV thing as it can overlap the features of other packages like the Info reader and Elfeed. Regardless of what is preferred, it is assuring to know that web browsing (however limited) is supported within Emacs.

Casual EWW is now available on MELPA in the Casual v2.13.0 update.

Announcing Casual HTML & CSS

2026-01-06T17:40:00-08:00

Although I rarely code up HTML and CSS these days, knowing their basics have brought me compounding rewards time and time again. If you use Emacs, you’re in luck as it provides built-in editing modes for both. These modes can make short work of sculpting your web pages to be presentable to the world at large.

Improving the discoverability of the features in these modes is what the latest v2.12.0 update of Casual is all about. Announcing Casual menus for HTML and CSS, new for 2026, now available on MELPA.

Casual HTML

The main menu for HTML mode is shown below. Tag (</>) operations for inserting, adding an attribute, closing, and deleting are supported.

HTML-specific tags are given their own menu.

Casual CSS

The main menu for CSS mode is shown below. A notable feature is the ability to lookup a CSS symbol from the Mozilla Developer Network (MDN) website using the built-in Emacs browser EWW.

Closing Thoughts

Both HTML and CSS modes support Tree-sitter which offers nice structural navigation features. Although at the time of this writing (Emacs 30.2), using html-ts-mode will break tag deletion (sgml-tag-delete). On the other hand, I use css-ts-mode without issue.

If you haven't used either HTML or CSS modes yet, definitely give them a try using my Casual menus. I think you'll find them to be quite usable.

Export Org to Markdown with the Clipboard

2025-12-17T11:30:00-08:00

In symmetry with my post, Import Markdown to Org with the Clipboard in Emacs, exporting Org to Markdown via the system clipboard might be desired instead. Turns out, Marcin Borkowski has already done this as detailed in his post Org-mode to Markdown via the clipboard with the function org-copy-region-as-markdown. In my Emacs initialization, I’ve taken the liberty of prefixing that function name with mb/ to disambiguate it with actual functions from Org.

If you prefer to write in Org but need to post in Markdown, definitely give Borkowski’s post a look.

Import Markdown to Org with the Clipboard in Emacs

2025-12-04T13:30:00-08:00

The preponderance of Markdown formatted text in both websites and apps is a blessing and a point of friction for Org users. The content is there, but if you’re an Org user, you really prefer the text to be formatted for Org. If you have Pandoc installed, converting from Markdown to Org is trivial but laborious as it involves making the right command invocation with temporary files.

Thankfully, Emacs can automate this conversion as described in the workflow below:

From the source app or website, copy the Markdown into the system clipboard. This step pushes this text into the Emacs kill-ring.
In Emacs, invoke a command which converts the above Markdown text into Org, then pastes (yanks) converted text into a desired Org file.

Note that this workflow presumes that the Emacs kill-ring is integrated with the system clipboard and that pandoc is installed.

The following Elisp command cc/yank-markdown-as-org implements the above workflow:

(defun cc/yank-markdown-as-org ()
  "Yank Markdown text as Org.

This command will convert Markdown text in the top of the `kill-ring'
and convert it to Org using the pandoc utility."
  (interactive)
  (save-excursion
    (with-temp-buffer
      (yank)
      (shell-command-on-region
       (point-min) (point-max)
       "pandoc -f markdown -t org --wrap=preserve" t t)
      (kill-region (point-min) (point-max)))
    (yank)))

This command can be invoked in numerous ways including by key binding, context menu, Transient menu, and directly via M-x. My preference is using the context menu as illustrated in the screenshot below to optimize for mouse copy/paste interactions between different apps.

Users interested in seeing how I’ve configured my context menu can read the source here. Users unfamiliar with Emacs context menus can learn more about it in my post Customizing the Emacs Context Menu.

Closing Thoughts

Implementing cc/yank-markdown-as-org turned out to be a lot more simpler than expected, as the command shell-command-on-region does the heavy lifting in abstracting away the pandoc command invocation and its handling of temporary files. This implementation can serve as a example for other conversions using the kill-ring.

A word of thanks to mekeor on IRC for reminding me that (point-min) and (point-max) exist.

Announcing Casual CSV

2025-11-24T09:00:00-08:00

Like Make, the CSV file format will outlive us all. That said, editing a CSV file is a precarious task, as it can be easy to violate its separator and escape rules. Thankfully, the Emacs ecosystem has got you covered, with the 3rd party ELPA package csv-mode. This mode provides all kinds of conveniences including:

spreadsheet-like visualizing and editing of fields (field alignment)
separator auto-detection (comma, tab, space, etc.)
support for quoted fields
sorting by fields
killing and yanking fields

To aid in the discovery and usage of these features, I’m happy to announce Casual CSV, a Transient menu for csv-mode, now available in the Casual v2.11.1 update on MELPA.

One notable feature Casual CSV adds is the ability to select a region of rows to copy to the kill-ring as an Org table. This is also usable in Markdown flavors that support tables.

Closing Thoughts and Caveats

YMMV on how well csv-mode works for you as its performance is tied to the size of CSV file you are working with. If you are trying to edit a CSV file that is hundreds of megabytes in size or greater, you might want to think twice before doing this in Emacs with csv-mode.

As a general rule, I try to avoid editing CSV files in the first place, as I prefer to think of them as files for data exchange. My ideal use-case for csv-mode is really for viewing. That said, if you really need to edit a CSV file, it is best to copy it first. Casual CSV reflects this sensibility by offering a command to duplicate a file.

To get the best results out of csv-mode, I highly recommend turning on field alignment and separator auto-detection. In addition, turning off line-wrapping will aid in both visualization and navigation. The following Elisp configuration shows how to do this.

;; disable line wrap
(add-hook 'csv-mode-hook
          (lambda ()
            (visual-line-mode -1)
            (toggle-truncate-lines 1)))

;; auto detect separator
(add-hook 'csv-mode-hook #'csv-guess-set-separator)
;; turn on field alignment
(add-hook 'csv-mode-hook #'csv-align-mode)

Thoughts on Funding Free Software Development

2025-11-13T17:20:00-08:00

“I have always depended on the kindness of strangers.” — Blanche Dubois from “A Streetcar Named Desire”, Tennessee Williams.

DISCLAIMER: None of this post should be considered as financial or career advice of any kind. All views and opinions expressed here belong solely to Charles Y. Choi.

Not getting paid for making free software has long been recognized as a conundrum in the early 21st century, where much of its discourse is trenchantly summarized by the xkcd drawing “Dependency” [1] shown below.

For some time I’ve been gathering my thoughts on this matter, with stances that I’ll share in this post today.

Fundamentals on Bringing a Product to Market

Before talking about software, let’s review the basic steps needed to bring a physical product to market.

Design & Development

In this step, the intellectual construction of the product is defined.
Manufacture

In this step the product is mass produced. This step must occur after step 1.
Distribution

In this step the manufactured product is delivered. This step must occur after step 2.
Marketing

In this step, awareness of the product to its target market is raised to induce demand for it. Ideally this step is taken when there is high confidence in delivering the product to the market.
Support

In this step, the producers provide support for the product after it has shipped. This step must occur after step 3.

For a physical product, each step has a monetary cost associated with it. If the producer wishes to make a profit by selling the product, the price of the product must be greater than the cost to produce it. This leads to the incentive to manufacture and distribute as many copies as possible to maximize profit. At scale, the dominant costs are manufacturing and distribution for a physical product.

Software is Different

If the product is software using internet distribution, then its costs for manufacture and distribution become effectively zero. For a software provider, the dominant costs to bring a product to market are design & development, marketing, and support. Such costs are largely fixed with respect to demand. Since software has no intrinsic manufacturing nor distribution cost, for-profit software must resort to creating artificial scarcity to justify (and protect) profit that scales with meeting demand. Tactics to create scarcity include:

Constraining code to be closed-source.
Distributing only executables, typically code-signed to a model of computer.
Compilation-enforced licensing, typically tied to a subscription model.

What about Free Software?

With that background in place, let’s talk about free (both in speech and beer) software. In this post, I make no distinction between free (libre) and open source licensed software [2] as their differences fixate on the user’s ability to modify and redistribute received software. In contrast, this post views free software through the lens of the costs required to deliver said software to the market as described above.

Free software requires that its distribution be zero-cost to users. In contrast with for-profit software, free software evades the creation of artificial scarcity. In light of this, what options are available for developers who want to get paid for making free software? Here are three:

Ask users to voluntarily give money after the software has been produced.
Attach the developed software to a service or hardware-based business model.
Get money upfront from users (or organizations) who have an interest in realizing some specific software, before its design and development are completed.

The first option offers providers no financial incentive to make free software, nor offers a reliable path to cover the cost to make it.

The second option relies on indirect compensation where the service or hardware revenue is expected to cover the cost of software development. Scarcity is imposed by restricting access to the service or hardware based on payment. This option is often taken by startups funded with venture capital.

The third option offers direct financial incentive for the developer to create free software, as money is taken by the developer with the expectation that said software is delivered at a future date. With this option, the design & development step is what is considered scarce. Upfront funding can come in a variety of forms, but largely fall into the following patterns:

Institutional funding, where an organization puts up the funding.
Angel funding, where a small group (< 5) of people contribute the funding.
Crowdfunding, where a pool of small contributions from individuals (> 1,000) is gathered, typically with a target funding goal.

Which approach is taken can vary widely depending on the functionality of the software and the relationship (or lack thereof) between the developer and their benefactors. Note that getting money upfront to develop software precludes gaining profit from it based on demand after it is made, as free software insists its distribution be zero-cost to users. The only avenue for developer profit in this case is to demand funding that exceeds the baseline cost of producing the software.

Getting money upfront implies negotiation, which gives the developer agency to choose whether to commit to building the desired software. It also significantly raises risk to all involved parties if the software fails to be built.

Upfront funding aligns the incentives for producers and consumers of software by having agreement on a future deliverable:

Consumers pay to get the future software deliverable.
Producers work to build the future software deliverable.

While the exact number is unknown, I think a safe presumption is that single developers have built the vast majority of free software packages as evidenced by the Linux, Emacs, Python, and Node ecosystems. Most all of them resort to appeals to user gratuity, which is not enough to actually cover the market cost of designing & developing that software.

Given the above options for upfront funding, I’ll further make the assumption that most single developers do not have access to institutional nor angel funding. So, let's talk about crowdfunding.

Crowdfunding

The dominant cost to producing software is labor. A common project scope is a three month schedule with a single developer. Estimating a market rate salary of $10K/month, this results in a budget of $30K to deliver software at cost.

Crowdfunding has proven to be successful in raising that level of funding, by mitigating risk to all participants by defining a funding goal. Typically a funding goal is set within a window of time. If the goal is not met, then patrons who already put money down will have their money returned and the producer is not committed to work on the software. With high demand, the goal can be met with potentially low financial risk to an individual patron. For example, if 30,000 people gave $1, the above budget could be met.

Reaching those 30,000 people is another thing altogether, as crowdfunding is an exercise in marketing.

To have a successful crowdfunding campaign, the producer must deliver a message about a future software product that is compelling enough to create demand for it. Common tasks undertaken to make a crowdfunding campaign include producing:

A video describing the envisioned product.
Marketing copy for said envisioned product published on web, possibly print.
Brand merchandise for patrons.
- Order taking
- Fulfillment
Press campaign.
Social media campaign.

Note that the success of the crowdfunding campaign will depend on how effective its message is to the target audience. Each audience is bespoke, meaning that not all things successful for one crowdfunding campaign can be applied to another. Invariably, the software producer must know their audience.

Single developers producing free software might look at the above and say “nope.” Most certainly it is a lot of work, much of which is perhaps outside the comfort level of persons whose focus has only been on coding. It is also not a common practice to use crowdfunding to support free (libre) or open source development. Regardless, if a developer wishes to be paid to work on free software, they will need to get comfortable with pitching their work beforehand to get the funding to do it. Wider-scale use of crowdfunding could bring better agency to the developer and enable the development of larger scope free software projects that would be untenable with volunteer time.

Observations and Closing Thoughts

This post has been a distillation of my thinking about free software and how it can be sustainably funded. From this exercise are some of my personal observations:

If you have a software idea that you want to distribute for free, determine as soon as possible if you want to get paid to make it.

If you don’t care about getting paid, ever, for that work, then GO MAKE IT! Be thankful for whatever gratuity you get from it.

If you do care about getting paid to make the idea, then explore what funding model fits best for the idea. At this point, DO NOT MAKE THE IDEA AND PUBLISH IT.

If you get funding, GO MAKE THE THING. MAKE PEOPLE HAPPY.

If you don’t get funding, let it rest. Move on to the next idea.

If you already produced free software that was built without funding, accept that you will never recover your development cost.

To reiterate, free software requires that its distribution be zero-cost to users. This is excellent for user freedom but comes at the expense of agency for developers: Users can not be compelled to pay developers for their already published work. Developers can however make new features and fixes contingent on funding. I think this position is fair and defensible for the obvious reason that software developers must pay for the costs of living in a material world.

If you’ve made to here, thanks for reading! Feel free to share your thoughts about this post on Mastodon or Reddit.

References

[1]

R. Munroe, “Dependency,” Aug. 17, 2020. Available: https://xkcd.com/2347/

[2]

R. Stallman, “Why open source misses the point of free software - gnu project - free software foundation,” 2024. Available: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html

Prototyping a Toolbar UI for Edebug

2025-11-03T13:55:00-08:00

About a year and a half ago I delved into understanding Edebug ((elisp) Edebug), the built-in debugger for Emacs Lisp (Elisp), as I was to give a presentation on it at the Emacs SF meetup. For new users, Edebug can be bewildering as it forces them to know beforehand its many commands and respective keybindings to make good use of it. Because of this complexity, many users writing Elisp often favor simple print-style debugging to avoid ever dealing with Edebug.

My dive into Edebug however left me with the impression that it was more a “kit of parts” in need of a good UI. So I set about to build an Edebug UI with Transient menus. The result of that effort was decidedly mixed. More often than not, window/frame management by Edebug would conflict with Transient. I shelved it.

Working on the toolbar icons for Calle 24, the thought occurred: what about a toolbar for Edebug? The results I think are much more successful, with a number of caveats that I’ll get to later. As far as successes, here’s what I think this toolbar brings:

Similarity to conventional IDE debuggers.
Avoidance of Edebug window/frame management.
Improved discovery of Edebug features.

The screenshot below shows this toolbar in action:

Motivated readers are invited to try this toolbar out using the instructions described in Calle 24 Edebug Support. If you have a prior installation of Calle 24 installed, you should update and re-run the command calle24-install to synchronize with the latest icon set in the v1.1.1 update on MELPA.

Edebug differences from other IDE debuggers

Users new to Edebug but familiar with debuggers for ALGOL-like languages (C, Java, Python, Swift, etc.) should understand that stepping through Elisp code is sexp-based. This distinction is significant when considering stepping into and out of an sexp, which is not the same as a function in ALGOL-like languages. Also, breakpoints can only be set during an Edebug session. If the Edebug-instrumented function is re-evaluated using eval-defun, all prior breakpoints defined for it are lost.

Caveats

Despite my enthusiasm for this toolbar, this should be considered prototype code for the following reasons:

There is an existing bug in the NS variant of GNU Emacs 30.1 where repeated rapid pressing of a toolbar button can force Emacs into a state where it is not responsive to GUI input. Bug reports can be found at #76749, #72496.
Both NS and GTK variants can only show toolbar icons in a single row.
window-tool-bar-mode does not support appearance changes (dark, light mode).
The licensing of SF Symbols icons precludes their distribution using a GPLv3 license.

Closing Thoughts

In many ways, building this toolbar has been a “proof of concept” for me in answering the question: can Edebug have a better UI? I think the answer is a resounding yes, so much so that I’ve decided to put it out in public for others to scrutinize. By no means do I consider this “finished product” given the caveats described above. That said, for those folks who decide to give it a try I’d be interested to know your thoughts.

Announcing Casual Ediff

2025-10-30T07:00:00-07:00

Truth be told, I find default Ediff to be weird and intimidating compared to other tools that do the same thing, which is to find differences between two files. Like other modes, Ediff is reliant on the user knowing beforehand its commands and respective keybindings, which means it has a steep learning curve. Many of these commands are context specific. While Ediff tries to be helpful by displaying a cheat sheet, I find this feature to be so information dense and context-free (in a bad way) that it usually results in upping my anxiety. I mean, look at this table!

That said, I’m not here to bury Ediff, but to praise it. Ediff is embarrassingly rich in functionality and time-tested. It just needs a better UI, which brings us to today’s post topic: Announcing Casual support for Ediff.

The approach Casual takes is to provide a Transient menu for the Ediff control panel, which is configured to be in the same frame as the windows holding the compared files. This menu organizes relevant commands in sections that map to the files being compared and does its best to be context-sensitive (e.g. determine if the buffer is writable or read-only, know if its a file comparision or a merge, etc.).

The result is an interface that is calmer to my eyes, as shown below.

Casual Ediff builds on the work described in my earlier blog post Using Ediff in 2023, in providing a streamlined way to diff a modified version-controlled file. This way, if you already have the file loaded in a window, you can call casual-ediff-revision to immediately see what changes you’ve made to it and to selectively be able to revert each change.

Casual Ediff also lets you resolve merge conflicts (typically from Magit). Added to Ediff is the ability to merge both conflicting differences in the order of choice by the user (the menu items “Merge A,B to C”, “Merge B,A to C”).

Read more about Casual Ediff at Ediff (Casual User Guide).

Casual Ediff is now available on MELPA as part of the v2.10.0 update for Casual.

It costs money to make, enhance, and maintain Casual as ideologically free software. If you enjoy using Casual, please consider a financial contribution to help support its development and maintenance. Thanks!

Storing a Link from your Web Browser to BibTeX using Org protocol

2025-09-25T16:15:00-07:00

If you’re familiar with this blog, you’ll know that I’m a fan of Org protocol, a means of sending data such as web links and content to an Org file from outside of Emacs. Following up on my last post on Casual BibTeX, this post will show how to re-purpose Org protocol to send a link from your preferred web browser to a BibTeX file.

This is achieved by adding the following template (named “bib”) to the variable org-capture-templates as shown below:

(add-to-list org-capture-templates
             '("bib"
               "BibTex Online Entry"
               plain
               (file "~/org/bib/references.bib")
               (function (lambda ()
                           (string-join
                            (list "@Online {,"
                                  "author = {%^{Author(s)}},"
                                  "organization = {%^{Organization}},"
                                  "title = {%:description},"
                                  "url = {%:link},"
                                  "date = {%<%Y-%m-%d>%?},"
                                  "notes = {"
                                  "%i"
                                  "}"
                                  "}")
                            "\n")))
               :prepend t
               :empty-lines-after 1))

The web link is treated as an BibTeX Online entry type whose fields are populated as follows:

url field holds the web page link.
title field holds the web page title.
date is populated with the current day (this should be edited to the actual date).
notes is populated with the body value according to the capture protocol.
author is populated with the value entered via mini-buffer prompt.
organization is populated with the value entered via mini-buffer prompt, typically the name of the website.

The template is configured to prepend (via the :prepend property) the captured Online entry to the file “~/org/bib/references.bib”. These values can be adjusted to taste.

When invoking this template via Org protocol, a temporary capture window holding the populated template is created. This entry will not have a citation key, so it is recommended to run M-x bibtex-clean-entry to generate it before committing the capture via C-c C-c. If you have Casual BibTeX installed, you can invoke the Transient menu casual-bibtex-tmenu with the binding M-m and invoke the clean command from there.

Closing Thoughts

Arguably, Org protocol was not designed to support files other than those using Org markup, so the above practice skirts its design intent by sending the capture to a BibTeX file. But as of Emacs 30.2 and Org 9.7.34, this works fine, so YOLO. Users intent on customizing the above “bib” template should be advised that many template properties are not supported, so be advised.

That all said, it’s a nice win to automate the task of writing a BibTeX Online entry.

Announcing Casual BibTeX

2025-09-24T16:00:00-07:00

Given current events, the importance of having a shared and testable truth is arguably the only thing that matters these days. A time-honored practice to reaching such truth is to write and distribute documentation with good references.

Emacs has long had support for BibTeX, going as far back as 1987. BibTeX is both a bibliography processor for LaTeX documents and more importantly, a database schema for bibliographic data. The significance of the latter allows for using a BibTeX database for contexts outside of LaTeX.

BibTeX organizes bibliographic data into a collection of records (or entries) that are stored in a plain-text file (multiple files are also supported). This plain-text file is identified using a “.bib” suffix and is treated as a database. Any plain-text editor can edit a BibTeX file. This can be seen, especially with 2025 eyes, as a virtue or an anathema. Because the BibTeX database is just a plain-text file, schema enforcement ultimately rests upon the user editing the file.

The Emacs built-in package bibtex tries to help shoulder this schema enforcement by providing commands for both navigating and editing BibTeX data structures (entries and the fields within an entry). In this way, bibtex tries to provide the user a quasi-“form-based” interface to editing a BibTeX file.

Like many other Emacs modes, I find the commands for bibtex-mode to be difficult to both discover and recall. I also find bibtex-mode to not be opinionated enough in trying to provide a form-based experience.

To address this, I’m happy to announce the latest Casual addition: support for BibTeX.

Casual BibTeX organizes bibtex commands into a Transient menu. The bindings remap conventional Emacs navigation bindings for field or entry navigation. Casual BibTeX holds the strong opinion that creation, update, or deletion of either an entry or a field should be done via commands dedicated for those respective operations. Using manual editing of the BibTeX file to achieve the same end is discouraged.

If you are invested in Org, knowing how to work with BibTeX has great benefit as Org has extensive citation support for it.

Casual BibTeX is now available in the v2.9.0 update of Casual on MELPA. Learn more about Casual BibTeX in its documentation.

notes from /dev/null - emacs

Casual now available on NonGNU ELPA

Announcing Casual Org

Deburring Emacs Imenu GUI Configuration

Using Casual to work with Emacs Registers, Rectangles, and Windows

Rectangle Menu (casual-editkit-rectangle-tmenu)

Registers Menu (casual-editkit-registers-tmenu)

Windows Menu (casual-editkit-windows-tmenu)

Closing Thoughts

Getting Eshell nth History to Work

Links

Announcing Casual EWW

Observations and Closing Thoughts

Announcing Casual HTML & CSS

Casual HTML

Casual CSS

Closing Thoughts

Export Org to Markdown with the Clipboard

Import Markdown to Org with the Clipboard in Emacs

Closing Thoughts

Announcing Casual CSV

Closing Thoughts and Caveats

Thoughts on Funding Free Software Development

Fundamentals on Bringing a Product to Market

Software is Different

What about Free Software?

Crowdfunding

Observations and Closing Thoughts

References

Prototyping a Toolbar UI for Edebug

Edebug differences from other IDE debuggers

Caveats

Closing Thoughts

Announcing Casual Ediff

Storing a Link from your Web Browser to BibTeX using Org protocol

Closing Thoughts

Announcing Casual BibTeX