Irreal

If you’ve been using Org-mode for a while, you’re probably familiar with its table editing functionality and may even know that you can use that functionality anywhere in Emacs with orgtbl-mode. For most non-Org applications, of course, those tables will be in some sort of comment.

Andrew over at the Listful Andrew site has a useful post on how to do that. It’s a little more finicky than you might think because the editing won’t work if the table lines are commented out. It’s easy to work around that, of course, but Andrew offers some other strategies.

When you’re in Elisp, the easiest way to add a table to a comment is to add it do a Docstring. That’s easy and the table can be edited at will. Andrew offer another method using his custom description macro. Most of us won’t have that macro, of course, but it’s another strategy.

Finally, Andrew considers adding tables to Bash comments. The problems are similar to those encountered with Elisp: you can’t edit tables whose rows are commented out. As with Elisp, that’s easily worked around but again there are better ways.

One way is to use the null command : to introduce the comment string. See Andrew’s post for the details. Another way is to use a here document or a here string. Again, see Andrew’s post for the details.

Tables in comments isn’t something that you need all the time but it’s nice to have to ability to add them when you do. Andrew’s post is a nice demonstration of how to do that.

Here’s some good news for iOS/macOS developers who are also Emacs users. Until now, the only reasonable way to develop for iOS was to use Apple’s Xcode. Xcode is a perfectly good editor and has the necessary integration to make it easy to develop for iOS but it’s not Emacs. I’m pretty sure that most Emacs users would consider it a tax on iOS development.

Now, thanks to Mikael Konradsson, there’s an alternative. For the last couple of years, Konradsson has been working on moving Swift development to Emacs. That’s harder than you might think because he also had to provide the interfaces to the previewers, simulators and build tools that are important in iOS development. It even has an interface to the Apple documentation system.

Take a look at his post to see a list of its features. His GitHub repository has even more information. Konradsson describes it as still Alpha quality software but he has been using it for his own development during those two years. One of the commenters asked if it was on Melpa and Konradsson said that he felt it needed to mature a bit more first. The paranoid may therefore want to wait a bit but it’s hard to see any harm in checking it out.

One of the reasons I’ve never ventured into iOS development—despite occasional itches to do so—is that the thought of learning and navigating the Xcode system seemed too daunting. Even using Konradsson’s package, it probably wouldn’t be easy for the newcomer, but at least it would be Emacs. I’ll be interested to see how this package plays out. If it lives up to its author’s description, it could be a game changer for Emacs iOS developers.

Álvaro Ramírez is back with the fifth episode of Bending Emacs. This video is about Ready Player Mode, his version of a media player in Emacs.

A year ago, Ramírez mostly moved away from streaming his music and went back to buying and playing his own copies of the music he liked. Of course, he wanted to do this from Emacs so he wrote his own Emacs-based music player. As Ramírez says, this is less of an effort than you might suppose. He leveraged Dired to keep track of the files and mpv or one of several other music players to do the actual playing.

You can get a comprehensive tour of Ready Player Mode here. The main point, at least from my point of view, is that you can move one more task into Emacs. That said, I’ve been lazy and still haven’t arranged to play music from within Emacs. I’m still using the Apple Music App for that. Partly that’s because some time ago I moved all my music to the iCloud so that it would be available on all my devices but mostly it’s because I’ve been too lazy to move the playing interface into Emacs.

Regardless, if you’re looking for a way to move media playing into Emacs, take a look at Ramírez’s video. It seems like a nice solution.

If you write in Elisp, Edebug, a source level debugger for Elisp, can be a real help in debugging your code. The problem is that it’s fairly hard to use and has no UI to speak of other than opaque command keybindings.

Charles Choi has long been bothered by this and has tried to fix it. His first thought was to provide transient menus for the commands but the transient menus interacted badly with the Edebug windows. Then he had an Epiphany: what Edebug needs is a toolbar. That would be in accord with the way most other debuggers work. Even when there are command shortcuts, the toolbar aids in learning and discovery.

As much as I hate using the mouse and toolbars, I have to admit that Choi has a point. I, for one, don’t need Edebug often enough to internalize the command shortcuts or even what’s possible. A toolbar can really help with that. Take a look at Choi’s post to see a screenshot of his toolbar in action.

Choi says that his toolbar is still a work in progress and lists several caveats. One of those is a bug in the NS variant of Emacs, which will, presumably, be fixed in an incoming release; bug reports have already been filed. Another problem is the licensing of the symbol fonts used in the toolbar: they are not GPLv3 compliant. There are some other nits, as well but nothing that should preclude you from trying it out.

Choi is still thinking of it as a proof of concept but if it helps you debug your Elisp code, there’s no reason not to give it a try. If you discover issues, let Choi know.

Serendipitously, my old pal Watts Martin posted his thoughts on everything in Emacs at about the same time that I did. Martin says that before he got into Emacs, he considered this “profoundly weird” but now he’s beginning to see the point.

His sticking point is one I understand and also had to overcome. He, like me, lives in the Apple ecosystem which means that Emacs is available only on his Macs not on his iPhone or iPad. Of course, that’s pretty much true of the Android ecosystem as well. Yes, I know about the Emacs port to Android but, really, do you want to use Emacs on your phone? What would be ideal was if Emacs were available on iPads and Android tablets. That’s theoretically possible on Android tablets but Apple has a firm “no interpreters” rule for iOS apps.

In any event, Emacs is pretty much restricted to our laptop or desktop computers. My main area of contention is my RSS feed, which is effectively restricted to Emacs. I don’t consider that a big problem—especially considering the excellent Elfeed app—but some might. Note taking is covered nicely by the wonderful Journelly but for messaging I’m still effectively restricted to Messages. Email is not a problem. I can read and write Email in Emacs but I can also use any of the Apple mail apps. They all deal with Apple email. As Old El Paso asked, why not both?

The big area is, of course, browsing. Yes, it’s theoretically possible to use Emacs for browsing but as Martin says, “the options for doing so range from bad to bad”. So for now, all but the most rabid Emacs users are consigned to using Emacs and the browser.

Martin, of course, is doomed. He’s already allowing that he may try moving email into Emacs. Once he even considers that, he’s already stepped into the quicksand and there’s no escape. Before long he’ll be wondering why the heck he can’t browse from within Emacs.

A couple of weeks ago, I wrote about Álvaro Ramírez’s time-zones package. It’s a package that expands on the built in world clock function by allowing cities to be added and deleted on the fly and by allowing the target time to be adjusted forward or backward.

When I wrote about it, it had just been released and was not yet on Melpa. Now, thankfully, Ramírez has added it to Melpa and made some enhancements, such as implementing DST and UTC. The original Irreal post got a couple of comments from people who have installed it and they seem happy.

Ramírez is an independent developer and provides apps such as time-zones as a public service. You can download and use it for free but it’s also important to support his efforts. The best way of doing this, I think, is by buying one or more of his paid apps such as Journelly, which I’ve written about many times. I use it constantly, several times a day and, at this point, couldn’t live without it. You’ll be helping Ramírez and yourself by getting a copy. If you don’t want to buy one of his apps, you can become a sponser.

As most of you know, I’m a true believer in the idea of “living in Emacs”. I’ve imported every task possible into Emacs to the point where virtually all my tube time is spend either in Emacs or my browser. My third most used application is Apple’s Messages but it’s a distant third. Everything else gets immeasurably small use.

This has always seemed right and obvious to me. At the same time I’ve always been dismissive of the newer notion of living in your browser. Why would anyone—other than Aunt Millie—want to do that, I thought.

Then I read this Daring Fireball post on ChatGPT Atlas. Gruber is not a fan for reasons you can read in his post if you’re interested but the thing that resonated with me was this quote:

But, for me, my browser is not "where all of [my] work, tools, and context come together". I use an email app for email, a notes app for notes, a text editor and blog editor for writing and programming, a photos app for my photo library, a native feed reader app for feed reading, etc.

When I read that, I thought, “See? That’s why I live in Emacs. Who wants to deal with all those separate applications?” And then I thought, “You know, I could make a blog post out of that.” Of course, as Paul Graham said, writing down your thoughts usually reveals that you didn’t really understand them. That’s what happened to me. As I started to lay out this post, I realized there was a contradiction. Why is living in Emacs a self-evident good and living in the browser something only Aunt Millie would do? More generally, if you’re going to have one app to rule them all, why should it be Emacs?

It’s a reasonable question but there’s a good answer. In a sense, all my Emacs posts are answers to that question. Let’s restrict the discussion to just Emacs and the browser. It doesn’t seem to me that there are any other serious contenders.

When I’m in Safari there’s not much I can do to adapt it to my way of working. Sure, there are some UI adjustments and other settings to tweak and I can even use emacs-everywhere and Vimari but basically I have to work the way the browser authors thought I should. Even if I were using, say, Firefox, which is open source and theoretically open to user change, browsers are sufficiently complex that user modifications are not a realistic option.

Emacs is different. Even putting aside its extensive user level configurability, it’s easy to modify the way any particular function works. You can make your desired changes, install the source in your init.el and those changes will be reflected whenever you load Emacs. Similarly, you can write entirely new functions in the same way. You don’t need to understand everything about Emacs to do this, only enough Elisp to express your desired behavior and a few simple rules to install it.

My conclusion is that I’ll continue living in Emacs and that Aunt Millie and other non-serious people are welcome to live in the browser.

Mahmood over at λ mental has a surprising post concerning the time to load and parse Org files. What was surprising to me is that a method I would have expected to take longer was actually much faster. Here’s a couple of statistics from Mahmood’s post:

where quick-way is

(defun quick-way ()
 (with-temp-buffer
 ;; the final `t' is to replace contents of the temp buffer
 (insert-file-contents "/home/mahmooz/brain/notes/1707069432.org"
 nil
 nil
 nil
 t)
 (let ((major-mode 'org-mode))
 (org-element-parse-buffer))
 nil))

As far as I can see, after a quick scan, find-file-noselect calls insert-file-contents after a bit of preprocessing but nowhere near enough reprocessing to account for the huge time difference. My unconsidered expectation was that it would be the other way around (insert-file-contents calls find-file-noselct), which explains my confusion. But I still don’t understand where the difference is coming from. Doubtless if I bore down a bit or (gasp) actually did some profiling I could find out but I’m enjoying being mystified and—truth to tell—am too lazy to track it down.

In any event, that little mystery is only part of Mahmood’s post. His main complaint was that loading his Org agenda and Org Roam files was taking too long. The above observation turned out to be the crux of the matter and Mahmood provides some code to load and parse Org files much faster than the default methods.

JTR over at The Art Of Not Asking Why has a post that explores why Emacs is the right thing. He begins with a story of a Porche owner who often has to drive in countries that require cars to have right hand drives¹ . Rather than give up their beloved Porche, they simply modified the car to have an adjustable steering wheel that could be set to either side.

JTR, of course, compares this to using Emacs. Others may lay down restrictions but with Emacs you can simply change it to adapt to those restrictions. As JTR says, sadly, for a lot of apps, configurabilty boils down to choosing between light and dark modes. Those apps force you to work the way they want you to. They give no thought to how you like to do things; they provide a solution and you have to use it whether you like it or not. These apps present a mental challenge: you have to do things that aren’t natural to you in order to work with them.

An example that JTR gives is date formats. Apple apps and many others prefer the US date format but the YYYY-MM-DD format is clearly superior. For one thing, it will sort dates correctly. I think of it as being like the Chinese personal naming convention of Last Name followed by first name. It’s the same principle of stating things in order of more general to more specific.

The main point is that Emacs allows you to adjust it to work the way you prefer. That’s sadly lacking in the majority of applications.

Ediff is a thing of beauty. It provides a way of not only seeing the difference between two files but for merging various differences into a third combined file. It’s very powerful and flexible. The problem is that using it can seem extraordinary complex. There’s a command menu that may or may not appear in your current frame but even if it does there are a plethora of options most of which are unfathomably opaque.

Charles Choi is once again easing our pain by providing a transient menu that tries to bring sanity to the confusion. His new package, casual ediff, tries to cut through the confusion. Take a look at his post to see causal ediff in action.

Ediff is really powerful and every Emacs user should be able to use it. Choi’s casual ediff can help with that but as I learned from this video from Prot, you can ignore most of the complexity of ediff. There are really only a very commands that you need to know. As I said in my post about Prot’s video:

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.

If you’re casual suite user, by all means include casual ediff in your repertoire but if you’re not and just want to make using ediff as simple as possible, take a look at Prot’s video.