Irreal

Those of you who have been around Irreal for awhile have heard me preach the gospel of interactive (or exploratory) programming before. I consider it the absolute best and most pleasing way to program. The problem is that it requires a REPL, which not every language offers.

Java is one of those languages that does have a REPL although you almost never hear about it. As far as I can tell, the REPL is merely a way of letting you type in a line input and get the corresponding output: not too useful.

Not too useful unless you’re using Musa Al-hassy’s REPL driven development package. It enables you to use interactive programming techniques with Java as well as several other languages.

Here he is putting together a Java-based photo display application using the interactive programming method. Notice how it’s easy to experiment by making a small change to see how things work before writing the more complex code that does what you want for the final application.

I don’t know Java at all so I can’t comment on whether or not is code is optimal or even good but I do know about interactive programming and can report that he’s captured the method very well. If you’re a Java programmer—or, really, a user of any other REPL enabled language—you should definitely take a look at this video. The video is only 10 minutes, 18 seconds so it should be easy to find some time for it.

Emacs Elements has an informative post on how to escape from a recursive edit. Unless you’re already an advanced user, you probably have only a vague notion of what a recursive edit is and you certainly aren’t going to be intentionally entering one. But, unfortunately, it’s fairly easy to stumble into one.

Even when you deliberately enter a recursive edit—the video has a typical use case—you still need to know how to exit to the main edit. The standard way to get out of a recursive edit is Ctrl+Alt+c but sometimes Emacs get wedged—especially when you inadvertently find yourself in a recursive edit—and you need to force an escape to the top level.

The video demonstrates several ways of doing this so you should definitely take a look but a good rule of thumb—although not a complete answer— is to try

• Ctrl+g
• Ctrl+]
• Esc Esc Esc

in order.

There are, as I hinted, a few nuances so be sure to take a look at the video for the complete details. The video is only 8 minutes and 21 seconds so it should be easy to fit in.

Update [2023-11-23 Thu 11:41]: Existing → Exiting.

Michael Neuper has a very nice article on Efficient LaTeX Editing With Emacs. As far as I know, there’s only two reasonable ways of doing that:

1. Org Mode
2. AUCTeX

Org mode is good for what might be called “light weight” LaTeX. If there’s a minimum of mathematics and special formatting, Org is ideal. Its simple markup is easy to learn and you don’t to need to worry about the more difficult LaTeX syntax. The result is exported to LaTeX so you can add LaTeX formatting as needed and the resulting PDF is still produced by LaTeX so you get the beautiful typesetting that the TeX family promises.

If you need more heavy duty mathematics and formatting, it’s hard to beat AUCTeX. It is, after all, purpose built for writing LaTeX inside Emacs. Neuper concentrates on AUCTeX and shows how to augment it to obtain an efficient LaTeX writing environment.

For AUCTeX itself, he starts by showing how to get a live preview within Emacs. If you’re like me and like to see how the output of a long document is progressing as you write, this is a Godsend. A couple of keystrokes and the current document appears right there in a separate Emacs window. What could be better?

He also looks at using special symbols (in the LaTeX source) and folding. I don’t think those are as important as live preview but some may find them useful.

His next addition is CDLaTeX, which I’ve written about before. It provides some shortcuts for entering LaTeX commands and symbols. It’s also usable inside Org—or anywhere in Emacs, really—so it’s definitely worth knowing about if you write LaTeX, even in Org.

Next he looks at using LatexMK and LSP. Most TeX/LaTeX users know about using LatexMK to make sure forward references are resolved. I didn’t know there was as LSP engine for LaTeX but apparently there is. If you care about such things, Neuper shows you how to set it up.

Xenops is a package that I haven’t heard of before. It basically serves as a sort of in place replacement for live preview. Take a look at the animated GIF in Neuper’s post for a demonstration.

Finally, he considers YASnippet and Calc. Both of these are able to expand some simple text into more complicated LaTeX. The Calc example—also illustrated with an animated GIF—is especially revealing. I vaguely knew you could do this sort of thing but I’ve never seen it in action before. Very nice and very powerful.

If you write in LaTeX at all it’s definitely worth your while to take a look at Neuper’s post.

Ruslan Bekenev has a post on filtering the results of buffer listings that reminded me of something I’ve known since I started using Emacs but keep forgetting. Bekenev writes that he often lists the open buffers with Ctrl+x Ctrl+b mostly so that he clean up his Emacs environment by deleting no longer needed buffers. I used to do the same thing so I can sympathize with the urge.

One day, though, he wanted to filter the listing so that only buffers from his current project were listed. Sadly, list-buffers is pretty bare bones and doesn’t support filtering. Ibuffer does, though, and produces essentially the same output as list-buffers. My first thought was, “that’s neat” but I also felt that it seemed familiar.

It was, of course. Long ago when I first started using Emacs, I learned that I should use ibuffer instead of list-buffers. I last wrote about this only a year and a half ago but I’d already mostly forgotten how powerful ibuffer is. Every time I rediscover the filtering capability, I promise myself I’ll internalize and make regular use of it but the truth is I just don’t need filtering often enough for the habit to set.

In any event, ibuffer is a better version of list-buffers and well worth trying. As Mickey says in the above link, “You should switch to it right now.”

Protesilaos Stavrou (Prot) has a really excellent video on Ediff. I’ve always had a difficult relationship with Ediff. It seemed really complicated with lots of obscure commands and, by default, a control panel that resides in a different frame, which didn’t play well with running Emacs full screen as I do. I’d already resolved that last problem but for those of you who haven’t, Prot shows you the secret spell.

More importantly, he demonstrates that using Ediff is actually simple if you ignore all the obscure stuff. With his configuration, the two (or three) diffed files or buffers are shown side by side and a short buffer at the bottom serves as the control panel. By default, the full panel with all the commands aren’t listed—although you can use ? to toggle it—but prot says that doesn’t matter because you hardly ever have to use that other stuff. All you really need to know is n for the next diff, p for the previous diff, and a, b, or c to move the A, B, or C diff to the other buffer(s). That’s it. It covers almost everything you ever really want to do in Ediff.

Prot also demonstrates the Magit Ediff (dwim) command that lets you see how a particular file has changed over a series of commits. It’s easy to use and invoked right from Magit.

Finally, for those who want to configure their Emacs like Prot does for Ediff, here are the two commands you need for side by side buffers and the control panel in the same frame at the bottom:

(setq ediff-window-setup-function 'ediff-setup-windows-plain)
(setq ediff-split-window-function 'split-window-horizontally)

I found this video to be really helpful. Perhaps you will too. The video is 15 minutes, 48 seconds long so you may have to schedule some time.

Mario Jason Braganza has an interesting post that opened my eyes to another way of adapting Emacs to your workflow. I’m a programmer so my first impulse when I have a problem to solve with my workflow is to write a program. That works well for me. It works especially well with Emacs where it’s easy to write a quick function to sand down any friction with in my workflow.

The first thing Braganza did every morning was to manually configure Emacs to show his notes and agenda in a single frame but he wished there was a way to make this happen automatically. He realized that the easiest way to do that was to write a bit of Elisp but he had neither the the time nor the inclination to learn Elisp so he looked around for another way.

His solution was to do it by hand but record his steps as a keyboard macro. Then he could save the macro and simply replay it every morning to get his desired Emacs windows configuration. He had a couple of problems but eventually got everything working.

Like most experienced Emacs users, I often use keyboard macros to automate a one-off task but I never considered using them as a substitute for Elisp. Why would I? I can write Elisp but for those who can’t—and sometimes even for those who can—macros are a really nice way of automating some frequent task. It’s yet another way that Emacs adapts itself to its users rather than insisting those users adapt themselves to Emacs.

Marcin Borkowski (mbork) has a cute post that addresses the abomination known as camel case. I use the term camel case to cover actual camel case as well as any of its illegitimate siblings such as studly caps. As I’ve said before, it makes text hard to type and hard to read with no discernible benefit.

Someone on the Emacs mailing list suggested coloring camel case identifiers so that all the odd subwords are in one color and all the even subwords in another. Borkowski took the idea and ran with it producing a proof-of-concept mode based on glasses mode. It turned out to be easy, at least for the simple cases. One thing I learned from his post is that of version 29.1, the overlay implementation was rewritten making it faster.

For me, the takeaway from Borkowski’s post is not a way of making the horror of camel case marginally more legible. It’s about how easy Emacs makes it to implement even a seemingly difficult feature. Or for that matter, to implement it at all. As I said, I have no interest in tinkering with camel case but I love how Emacs makes it relatively simple to tinker with even the seemingly low level display features. Zamanky’s ongoing project to replace certain words with an emoji is another example of this. The emojis are displayed instead of the keywords but the underlying text is unchanged.

Overlays are a powerful technique built into Emacs that can be used in all sorts of projects as Borkowski and Zamanky demonstrate.