Irreal

Planning for the 2024 EmacsConf is underway and the organizers are calling for participation. “Calling for participation” means they’re asking folks to submit proposals for talks. The conference will again be virtual and take place on December 7^th and 8^th.

If you’re interested in contributing, the organizers would like to hear from you as soon as possible but in any event by September 20. Your talk can be short (about 5–10 minutes) or long (about 20 minutes). If you’d like to give a longer talk, that can be arranged too: get in touch with the organizers.

EmacsConf is a great way to share your ideas and get some exposure. It’s virtual so there’s no expensive travel involved. Even if you are unavailable for questions on the day(s) of the conference, the organizers can accommodate that so if you think you have something to say, sign up for talk. The talks are prerecorded so you don’t have to worry about stage fright.

These conferences are a font of great ideas so whether or not you give a talk, be sure to be there. Even if you can’t be there, the talks will be available as recordings so you can enjoy them at your leisure but you won’t be able to join in the after talk discussions.

Over at the Emacs subreddit, Phovox—a 30-year Emacs user—asks what your favorite Emacs utilities are. He’s started using Doom Emacs and has discovered, through Doom, utilities that he didn’t know about. So he’s wondering what else he may have missed and is asking the community what they recommend.

Some of the answers were general things like the ability to use Emacs to change virtually any part of Emacs to suit your preferences. Others were more on point and included things like Dired, Hippie-expand, the classical version control system, Ediff, Magit, Calc, Org, Projectile, LSP, and Replace-regexp.

Some of the other commenters mentioned third-party packages such as Hyperbole and Everything.

The best advice, I think, came from Wumpitz. That is to spend some time with the Emacs manual. It’s too much to try to read it straight through, of course, but you can decide to read one chapter every day or week. It is, says Wumpitz, amazing how much you don’t know about some of the basic utilities.

All the action is in the comments so take a look to see if there’s some utility you should be using but aren’t.

There’s a great question and answers post over at the Emacs subreddit. The question, from lynnlei, asks how a prose writer who has been using Vim should approach moving to Emacs. This comes up a lot, of course, and it’s always the comments that provide value. I like reading them because I almost always learn something new about Emacs.

That’s certainly the case here: I learned about org-novelist, which will be the subject of an upcoming post even though, as I recently said, I don’t write novels. Even so, it has lots of capabilities to help with any long(ish) form writing.

The rest of the comments are interesting and helpful too. There’s no ankle biting or silliness so you might learn something useful for your own workflow.

A lot of the things we Emacers take for granted seem mysterious and marvelous to immigrants so posts like this are really useful to get new users oriented. They’re also useful to introduce oldtimers to Emacs features that they were previously unaware of.

Lynnlei said she wasn’t interested in Evil, even though she is coming from Vim, and that leads to some interesting discussions on packages that are probably best thought of as “evil-light”. Whether you’re coming from Vim are or an old-time Emacs user, there’s probably something worthwhile for you in this post. The comments are definitely worth perusing.

It’s been a slow day on the Intertubes for Irreal material but I do have something that might interest those of you who have the misfortune to be running Emacs on Windows. Just the other day, we discussed the sad fact that Emacs on Windows can be slow. Despite the tone that my posts on Windows often take, I do want Windows users to be able to enjoy all the benefits that Emacs offers.

One of the problems with Window/Unix interaction is that they made slightly different decisions about file formats. That mostly manifests itself in Windows using CR LF for EOL while Unix uses LF. This isn’t just a matter of Microsoft’s contrariness. The choice of CR LF was reasonable at the time.

Over at the Emacs subreddit, BrainFuckPlusPlus talks about another problem with using Emacs on Windows. He’s an Emacs user working in a shop dominated by VSCode users. Apparently VSCode saves files with a BOM sequence starting the file and he was trying to get Emacs to ignore the BOM by setting the Emacs coding method. He found a solution but that solution caused problems in another area.

That brings up another remarkable aspect of this story. BrainFuckPlusPlus’s question was answered by Eli Zaretskii, the main Emacs maintainer. This was an obscure question on reddit, not the Emacs-Devel mailing list, and yet Zaretskii took notice and explained what BrainFuckPlusPlus should do to resolve it.

Zaretskii, like most FOSS maintainers, doubtlessly has a job and a family demanding first claim on his time but he still found a few minutes to help an Emacs user with an arcane problem. It’s yet another demonstration that Eli and the other devs don’t get nearly enough credit.

Chris Maiorana has another thought provoking post that advocates the use of one line sentences. The idea is that each sentence ends not just with a period but with a newline. That seems a little unnatural but has a lot to recommend it.

I don’t do that anymore but I used to. I wrote two books where every sentence was a separate line. This was before my Emacs days so I was using Vim but it worked pretty much like it would in Emacs. If the sentence was long, the line would wrap to fit on the screen but the wrap was virtual, much like Emacs’ visual-line-mode. Actually, using visual-line-mode means that paragraphs rather than sentences are the single lines but no one ever thinks of it that way.

I no longer remember why I used the one-line-per-sentence method for my books. It probably had something to do with the fact that they were written with Groff but as Maiorana says, there are lots of good reasons to recommend it. You can check his post for some of those reasons.

As with most things, Emacs—and in particular Org mode—has you covered. There are commands for moving between sentences and for moving those sentences up and down. That makes it easy to switch sentences around while you’re editing. None of that depends on one line per sentence, of course, but works seamlessly if you prefer that way of working.

My view is that Emacs and Org mode do away with a lot of the reasons to use one line per sentence but, of course, you like it for some of the reasons Maiorana offers or for others, Emacs has you covered. Even if you have to mix methods, Emacs will work the same way.

Charles Choi has made good on a promise he made in his post announcing a name change for some of his early Casual packages. In that post, he said he was going to bundle all the current and future Casual extensions into a single package.

He’s honored that pledge and the new Casual Suite is available for download on MELPA. It’s the best of both worlds. If you want all the current and future porcelains, you can install the Casual Suite package. If, like me, you prefer to load only some of them, you can do that too because the individual porcelains are available on MELPA too.

As I’ve said before, these packages are a real win. The only time you need to invoke them is when you want to use some aspect of the target UI that you seldom need and don’t remember the shortcut for. The menus are never shown unless you explicitly call them.

Eli Zaretskii has announced the start of the Emacs 30 release cycle. What that means is that Eli has created the emacs-30 release branch and restricted commits to it to bug fixes that don’t affect low level code. This is the start of the process where what will become Emacs 30 starts undergoing refinement and polish.

Eli says that he hopes to release the first pretest in about a month. After that, barring any show stoppers, the release of Emacs 30.1 won’t be far behind.

If you don’t mind living on the bleeding edge, download and install the emacs-30 branch and report any problems to the development team. You’ll be helping all of us get a better Emacs 30.1 faster by doing so.

I know I always say this but it can’t be said enough: thanks to Eli and the other devs who work so hard to benefit us all. I’d double their salary but it would stay the same.