Mbork on New Emacs 29 Features

Marcin Borkowski (mbork) has a nice post about some of the things he likes about Emacs 29. Irreal has posted a couple of articles on Emacs 29 and what is coming but Borkowski’s post is different in that he just mentions a few things about Emacs 29 that he, personally, really likes. Due to our craven nature, we here at Irreal mostly shy away from using unreleased Emacs versions. Emacs—and especially Org mode—are central to our workflow so the minions and I are loath to take chances.

Still, I enjoy reading about the experiences of those—like mbork—who are more courageous. The features that he calls out are not the big things that most commenters write about but a few small improvements that make the editing experience more pleasant.

Rather than reiterate the list of those features, I’ll send you to Borkowski’s post. Go take a look. You’ll probably learn something. I, for example, learned about the long standing command (not just Emacs 29) where-is. It’s the opposite of describe-key. Instead of taking a key and returning the command, where-is takes a command and returns the keys that are bound to it.

If, like me, you’re looking forward to the release of Emacs 29, you should take a look at Borkowski’s post. It will give you a small hint of some of the nice things that are coming.

Posted in General | Tagged | Leave a comment

Building An Exercise Table From a Journal

Like many people, Simon Pugnet likes to keep a record of his exercising. His regime includes several types of exercise such as running, sit-ups, and pushups. Also like many of us, he maintains a daily journal so, of course, it made sense to record the exercising in his (Org mode) journal. He does this by adding a third level headline for each exercise under the second level headline Exercises. The first level headlines are the date so this gives Pugnet an “Exercises” headline for each day.

You may not think this is an optimal setup but it’s a reasonable one. Now, however, Pugnet wanted to generate a table of his daily exercise and maybe even some graphs. He solved that by writing a bit of Elisp, which you can see in his blog post about his setup. It would certainly have been easier to record the data in an Org table to begin with, which is what I do for things like this but I do like the idea of keeping everything in the journal and extracting the data you need for whatever project you’re working on. It take a little more work but everything is in one place and easy to find.

In any event, the reason I’m writing about this is that Pugnet’s code is a nice illustration of how to parse Org files and extract data from the entries. You can, of course, do that with regular expression search and other ad hoc methods but Org provides you with functions that take care of all that for you. It’s worth studying Pugnet’s post just to get an idea of how to do these things.

Posted in General | Tagged , | Leave a comment

John Wiegley on Emacs 29

Here’s another nice video from the EmacsConf 2022 conference. It’s John Wiegley on what’s coming in Emacs 29. As Wiegley says, it’s going to be a significant release with lots of new features.

Here’s a list (cut from the video’s timeline) of the new Emacs features that Wiegley tells us are coming.

  • Overlays
  • Eglot
  • Tree-sitter
  • Very long lines
  • SQLite
  • XInput
  • Pure GTK build
  • Drag and drop
  • Double-buffering on Microsoft Windows
  • Emoji input

The Emacs 29 release cycle is already underway and final release should be with us soon. If you want to get an idea of what’s coming, take a look at Wiegley’s video. It’s only 5 minutes 15 seconds long so it should be easy to fit in.

Posted in General | Tagged | Leave a comment

Writing With Org Mode

Chris Mariana has an interesting video on how to prevent losing files when writing in Org mode. It’s a useful post but not really enough to write about. The TL;DR is that it explains how to locate files that were saved with org-attach.

That video, though, led me to another video of his on writing in Org mode, which is an elementary introduction to writing documents with Org. Mariana begins by noting that a big advantage of this approach is that you’re writing in plain text and that brings many advantages such as easy version control, flexible export, and others. And, of course, although he doesn’t mention it, the avoidance of lock in: your plain text document will always be readable even if you change text editors or yours disappears.

From there, he moves on to the basic structure of an Org document and some of the ways to manipulate it. Org, of course, can be thought of as two things:

  1. A lightweight markup language
  2. An Emacs mode that implements many features including an easy way to edit and operate on Org documents from within Emacs

Mariana’s video is more about the second of those although he does cover a few of the markup features. He also shows some of the flexibility of the export system. You won’t become an expert in writing with Org from this video but it does gives you a good feeling for what the process is like and why you might want to find out more.

The video is 17 minutes long so plan accordingly.

Posted in General | Tagged , | Leave a comment

Red Meat Friday: Where Your Editor Runs…

…and what it says about you.

I’m sure we Emacers can all agree on the conclusion that “We are not the same.”

Posted in General | Tagged , | Leave a comment

Academic Writing in Emacs

I recently came across this post by Chung-hong Chan on academic writing in Emacs that really annoyed me. It’s not anything that Chan said that put my back up but rather a common supposition that he mentioned that I and almost everyone else seems to accept uncritically. That supposition is that of course we can’t ask our project collaborators to learn Emacs and Org mode. No, it’s incumbent on us to learn Word or Google Docs instead.

You know what? I’m over that nonsense. I’m not going to write in Word and if you want to collaborate on a paper or article with me it’s going to be in Org mode, Markdown, or even LaTeX but not some brain-dead word processor like Word. Even if—heaven forfend—our target publisher requires Word, I will insist on a rational development language that we can convert to Word as the last step.

Really, do you want to collaborate with people who say they don’t have the necessary cognitive cycles to learn Emacs? Of course, they do have those cycles but they’d rather have you inconvenienced than them. Just say no.

Chan introduces the notion of “highest common factor” to justify Word as the lingua franca of collaboration but I submit that it’s really the “lowest common factor” and that serious collaborators should level up to at least Markdown rather than insisting everyone else stoop to Word.

Again, I’m not objecting to Chan’s article—which is, in fact, a nice exposition of how he uses Emacs for academic writing—but rather to the notion that it’s somehow incumbent on those of us using a rational writing environment to defer those who aren’t.

Posted in General | Tagged , | Leave a comment

RMS On What He Wants and Doesn’t Want in Emacs

RMS presented a talk at the EmacsConf 2022 meeting on what he’d like to see and not see in Emacs. His first point was to dismiss the idea of replacing Elisp with something like JavaScript. Besides the technical infeasibility due to the vast repository of packages written in Elisp, RMS notes that these languages are not as powerful and useful as the Lisp dialects and that it would be foolish to switch even if we could.

RMS takes this opportunity to deliver a mini-jihad about JavaScript. Everyone loves to hate JavaScript, of course, but it’s hard to see how it can be blamed for its misuse in browsers. Had the JavaScript niche been filled by Scheme—as almost happened—would Stallman still blame Scheme itself for its misuse?

He discusses many possible ways to change Emacs but to me the most controversial is his desire to support a WYSIWYG word processor in Emacs. I have never understood why anyone would want to do this and I am definitely against it.

Such editors never live up to their promises and almost always fail to deliver decent final documents. Further, they reduce the user’s control over the final output, something that RMS criticizes modern Web browsers for earlier in his talk. There is no real need for such a thing. Org mode provides any easy way to produce excellent looking documents—typeset with Latex—with a very lightweight markup language. It’s easy—certainly easier than with something like Word or its evil siblings—for a casual user to use it to produce letters and simple documents but it can also be used to produce complex and sophisticated documents.

Worse yet, what would a file produced by such an extension look like? It certainly wouldn’t be plain text; it would be a proprietary—albeit open source—format. Who needs or wants that? And, of course, it would set up a feature race with Word and similar ilk that would lead to further bloat and incomprehensibility.

And who, exactly, is the constituency for this feature besides Stallman? I’m pretty sure that there’s not a single user out there who is thinking, “I’d use Emacs if only it had a WYSIWYG word processor” and I’d be surprised if there is any significant number of Emacs users who want such a thing.

In any event, it’s interesting to get Stallman’s (up to date) views on these issues. The talk is 17 minutes long so plan accordingly.

Posted in General | Tagged | Leave a comment

IDEs

Renato Athaydes has an interesting post about his use of IDEs and how they are resource hogs and have a hard time operating on any but the most high powered machines. Most of you know by now that I’m not a fan of “IDEs”. That may seem strange given that Emacs is the apotheosis of an IDE. IDE, after all, stands for Integrated Development Environment and Emacs is nothing if not that. It integrates just about everything a developer needs to do including editing, compiling and testing, debugging, version control, RSS and News feeds, Email, documentation, and much more.

But when I hear the term IDE I immediately think of monstrosities like Eclipse, IntelliJ, and VS Code. Images of those stupid completion boxes popping up as I type come to mind and make me shudder. I’ve always felt that if you know the language you’re writing in, you don’t need your editor trying to autocomplete everything as you enter it. To me, it just feels like it’s getting in the way. I understand that that’s a minority position but it’s mine and I claim it proudly.

That brings us back to Athaydes’ post. He’s a dedicated IntelliJ user and wouldn’t consider using anything else for his professional development. For his personal work, though, he uses a lower powered 2019 MacAir and IntelliJ became unusable. Therefore, he turned to Emacs for that computer. He found that in most respects it was a good IDE but he didn’t like it as much as IntelliJ.

My laissez faire attitude about the choice of editors is well known so I have no problem with Athaydes’ choices but I really don’t understand why someone would choose a heavyweight editor that pops up annoying messages, is not free in either sense of the word, and is not truly extensible instead of using Emacs. Still, different strokes for different folks as the Hippies used to say.

Posted in Programming | Tagged | Leave a comment

Debugging Elisp

Jon Eskin has a revealing post that shows how easy it is to use the Elisp debugger. The debugger, Edebug, is documented in the Emacs Lisp manual so of course it’s always available in your Emacs session.

What I liked about the post was that it shows how easy it is to use Edebug to solve a problem even if you don’t really know the code base. Usually when you think about a debugger, there’s a supposition that it will be complex, hard to use, and have lots of mysterious commands. Eskin’s post shows otherwise.

The entire debugging session involved two commands. First, the suspect function is intrumented with Ctrl+u Meta+Ctrl+x so that Eskin could step through the function and see what it was doing. It turned out that a variable was being unexpectedly changed. To track down the culprit, Eskin put a watchpoint on the variable and was able to see exactly what was changing it. After that, the problem and its fix was obvious.

There’s more to Edebug, of course, but it’s amazing how far you can get with just the two commands that Eskin used. Notice that Eskin wasn’t writing Elisp code, he merely wanted to track down a problem in existing code. That shows that Edebug can be useful to many different types of users. If you aren’t already familiar with Edebug, take a look at Eskin’s post and then read over the Edebug chapter in the Elisp manual.

Posted in General | Tagged | Leave a comment

Plan 9: If It’s Not Broke, Don’t Fix It

I just came across an interesting article that appears to be from Francesco Nidito—although I’m not sure about the provenance—concerning the Plan 9 operating system. The gist of the post was that Plan 9 was a brilliant piece of software but that it didn’t solve any real problems.

The most salient example of this was Plan 9’s fulfillment of the Unix promise that everything is a file. Unix broke that promise as soon as networking was introduced and the socket interface was implemented. Plan 9 provided a much more Unix-like networking interface that made networking connections look like files. The problem, according to the post, was that no one considered the socket interface a problem. Most users didn’t consider Unix broken in any significant way.

I have a couple of problems with the post. The first is the assertion that Plan 9 failed because AT&T didn’t have any experience in selling software. That was true—perhaps even more true—when Unix was introduced, yet Unix survived and thrived. It had all the same problems concerning incompatibility and the need to reprogram existing applications that Plan 9 had yet was successful.

Far from never hearing about it, I actually had a running Plan 9 instance and contra the article it had at least two excellent code editors, Acme and Sam. What it did lack and what I consider its fatal failure—and my second problem with the post—was its lack of a Web browser. If it had had one, Plan 9, like Linux, could have gained traction in the nerd community and leveraged that to more a general acceptance. Being able to browse the web is the sine qua non for any workstation OS these days so Plan 9 was going nowhere without one. Oddly, the Plan 9 faithful never considered this a problem worth solving and as a result Plan 9 lives on mainly as Plan 9 From User Space, a port of many of Plan 9’s tools and libraries to other operating systems.

It’s too bad. Plan 9 was a better Unix and it’s program from anywhere paradigm was a powerful and compelling feature. It’s too bad it didn’t succeed.

Posted in General | Tagged | Leave a comment