Zamansky 67: Emacs vs. Vi(m)

As promised, Mike Zamansky has published his thoughts on the Emacs vs. Vi controversy in a another video in his Using Emacs Series. Unlike Zamansky, I was a long time user of Vi/Vim before I moved to Emacs so I’m intimately familiar with both editors on a muscle memory level. Zamansky is absolutely right that neither is objectively better than the other; they both have good points and bad points and furthermore what those good and bad points are can vary with every user. As I’ve said before, choosing an editor is like choosing a mate: everyone else should butt out. Zamansky echoes that feeling and says to choose whatever works best for you but to spent some serious time with your candidates to give them a reasonable evaluation.

One of the very best features of Zamansky’s video is that he covers the history of the two editors to show how they evolved and why they are the way that are. He even gives a demo of the Teco editor, which I’ve never seen running before. He also demonstrates Ex and shows how it evolved into Vi. Most of what partisans claim are examples of superior design turn out to be accidents of history.

I hold onto my belief that Emacs and Vi are two different things: that Emacs is an entire development or operating environment and that Vi is an editor that embraces the Unix philosophy of doing one thing and doing it well and that therefore the type of workflow you are looking for should be the deciding factor. I do think that Vi’s composable keybindings are easier to learn any possibly a bit faster but that Emacs has more and better editing features and if you find one it doesn’t have, it’s easy to add it as a first class command at the same level as every other Emacs command.

This is a really excellent video. You probably won’t learn anything new—except possibly what a Teco or Ex session looks like—but the historical background and good sense suggestions make it more than worth watching. The video is 35 minutes, 20 seconds so you’ll need to plan ahead.

Posted in General | Tagged , | Leave a comment

A Comparison of Vim and Emacs

Over at the YouTube DistroTube Channel, Derek Taylor has an even handed video that explores the question Vim Versus Emacs. Which Is Better? Taylor is a n00b with both editors but has come to the same conclusion that I have: why would a serious developer not use one of these editors? The video is barely a week old as I write this so we can be sure that Taylor is aware of all the hot new coolness such as VS Code, Sublime Text, Atom, and the others but he still recommends the “ancient” Vi/Vim and Emacs editors.

Taylor starts off by making the same observation that I often have: comparing Vim and Emacs doesn’t make much sense because they are really different things. Vim is a fast, efficient editor that embraces the notion of doing one thing well. Emacs is more of a development environment that can do almost anything and ships with many built-in apps one of which is an editor.

Taylor is using the Doom distribution so he says actual editing between the two editors is virtually identical and not worth comparing. Rather, he looks at a range of other chores such as file handling, git, and invoking shells. He compares the ease of doing all these with the two editors. Oddly, he doesn’t mention the real Emacs killer app: Org Mode. Everyone here knows that I depend on Org mode and consider it one of the most important parts of Emacs but it’s not just me. Org mode is widely considered Emacs’ killer app and the gateway for many new Emacs users.

The video is 30 minutes, 37 seconds so you’ll need to schedule some time. If you’re interested in a relative new comer’s opinion on the great Editor War the video is definitely worth your time. Taylor is worth listening to because he doesn’t have any preconceived preferences and is not defending his own choices.

Posted in General | Tagged , | Leave a comment

An Org Mode Workflow for Spacemacs

Over at OutOfCheeseError there’s a useful discussion of an Org-mode workflow for Spacemacs. If you’re a member of the Spacemacs sect, you should take a look. Interestingly, the post is part of his .spacemacs file so it’s pretty much always up to date.

Even if you’re not a Spacemacs user, there’s some good ideas and useful information in the post. The author likes fancy text and symbols so he makes heavy use of org-entities and shows some examples. I already knew about org-entities-help but I tend to forget about them. It’s amazing how many there are. If you have a use for these, take a look at John Kitchin’s code to bring up an Ivy list to choose from. There’s also a version that works with Helm.

There’s also a very nice section on how he uses capture templates. He even has one for starting a blog post. Again, aside from the key shortcuts, none of this is specific to Spacemacs so all Emacs users can benefit from reading it, especially if you like to work with nice looking text.

If you’re coming from Vim, you may be surprised at what a powerful workflow Spacemacs and Org can provide. As always with Emacs, it’s all about reducing friction.

Posted in General | Tagged , | Leave a comment

Progress Report

I’ve almost completely recovered from the debacle with my old computer. At least recovered enough to resume posting to Irreal. I now have a brand new 13“ MacBook Pro complete with touch strip and bad keyboard. My old machine was 6 or 7 years old and I’d been thinking of replacing it but I was waiting for Apple to admit they made a mistake with the new keyboards and go back to the old style across their product line.
The 16” does have the new keyboard and wasn’t that much more expensive but I really like the 13“ form factor. And there’s no getting away from the touch strip so I’m just sucking that up.

I learned a lot from all this. First and most important, a robust backup regime is vital. I use Backblaze, which I really like. It’s not too expensive and takes care of backing up everything automatically. I was hoping to never have to use the restore function but my old machine was completely dead so I couldn’t migrate my environment to the new machine automatically. The Backblaze restore has several options but the easiest and fastest for me was to download a zip file. Backblaze even provides a downloader that they say is faster and safer than using the browser and it did work well. At one point there was a network problem but the downloader was able to restart where it left off.

I made the mistake of unpacking the zip file from my desktop. That was a mistake because the desktop is shadowed on the iCloud and it filled up my iCloud space as it started to expand the zip file. I aborted that and moved the zip file another area that wasn’t shadowed. After that, everything went pretty well except that some permissions and ownerships were changed and I had to fix those. Fortunately the -R option to chown made that mostly painless.

So the second lesson is that it pays to have a local backup of your important files. I’ll probably get a solid state hard drive (like this one) and maybe tie it to Apple’s Time Machine mechanism. If I’d done that before it would have been easier and faster to recover my environment.

Perhaps the most important thing I learned was that my smug assurances that I could recover in a day if Apple suddenly disappeared were wildly overoptimistic. Starting with a new machine and no old machine to help migrate your important files turns out to be harder and more finicky than I supposed. Still, my main point holds: All my data is text and I could just as easily restored it onto, say, a Linux machine if I’d needed to. It just wasn’t as easy as I thought it would be.

This is a long post but the TL;DR is that if, like me, you’re living a digital life and have important data on your computer it’s vital that you keep it backed up.

Posted in Blogging | Leave a comment

Red Alert

Last night, I managed to spill my beverage of choice onto my laptop. As McCoy would say, “It’s dead Jim.” Until I can replace it (probably tomorrow) and download my backups (who knows how long that will take) Irreal will be taking a forced vacation. See you on the other side.

Posted in Blogging | Leave a comment

Regular Expressions in 30 Lines of C

I recently saw a pointer to a nice article by Brian Kernighan that describes some beautiful code written by Rob Pike for their book The Practice of Programming. As an example of the power of notation, they wanted to show a simple implementation of regular expression matching. They couldn’t use one of the existing implementations because they were too long so Pike sat down for an hour or two and whipped out a 30-line version in C.

In the article, A Regular Expression Matcher, Kernighan explains why he thinks Pike’s creation is “beautiful code.” It’s compact, clear, elegant and implements a simple example of a real tool. If you know C or can read it, you should definitely take a look at Kernighan’s article.

If, after reading the article, you’d like to know a bit more about how regular expressions are implemented, you should take a look at Russ Cox’s posts on the subject. The first two posts, in particular discuss some of the theory and show how to implement efficient algorithms. Efficiency can be important in certain edge cases where the implementations in Perl and many other popular languages can take exponential time. Compare that with Ken Thompson’s original implementation for the QED editor from the 60s. Thompson’s version is literally a million times faster than Perl’s for one pathological regular expression and even faster for others. You can read all about that and why Thompson’s version performs so much better in Cox’s first post. The second post has a virtual machine implementation that more or less duplicates Thompson’s QED algorithm that generated native code on the fly for the matcher.

Posted in General | Tagged , | Leave a comment

Dark-Mode vs. Light-Mode Again

You’d think this would be dead horse by now but we always have fun with it when I post on the issue so here’s another episode. Via Kontra we have an article by Raluca Budiu on whether light-mode or dark-mode is better. The article is a review of the pertinent research, which turns out to be more extensive than you might think.

The really short TL;DR is that it depends. The slightly longer TL;DR is that for people with normal vision or who are corrected to normal vision, light-mode is easier to read and read accurately than dark mode. If, on the other hand, you’re a person with a visual impairment, dark-mode might be easier on your eyes.

But wait. There’s more. It turns out that reading a large amount of text in light-mode over a long period of time may lead to myopia. That’s not too surprising since myopia has historically been associated with those with more education and with prolific readers. Thus, while dark-mode may be harder to read, over time light-mode may lead to vision problems. On the other hand, for most Irreal readers I’d wager it doesn’t make much difference because they’re probably prolific readers on and off the computer screen.

So far as I can tell, the answer is the same as it was before. Use whatever is most comfortable for you to read or whatever you think is cool. It probably doesn’t make any real difference. Read Budiu’s article and decide for yourself.

Posted in General | Tagged | Leave a comment

Emacs Variables

Emacs variables are at once both easier and more difficult than in other languages. On the one hand, Emacs variables are typeless so you can put whatever you like in them and even use the same variable to hold different types at different times. Whether this is a good or bad idea is a religious issue and one I don’t want to litigate here.

On the other hand, Emacs variables can have differing scoping rules that can seem arcane and confusing, especially if you’re used to “normal” languages. The situation is more complicated than in other Lisps because Elisp also has buffer-local-variables and custom-variables with their own scopes and setting rules.

Over at (with-emacs, Clemens Radermacher has a post that gives a nice introduction to Elisp variables. It’s the first in a series that Radermacher is planning on Elisp fundamentals that he is aiming at beginners. One of the hardest things for Lisp n00bs to grasp is the difference between lexical and dynamic scoping. Dynamic variables are (much) more than just global variables and can have some surprising behaviors. As Radermacher says, the situation is exacerbated with Elisp because, for historical reasons, dynamic variables are the default and it’s only recently that lexical variables have been added. Even with their official introduction, lexical variables require some special handling. Radermacher does a pretty job of explaining all this so if you’re new to Elisp, the post is worth reading to help get you started.

Update [2020-02-16 Sun 13:25]: Fixed link to Radermacher’s post.

Posted in General | Tagged | Leave a comment

When Will They Ever Learn?

Jacob Eisenstein is wondering at the madness that has overtaken the academic world. He wonders why in the world they are depending on someone else’s computer and SaaS to do one of their most important jobs: writing and publishing papers.

For context, the ICML is the International Conference on Machine Learning and the “ICML deadline” refers to last date for submitting papers to the 2020 conference. Eisenstein’s question is well taken. These are computer scientists and using tools like Emacs and Git is certainly within their skill set. Instead they chose to depend on someone else’s computer and software, which inconveniently became inaccessible just prior to the submission date of one of their major conferences.

Most disturbing, though, is the response. I’m sure it’s true that Overleaf is great for collaboration and at least they’re writing in LaTeX—instead of the monstrosity that must not be named—but (1) we’re not talking about social and political scientists here; we’re talking about computer scientists and (2) it’s simply not true that people in the “soft” sciences can’t learn Emacs and Git. Irreal often publishes stories about people in the liberal arts and social sciences doing exactly that.

None of this is to say that computer scientists, let alone social or political scientists, must write in Emacs or collaborate through Git. The point is what it always is when I’m on this particular rant: if you’re committing writing that you care about to a third party for processing and safekeeping, you’re asking for trouble. In this case, the trouble probably wasn’t too severe but as I’ve argued elsewhere, it could have been. The answer is also the same as it always is: use open-source/open-standards software on a computer you control. Anything else is reckless.

Posted in General | Tagged , | Leave a comment

Org 9.3.6

Bastien lets us know that Org 9.3.6 has been released:

It’s another bug release but the Org 9.4 with new features is coming soon.

Posted in General | Tagged , | Leave a comment