The Holy War

After writing yesterday’s post on Vim vs. Emacs, I serendipitously saw a tweet pointing at the Wikipedia article on the Editor War. It describes our holiest of holy wars and gives a pretty thorough analysis of both sides’ views.

The article is also useful as a comparison of Vim and Emacs. It lists the strengths and weaknesses of both editors as well as the jokes the partisans make about them. If you worship in the Church of Emacs, you’ll probably enjoy Bill Joy’s 1999 comment that vi was written for a world that doesn’t exist anymore and that Emacs was written on and for much more capable machines. There’s a bit more to the quote that’s worth taking a look at.

Both Vimmers and Emacsers will take comfort in the article’s noting that one of the major arguments in favor of vi, its much smaller footprint, is pretty much moot because both Vi(m) and Emacs can be considered light weight compared to modern monstrosities such as Eclipse.

As I said in yesterday’s post, no one takes the argument seriously anymore other than for its entertainment value but the Wikipedia article gives a nice history of the war and its major points. It was fun to read it. If you have a couple of minutes, take a look and enjoy one of the sillier parts of our shared history.

Posted in General | Tagged , | Leave a comment

Vim vs. Emacs

One of our longest standing holy wars is Emacs versus Vim. I’ve been around long enough that I’ve seen all the jokes and memes. Seen them over and over again, in fact. At this point, I doubt anyone is even serious about the debate; they just throw out the same old arguments for the fun of the troll. Still, occasionally someone tries to bring a little light to the squabble.

I’ve written before about my thoughts on the war. Vim and Emacs serve two different constituencies and you pick the one that meets what you want from an editor: Vim if you’re looking for a fast editor that does one thing (editing) well; Emacs if you want an operating environment or, as I like to say, a recapitulation of the Lisp Machine.

David Morelo has a nice post that makes an honest assessment of the two editors’ strengths of weaknesses and which you should choose. I pretty much agree with what he has to say. In the past, I would have agreed with his statement that “[f]or pure text editing, Vim is usually faster…” but I’m no longer sure that’s true. Certainly Vim, with it’s composable command set can take less time to invoke an editing operation that is common to both editors but Emacs has a much larger command set and an individual user can, of course, add any command they like. Given that, I’m pretty confident Emacs can be faster for some editing jobs simply because it has a more powerful command set.

Or maybe not. As I said, it doesn’t really matter. If you want an editor that edits your files quickly and easily and the idea of playing Tetris in your editor seems bizarre, then Vim is your editor. If you want a complete operating environment in which you can perform most of your tasks, then Emacs is for you. The real argument is not which editor is better but which workflow is more effective.

In any event, read Morelo’s post and see if you don’t agree with what he has to say.

Posted in General | Tagged , | Leave a comment

The First Rule

For many years I had the good fortune to work with a small team of very talented software engineers. The team stayed together across many jobs working for many different companies. Our work was always related to computer networking and communications.

We had what we called “The Three Rules.” They weren’t really rules so much as aphorisms or perhaps rules of thumb that were surprisingly helpful in getting our job done. The first rule, also known as the prime directive, was “It’s always the cable.” The meaning of that was that when you’re having network problems it’s almost always because of a cable that needs to be replaced. You can think of it as analogous to the police rule that in a murder case you always look first at the spouse as the perpetrator. It isn’t always true but it turns out to be correct much more than you’d think it would.

The problem with the first rule is that we were always forgetting it. A network problem would occur and we’d waste time looking at all sorts of things that weren’t causing the issue. Finally, one of us would chant, “It’s always the cable” and sure enough when we replaced the cable the problem went away.

I’d been thinking lately that in our new wireless world where cables are eschewed, the first rule might not be applicable anymore or at least not with such force. The gods, of course, punished me for my apostasy.

I wrote the other day about the problems I had restoring my network connection after a lightning strike. I didn’t go into detail about the difficulties I had getting the new WiFi router working but the major issue was that it wouldn’t talk to the firewall to which it was connected. I spent most of the day chasing down what I believed the problem might be but got nowhere. Then in the back of my mind a little voice said, “It’s always the cable.”

Now I didn’t think that could be the case because that cable had been working just fine with the old router. All I did was unplug it from the old router and plug it into the new one. Of course, when I switched out the cable everything started working. That’s always the way the first rule works. You have a nice rationale for why this time it doesn’t apply but learn to your sorrow that—yes, actually—it does apply. That’s why it’s the first rule.

I’m telling you this story in part because I think it’s amusing but mainly to spread the dying wisdom embodied in the first rule. If you’re having a network problem, check your cables first.

Posted in General | Tagged | Leave a comment

Making The Results Block Executable

Over at the Emacs Stack Exchange, shackra asks how he can make the RESULTS block of an Org babel SRC block executable by the shell. In other words, he wants to build a shell script in one block and be able to execute the resulting shell script in another.

That turns out to be really easy and Xu Chunyang provides a very nice answer: simply use the :wrap keyword in the first block to wrap the RESULTS block in a new Org src code block. Follow the above link to see the exact details. As I say, it’s easy and can be very convenient. Needless to say, you can make the results executable by any of the supported languages, not just shell.

When I read the Stack Exchange query, I remembered that I once knew about :wrap but had completely forgotten about it. Then I thought that I vaguely remembered writing about it but I couldn’t find any mention of it in my archives so perhaps I’m imagining the whole thing. In any event, if you’re a Babel user, it’s worth knowing about the :wrap keyword. If you like the idea of programs writing programs, here’s a great technique for doing so from within Org-mode. Very nice indeed.

Posted in General | Tagged , | Leave a comment

Fun and Games

For those of you living in saner parts of the world who might not know, the Irreal International Headquarters are located in Tampa, Florida, which is recognized as the lightning capital of North America. Indeed, Tampa comes from an Indian word meaning “lightning.” Last night, Tampa was living up to its name with more severe than usual thunderstorms. About 10 PM our time, there was a strike right above our house that sounded more like a large gun than the usual thunder clap. Afterwards, all the TVs, cable boxes, and cable modem for the Internet were DOA. My trusty Apple WiFi router was clearly suffering but I hoped it was just unhappy about not seeing the network.

I spent all day today dealing with just trying to get the Internet up again. First I went to Spectrum to change out the modem. Everybody in Tampa was there doing the same thing and it took at LONG time just to talk to a representative. Once I did, though, it was only a couple of minutes to get a new modem.

Then home to plug in the new modem and get things going again. Sadly, the WiFi router refused to talk to the modem so it was off to Best Buy to get a new WiFi router. I’ve heard great things about the Eero routers and Best Buy did carry them. Of course, when I got there they were out of what I needed so I grabbed a Netgear router and went home to hook it up.

The horrors that followed would take a book to relate so I’ll merely say that after much hair rending and some occasional iffy language I did get the Internet back. I still have some configuration to do but at this point I’m too exhausted to do anything but whine in this post.

Right now, we’re having another storm but it isn’t as severe as yesterday’s. If you don’t hear from me tomorrow morning, you’ll know why.

Posted in General | Tagged | Leave a comment

The Speed of Offlineimap vs. Mbsync

One of the problems faced by those of us who have moved our email operations into Emacs is how to download the emails from the Imap server. There are two popular solutions: offlineimap and mbsync.

Offlineimap is written in Python and has the reputation of being slower than mbsync, which is a C application. Occasionally you see this disputed by someone offering largely anecdotal evidence that there’s no discernible difference. Such claims are invariably met with other anecdotal evidence that mbsync is indeed faster.

Charl Botha, who’s postings on email in Emacs have been excellent, decided to offer some actual scientific evidence so he ran some timing tests. The tests were all run on a single Windows 10 machine so they are by no means a definitive benchmark but they do offer much better information than we had before and probably generalize to the other platforms.

I’ll let you head over to Botha’s site to get the actual results but the TL;DR is that mbsync’s running time for a sync is about 65% that of offlineimap’s normal mode. Offlineimap, however, also has a quick mode that may not detect some message flag changes but that runs at about the same speed—a little faster, actually—as mbsync.

I don’t think any of this matters much. Generally the syncs are happening in the background so you don’t really notice them unless you’re forcing a sync. Even then, the times are not onerous. As for offlineimap’s quick mode, I think life is already uncertain enough without adding additional entropy to solve a problem that has another, better, solution.

I started off using offlineimap but changed to mbsync because I read reports of instability on offlineimap’s part. I never experienced that so it was probably just irrational paranoia. I don’t know if it’s still true—or ever was, for that matter—but I’ve been happy with mbsync and it was difficult enough to get configured that I have no desire to change.

Posted in General | Tagged | Leave a comment

The Gauntlet Is Thrown

I’ve written many times (1, 2, 3, 4, 5) about the open access wars between universities and academic publishers. In a move that almost certainly signals the beginning of the end game, the University of California has refused to renew its Elsevier subscriptions. This isn’t a small matter. Not only does UC spend 11 million dollars a year on Elsevier subscriptions but it is the largest producer of scholarly papers in the U.S. and Elsevier publishes about 18% of them. Other university consortia have done the same and as with UC, Elsevier has cut them off.

The UC, for its part, says that losing access to the journals will be inconvenient but only inconvenient. They already have plans in place to obtain needed papers through interlibrary loans and other means. They didn’t mention Sci-Hub and other illegal sources but you can bet that researchers will be making use of them. They probably already are because it’s easier to get a paper from them even if you have legal access.

The next step would be for the UC to discourage publication in Elsevier journals. No one’s said they’re going to do that but many researchers are already refusing to publish in their journals and the movement appears to be growing.

Elsevier and the other publishers have had a free ride for a long time. Academics write the papers, edit them, and referee them and the publishers then charge them for access to their own work. The UC’s actions are hopeful signs that that disgraceful situation is coming to an end.

Posted in General | Tagged | Leave a comment

Text Based Email Clients

Many people can’t imagine life without a shiny, GUI-based email client. The idea of using a text based client would never occur to them and some probably don’t even know there are such things. Others of us don’t want to waste our time clicking around a GUI app or Web Email page. We like doing things from the keyboard and, if you’re a hardcore Emacser, handling our email from within our editor.

Shreyas Ragavan is in the latter group and has a very nice post on why he thinks text based clients are the best solution. He had three email accounts and wanted to handle them in a unified way. His first step was the get a paid Fastmail account and forward his other accounts through it. That makes dealing with email from separate accounts much easier. I do something similar and have my email client (mu4e) set to respond with a From: address that matches the To: address of the original email.

Ragavan, like me, uses mu/mu4e. He finds that it integrates very well with his workflow. If he’s working in Emacs on some other task and finds he needs to dash off a quick email, mu4e is only a couple of keystrokes away. If he wants to turn an email into a task, that too is only a few keystrokes away. And, of course, he avoids the context switch that invoking a separate email client involves.

Like Ragavan, I love using mu4e. It makes working with email easier, keeps me in Emacs, and I can easily turn an email into an actionable task or put a link to an email into any of my Org files.

Posted in General | Tagged , | Leave a comment

Update to Writing a Thesis With Org Mode

Last year I wrote about Daniel Gomez’s post on writing a PhD thesis with Org-mode. Gomez’s post was an excellent exposition of the workflow that he used to write his thesis using Org. One of the most useful features was how he handled his “research chapters,” which had already been submitted to journals for publication. The journals, of course, had their own formatting requirements and some content in the journal article was not appropriate for the thesis (and vice versa).

Gomez put together a framework to handle all these—and other—issues that he described in his post. He did not, however, include the framework itself, although he did say he was considering making a repository for it. Happily, he has done just that and made it available on GitHub.

Formatting content for a Thesis suffers from the same problems that formatting it for a journal does: every school—indeed, every department—has its own rules and standards rigidly enforced by a little old lady in the graduate school who can hold up acceptance of your thesis until those standards are satisfied. It is, therefore, impossible to provide a single framework that will work for everyone, everywhere but you can take a framework such as Gomez’s and tweak it to work for your situation. Mostly that’s going to involve choosing the proper LaTeX class for your thesis. Gomez uses the mimosis class but says everything will probably work with other classes.

If you’re getting ready to write your thesis and would like to do it in Org-mode, be sure to take a look at Gomez’s original post and the framework itself. Even if you don’t use it, there are plenty of good ideas to make the mechanics of the writing easier.

Posted in General | Tagged , | Leave a comment

Is Emacs an Editor Framework?

Over at the Emacs sub-reddit, yep808 says that he thinks of Emacs not as an editor but as an editor framework that allows you to build the editor you really want. He asks if others share this view. It is, of course, a widely held perspective but as Irreal oldtimers know, not one that I think is precisely accurate.

My view is neatly captured by rhabarba’s comment which posits that, “GNU Emacs is a Lisp machine emulator which can (but does not have to) start a text editor application by default.” I’ve long held that the real power of Emacs comes from that fact: that Emacs is, in fact, a light-weight Lisp Machine.

Sadly, it’s nowhere nearly as powerful (a software system) as the original Lisp Machines but it does allow us to do all sorts of non-editing things like using it as an RSS reader, or music player, or Email client, or any number of other things. And, of course, we can easily build our own applications in Emacs Lisp.

It might seem as if it doesn’t matter how you view Emacs but I believe thinking of it as a Lisp Machine has a definite benefit: it encourages the view that Emacs is a programmable environment in which you can build all sorts of applications that are only peripherally, if at all, related to text editing. Once you adopt that point of view, you can start really tapping into the power of Emacs by writing code to solve your own problems.

Posted in General | Tagged | Leave a comment