Irreal

Lars Ingebrigtsen has an interesting post that discusses writing WordPress blog posts in HTML. Why would you want to do that? Ingebrigtsen’s answer is that the alternatives are harder to use. In particular he says that markup languages are as hard, or harder, to use than raw HTML.

Even though he’s an Emacs user, he frames the discussion in terms of Markdown instead of the much more capable Org mode. Ingebrigtsen makes the point that writing a Markdown link is pretty much the same as writing an HTML link but Emacs/Org-mode makes all this easy.

First of all, you can simply ask Org to insert a link and it will query you for the link and associated text and then format and insert the Org actual link for you. I can’t remember the last time I actually hand-formulated an Org link. But it gets better. In most cases I want to link to a Web page and I have a function that extracts the link and queries me for the associated text. That’s much easier than doing the same thing with raw HTML.

A lot of his post discusses the problems of dealing with images in posts. He uses ewp to deal with this and other matters of dealing with HTML. The Org mode solution is org2blog which seamlessly handles images and the formatting of an Org buffer into to a WordPress blog entry.

I don’t begrudge anyone the ability to write in raw HTML but I don’t think it’s true that it’s easier than writing in Org. On the other hand, one nice thing about ewp is that it can take a screenshot of everything that’s linked to so that it’s easy to see it by just hovering over the link. That helps deal with linkrot.

In any event, it’s an interesting post and worth taking a look at if you feel that you’d like to write in raw HTML.

I have family visiting so this is another short post. Charles Choi has an interesting tip for Emacs emoji users on macOS. I rarely use emojis anywhere but in texts so I wasn’t aware of Emacs facilities for choosing emojis. It turns out that emoji-list will work on any Emacs installation but that there’s a better system on macOS. That’s ns-do-show-character-palette, which pops up the usual macOS emoji picker.

If you use it a lot, it makes sense to bind it to a key sequence shortcut. Choi prefers to do this sort of thing from the menu system but, sadly, ns-do-show-character-palette is not in the Edit menu by default. It is, however, easy to add it and Choi’s post shows us how to do that.

If you like to add emojis to your emails, say, you use something like Mu4e or one of the other Emacs Emacs clients, and you’re on macOS you will probably find Choi’s post useful.

Just a quick post about a short note from Marcin Borkowski (mbork) concerning searching for the thing at point. Despite using Emacs for over 18 years I didn’t know about isearch-forward-thing-at-point.

As mbork says, it does just what it says. You invoke it with Meta+s Meta+. and it searches forward for whatever the point is on. This is something I want to do all the time and I was vaguely aware that it was possible but didn’t know exactly how to do it, so I’m really glad to see mbork’s post.

Finding out about this now serves to emphasize that learning Emacs really is a lifelong journey.

Everyday I see several articles from—usually—younger developers opining that Emacs is too old-fashioned, non-intuitive, and, really, just too hard to bother learning. And, it doesn’t look nice like VS Code and other modern editors.

Okay, they’re young and don’t know any better. Maybe they’ll learn as they go along. But there are also older developers who have been using Emacs for years who say they’ve been seduced by the bling, and lately, AI integration. They too are choosing to use editors other than Emacs.

One would think, from reading all those posts, that there’s a one way current flowing from Emacs towards those lesser other editors. But that’s not true. There are still people who get a hint of Emacs’ power and make the effort to learn it. Ivan Prikaznov is a case in point.

He came into an IntelliJ shop as a green engineer so, of course, he used the IntelliJ IDEA editor like all his colleagues. But then he stumbled on Vim and learned about efficient editing. Eventually, he changed jobs and found himself editing a large configuration file. He realized that he was “essentially executing an algorithm by hand”. At that point he grasped that what he needed was a programmable editor and he turned to Emacs.

He hasn’t looked back. Now he does everything in Emacs and the Borg has assimilated a new member. Or something. In any event, it’s nice to know that Emacs is also gaining converts. It may not be a rapidly as the “in” editors but we’ve always known that Emacs is for the discerning.

Continuing with our “Emacs for all things” theme of the last couple of days, here’s another post that speaks to how Emacs can be used for many things and how seemingly difficult or even impossible tasks can be done by using the right packages.

The topic of the post is using Emacs for taking research notes. S4h4rJ says that he loves Emacs but that he finds it hard to use for taking research notes because it’s so hard to deal with figures (jpegs, etc.). They are, he says, hard to size and hard to place within the file.

That didn’t seem right to me and other researchers chimed in explaining how they handled the problems that S4h4rJ was complaining about. It’s surprising how often the answer is simply installing and using an existing Emacs package.

The TL;DR is that there are many researchers who use Emacs to take and organize their notes. They use things like org-download and org-roam to deal with problems specific to their workflows. Take a look at the comments to S4h4rJ’s post for the details.

The takeaway is lots of serious researchers are using Emacs everyday for taking and organizing their research notes. If you’re a researcher and want to use Emacs, there’s no reason you can’t. You just need to be aware of a few packages and techniques that ease the process. Read the comments to S4h4rJ’s post to get an idea of what’s available. Even if you’re not a researcher, you may find those packages useful for your own workflow.

One of the odd things about writing Irreal is that I never know which posts will be popular or at least provoke some engagement. Often, posts that I think are really interesting receive no comments and posts that I suspect will be of marginal interest strike a chord with readers.

Yesterday’s post, Reasons You Can’t Use Emacs More, is an example of the latter. I wrote it mostly because I was enraged by the idea of people who don’t use editors telling people who do which editors they can use. I didn’t expect most people to care but there are, it seems, a lot of our colleagues suffering from that and they are, likewise, enraged.

Of course, they’re hackers and often find ways of bypassing the nannies. But not all the problems are caused by the nannies. Often, the issue is finding some way of a way of performing a necessary task with Emacs. This usually arises when the “normal” app for performing some task won’t interoperate with Emacs.

Serendipitously, I found this Emacs subreddit post by arni_ca asking what sort of tasks people perform with Emacs. That seems only marginally related to JTR’s problems from yesterday’s post but when you read through the comments you find lots of ways people have found to do things in Emacs even if it doesn’t seem possible at first glance.

It is, really, an encouraging post because it shows that it’s very often possible to find some way of importing an important task into Emacs. The real problem is discovering those methods. Posts like arni_ca’s help but that still means reading through a lot of blogs and reddit posts to find them. Sacha’s Emacs News is a good place to start. It provides a weekly review of interesting Emacs news and helps keep you up to date with minimal effort.

Over at The Art Of Not Asking Why, JTR has some nice things to say about Irreal but that’s not what I want to talk about. Rather, I like to address the point of his post, which is how difficult it can be to use Emacs as much as he’d like.

There are two main issues. The first is work problems. Lots of companies make it difficult to use anything other than “approved applications”. These are almost always brain-dead Windows apps that don’t work all that well and certainly don’t interoperate with others apps.This sort of thing is usually driven by what my son calls the “Notwork Nazis”, his term for the network engineering folks having an obsession with making sure that not a single unauthorized activity takes place on “their” network.

These guys don’t—usually—care what you do on your own machine as long as it doesn’t impinge on the network. There are, sadly, more extreme cases. Consider this case of of a company so clueless and intent on controlling every aspect of their employees’ work environment that you can’t use Emacs at all because it’s “An old fashioned and slow text editor created by Canonical for use with the Ubuntu operating system.” These morons are actually scanning machines to make sure no unauthorized editors are being used.

There are many degrees of this dysfunction. If it’s only that you can’t access company Email through Emacs, that may be tolerable. If your management thinks Emacs was developed by Canonical, it’s probably time to find another job.

The second problem that JTR encounters is that Emacs doesn’t interoperate with some apps that are important in his workflow. He gives the example of Grammarly. Being a curmudgeon who doesn’t like being told what to do, I’m not a Grammarly user but I take JTR’s point.

These apps obviously have an API so they can interoperate with others apps but sometimes they’re loath to share them. I’m not sure why that’s so. Wouldn’t you want your app to work with as many other apps a possible?

In any event, it’s a sad truth that it’s not always possible to use Emacs as much as you’d like.