Emacs Pretest 30.0.91

Andrea Corallo has just announced that the first Emacs 30 pretest (30.0.91) is available for download and testing. You can check the NEWS file to see what’s new in the release.

As always, thanks to Eli, Andrea, and all the other devs who worked so hard to bring us this release and who keep Emacs a vital and thriving enterprise. The release of this pretest means that the release cycle for Emacs 30 is underway and we can expect the first release candidate sometime soon depending on how many errors are discovered in 30.0.91.

The developers depend on the Emacs community to help find those errors so if you can, please download and test the new version. It will help us all and move Emacs 30 closer to the official release.

Posted in General | Tagged | Leave a comment

Casual Symbol Overlay

A couple of months ago, I wrote about Álvaro Ramírez’s gluing together of Symbol Overlay and Multiple Cursors. I was really taken with Symbol Overlay and its ability to select a given symbol for further actions. There are many possible operations and symbol-overlay lets you define your own commands for them. Of course, those commands are going to be hard to remember so it’s a perfect candidate for one of Charles Choi’s Casual apps.

Choi has, of course, stepped up to that challenge with Casual Symbol Overlay. As usual, it provides a Transient menu for those commands that you can invoke at will. You don’t, of course, have to use the menu. If you use a given command enough to remember it, you just use it but if you can’t remember the command, you can just invoke the menu and execute the command from there. It’s the best of both worlds.

At this point, I’ve just about decided to install Casual Suite so that I get all the Casual apps. You still have to configure them so they won’t be loaded unless you want them but Choi is making additions so often that it makes sense to reduce the friction of adding them. I don’t want them all but I do want a lot of them so it makes sense to add them all to my ELPA repository and configure the ones I actually want to be available.

Posted in General | Tagged | Leave a comment

Branch Prediction

Here’s a very nice discussion of branch prediction from a Stack Overflow question. We graybeards and, really, just about everyone else like to pretend that all processors are still like the PDP-11. They were easy to understand and their semantics easy to assimilate.

Modern processors are nothing like them, of course. Instead of a linear pipeline of instructions executed sequentially, modern processors like to gamble. They look ahead in the instruction stream and precalculate results so they’re ready when they’re needed. The difficulty arises when there’s a branch. What should the look ahead procedure do? Should it take the left fork or the right one.

It’s a difficult problem but there are, in fact, some effective procedures. It basically boils down to noticing what the average behavior is and betting on that. If the behavior is reasonably normal, the results are good. Most times the processor guesses right and there’s no reason to stop everything and back up like there is when the processor guesses wrong.

If you’re writing in Python or a similar high-level language, there’s no reason to worry about this. But if you’re writing in C, or some other low-level language, this is something you sometimes have to take into account.

Happily, most of us don’t have to worry about such things but it’s worth knowing that the problem exists if only to have them in the back of our minds as we write our code.

Posted in General | Tagged | Leave a comment

Babel and Python

This is a sort of Public Service Announcement. One of the great things about Org mode is the code block where you can run code in an Org buffer and have the results inserted into the Org document. I use this all the time. It’s a particularly elegant way of practicing literate programming and writing “live” documents that automatically rewrite themselves when the data the changes.

It’s usually a seamless process but there are gotchas for some languages. Sadly, Python, a widely used language, is one of those where you have to be careful. If you don’t follow the rules correctly, you can end up with erroneous results.

Recently, on the Org Mode mailing list there was a nice discussion of the problems that Python can present. As of right now, there are only three posts in the thread so you should read them all to get a full idea of what’s going on. The TL;DR is that you (usually) have to provide an explicit return in your Python code to get the correct results into your Org buffer.

Python is the only language that I use—even occasionally—that has these problems: usually things just work. It is, therefore, worth spending a few minutes familiarizing yourself with the problems that Python and a few other languages have in the Babel environment.

Posted in General | Tagged , | Leave a comment

Using .authinfo With Org Code Blocks

As most of you know, I’m a big fan of using literate programming techniques in the context of what might be described as “devops”. The technique boils down to writing an Org file with code blocks that document how you are solving a particular problem. The key is that the code blocks are executable and are what you actually use to solve the problem. Howard Abrams has a really good introduction to the idea in a post and subsequent video.

Magnus Therning has a nice nice post that expands on the same theme. His wrinkle is that the applications he’s interacting with require login credentials. For a long time, he simply kept those credentials as plain text in his Org file but, of course, he realized that was a bad thing.

He solved the problem by putting his credentials in his .authinfo file and accessing them with the auth-source library. He wrote a couple of functions that used the auth-source library to retrieve the necessary credentials. He populated these in a properties block. This is perfect because the source code doesn’t show any secrets but those secrets are made available to the executing code.

I do something similar to retrieve secrets that I don’t want exposed in plain text. The .authinfo file and associated library is a really useful set of tools to enable access to secure applications without exposing the required credentials. Take a look at his post to see how easy it is.

Posted in General | Tagged , | Leave a comment

Converting Between Miles and Kilometers

Peteris Krumins has a nice post on using Fibonacci numbers to covert between miles and kilometers. The TL;DR is that if you take any two consecutive Fibonacci numbers, X and Y, there will be approximately Y kilometers in X miles (and vice versa, of course). The approximations are amazingly precise.

There’s more. The above works only if the number you want to convert is a Fibonacci number but you can express the number you do want to convert as a sum of Fibonacci numbers and sum up the corresponding pair numbers to get the conversion. Take a look at Krumins’ post for an example.

It’s not an accident that it works, of course. The secret is the ratio of consecutive Fibonacci numbers, \(F_{n+1} / F_{n}\) converges to the Golden Ratio, \(\frac {1+\sqrt{5}} {2} \approx 1.618034\). The key is that there are 1.609344 kilometers per mile, which is very close to the Golden ratio.

Serendipitously, John Cook, a Mathematician, has a recent post on the same subject. He makes an interesting observation. The higher the value of n the closer \(F_{n+1} / F_{n}\) gets to the Golden Ratio so, naively, one expects the kilometer-mile approximation to get better too. That works for a while, but for larger n, the \(F_{n+1} / F_{n}\) ratio gets closer to the Golden Ratio than the number of kilometers per mile. Cook calculates where the ratio is the best approximation to kilometers per mile and, surprisingly, it’s at 21/13, a lower number than I would have expected.

Cook also mentions Lucas numbers, which are very similar to Fibonacci numbers except for the starting values. It turns out that Lucas numbers provide an even better approximation but, really, both methods are back of the envelope approximations so who cares.

Perhaps I find this interesting only because I’m a Mathematician but I’m pretty certain the average Irreal reader will find it so too.

Posted in General | Tagged | Leave a comment

🥩 Red Meat Friday: Should You Replace Emacs With An “AI Editor”?

Over at the Emacs subreddit, harmanola, an Emacs user of 16 years, says that he’s recently switched from Emacs to Cursor, the AI code editor. It’s his opinion that Emacs has become unstable, that he’s tired of its “non-standard defaults”, that AI can increase his productivity by 5 times, that Emacs doesn’t scale, and that its developers aren’t on Discord. He also thinks that Emacs might be history soon.

One hardly knows where to begin. Well, I may not but the commenters certainly do. If there was ever a legitimate point to harmanola’s post, it got demolished by one or more of the commenters. To me, the silliest of his arguments is that one needs an “AI editor” to be productive. It seems to me that the AI suggestions are usually just slightly better than the code generated by previous editors that offered to write code for you: great for folks who are mostly generating boilerplate but used by virtually no one else.

The silliness about the Emacs developers not being on Discord strikes me as revealing a sense of entitlement: “I would like your help but I don’t want to go where you give it; please come over here instead.” If you spend 10 minutes on the Emacs mailing list you can’t help but be impressed by how much time guys like Eli Zaretskii spend—for free—on Emacs. As one of the commenters noted, all the things that comprise a healthy development environment—bug fixes, responding to pull requests, and regular updates—are, in fact, happening.

I’m sorry to see harmanola abandon Emacs and I hope he finds happiness elsewhere but his arguments for why we should leave Emacs for an AI editor just don’t withstand scrutiny.

Posted in General | Tagged , | Leave a comment

More On Upgrading Builtins

Last month, I wrote about Charles Choi’s post on the the on package-install-upgrade-built-in variable and how it controls the upgrading of builtin packages. The TL;DR is that when it’s set to t, package.el treats builtin packages as if they had been installed like any other 3rd party package for upgrading purposes.

My first inclination was to wonder why anyone would not want to have it set to t. I could imagine some outlying cases where it didn’t make sense but mostly I’d have expected that upgrading builtin packages was what most users wanted.

Apparently not. Over at the Emacs subreddit, jonas37 asks if people are setting package-install-upgrade-built-in and the comments are revealing. It’s hard to imagine the answer would be controversial but lots of people have strong feelings on the matter.

Take a look at the comments to see what I mean. The answer, as it usually is, is that “it depends”. In short, it’s hard to automate the decision. Sometimes you want to upgrade the builtins and sometimes you don’t.

It’s easy to take the position that your editor, whatever it is, should take care of things for you, but people who do take that position are the first to complain when the algorithmic decision is not to their liking. Sadly, sometimes we just need to engage with Emacs and tell it what we want it to do about upgrading our packages. For many cases. setting apackage-install-upgrade-built-in to t is probably the right decision but sometimes not. It, as they say, depends.

Posted in General | Tagged | Leave a comment

Casual Agenda

Charles Choi is announcing another member of his casual suite: Casual Agenda. Like the other members of his suite, Casual Agenda provides a Transient driven menu that helps you navigate the arcane functionality of Org Agenda View.

I say “arcane” because although it’s easy to use Agenda View to simply list the content of the target files, there’s a lot more functionality hidden in obscure commands that even if you know they exist are hard to remember. Remembering the commands is even harder because Org makes them context sensitive.

Take a look at Choi’s post to see the menus and how they work with each other. It’s a nice system and probably worth installing even if you don’t use the commands often. Especially if you don’t use them often.

I know these command exist but I can never figure out how to access them so I’m really glad to see this latest addition to Choi’s suite. If you’re in the same situation, you should consider installing Casual Agenda.

You can, alternatively, simply install Casual Suite to get all the apps in the collection. This has the advantage that you automatically get additions to the suite when Choi adds them. All the apps have to be invoked explicitly so they never get in the way. If, like me, you follow Choi’s recommendation to bind them all to Ctrl+o, you need only remember a single command to bring up the appropriate menu when you need it.

As I’ve said before, I really like this set of applications and recommend you install the ones you need or possibly just install the entire suite.

Posted in General | Tagged | Leave a comment

Show Font

The ever industrious Protesilaos Stavrou (Prot) just uploaded another nice package to MELPA. It’s a simple little app that displays a font in an Emacs buffer but for those who are on an eternal quest for the perfect font it’s perfect.

The app displays a (configurable) bit of text—think “The quick brown fox…”—and an (again configurable) set of characters underneath. Currently, the app works only with locally installed fonts but Prot is planning to upgrade it to be able to display and install any font.

Prot describes it as a work in progress but it’s already useful and will probably become more so as Prot refines it. It’s not a big thing but it’s another nice example of how Emacs is—or can be made to be—a complete editing environment.

Posted in General | Tagged | Leave a comment