Fifteen Reasons to Prefer Emacs

Posted on 2020-04-20 by jcs

Dominik Tarnowski gives us 15 reasons to use Emacs and says that VS Code has nothing on Emacs. He’s a Doom Emacs user but everything he says other than the particular keystrokes apply to any flavor. Another possible title for his post would have been Emacs’ Killer Apps because most of the post is about those killer apps. People can differ on what the Emacs killer apps are but pretty much everyone agrees that Org-mode and Magit are on the list.

Most of the post is devoted to Org-mode and a small amount of Magit. He’s got animated GIFS to illustrate many of points he makes so it’s pretty easy to follow along. Rather than reiterating Tarnowski’s list of outstanding Emacs features, I’ll let you check out the post yourselves.

I disagree with his conclusion that “…Emacs out of the box is simply bad.” What he probably means is something like “it doesn’t look modern enough” but vanilla Emacs is powerful out of the box with a lot of functionality already there. To be sure, most users will add packages for even more functionality but I live happily with the default Emacs look other than changing the white background to “oldlace” (a very light tan) to make the contrast a bit easier on my eyes. Of course, if bling is important to you, Emacs can do that too. As always, it lets you have it your way.

Posted in General | Tagged , | Leave a comment

Emacs Is Not An Editor

Posted on 2020-04-19 by jcs

Jordan Besly has a nominally provocative post that claims Emacs is not an editor. Of course, it’s only nominally provocative because what he really means is not merely an editor. It is, as we often say at Irreal, a Lisp interpreter specialized for dealing with text that has an editor as one of its built-in applications.

You see that “specialized for dealing with text” frequently in descriptions of Emacs but I think you can make a case that even that’s too restrictive. It’s certainly true in that Emacs has specialized low level (C-based) functions to deal with the efficient display of text but that’s just one facility out of many. I prefer to think of Emacs as a light-weight Lisp machine suitable for many tasks. Of course, things like high speed computation or the manipulation of graphics are not suitable tasks for Emacs but the list of things that are is wider than just those that involve the manipulation of text in some way.

On the other hand, I don’t think it’s true, as Besly claims, that Emacs was designed ab initio “as an extensible environment with text editing as a feature” That claim is trivially false if you take the statement literally. After all, Emacs was originally implemented as a set of macros on top of the TECO editor. But even later, stand-alone versions of Emacs were not conceived as general purpose environments the way Emacs is often thought of today.

Regardless of original intentions, Emacs today certainly embodies the notion of being “an extensible environment with text editing as a feature.” But it’s even more. At least for many of us.

Posted in General | Tagged | Leave a comment

A Workflow For Writing A Book

Posted on 2020-04-18 by jcs

Vladimir Keleshev has an interesting post that details his book writing process. It is, in a sense, low tech in that it uses very basic tools: Pandoc, Make, and Vim. He writes in Markdown and uses Pandoc to covert that to PDF or EPUB. It’s a workflow that I’m familiar with as it’s pretty much what I used to write my two books.

Instead of Markdown, I used Groff to produce camera ready PS or PDF. That was before I switched to Emacs so all the text entry and editing was done with Vim. And, of course, the whole process was controlled with a makefile. It was a pleasant and efficient workflow but these days I’d do it all with Org mode. The Org markdown is easy to use and allows fine tuning by adding in some LaTeX. Since it produces LaTeX as the “intermediate file,” there’s no need to balance facing page bottoms by hand, a boring and labor intensive exercise that took considerable time.

The only difficulty would be the diagrams. I had a lot of them and they were all produced by the pic preprocessor. I like the pic language and found it easy to use but if I were to write another book using Org mode, I might try something like draw.io as Keleshev did but I’d probably bite the bullet and learn PGF/TikZ or MetaPost.

These days, there are a lot of ways to prepare a book for publishing but if you want to keep things simple, Keleshev’s post may help you out.

Posted in General | Tagged , , , | Leave a comment

An Organizational Workflow

Posted on 2020-04-17 by jcs

Gregory J Stein has another interesting post on Emacs and Org Mode. This time it’s about how he leverages Org Mode to organize his life and workflow. It’s basically an update to his 2016 post on the same subject. This time he has a lengthy introduction that explains his goals and places his workflow in the context of the Getting Things Done method.

His workflow is a lot like mine except that I put most things into my engineering notebook/journal file including a record of my daily activities, phone calls, and discovery of things worth remembering. As Stein says, his setup works well for him but may not be exactly right for anyone else. Still, it’s a nice basis for anyone who wants to organize his life.

Stein says that his system transformed his life and enables him to plan for the future as well as manage his day-to-day activities. Take a look at his post and see if there’s something in there for you too.

Posted in General | Tagged , | Leave a comment

Working From Home: The Preferences

Posted on 2020-04-16 by jcs

I’ve been an advocate of remote work from well before it became popular and widespread. I’d always been aware of the lucky, tiny, minority who could work from home but it wasn’t until I read Mike Elgan’s 2007 article on the New Bedouins that I began to see it as an achievable goal for more than a small segment of workers.

The idea has always been controversial and remains so today but the idea clearly has a lot of momentum and is gaining traction, especially among tech workers. The naive view is that companies are crazy to resist remote work. After all, they save on renting and maintaining an office—a considerable expense—and their employees are happier and more productive. Of course, when you look deeper the situation is a bit more subtle. Not everyone likes working at home. Some people—as the micromanagers fret—really will goof off, and some business just don’t lend themselves to work-from-home. And, of course, the IT security problems that companies face are exacerbated by supporting remote workers.

Now, sadly, we’re in the middle of a large work-from-home experiment. Companies no longer have a choice. Workers no longer have a choice. A significant number of us are working form home. So how’s it working out? Zippia surveyed over 500 people on their experience with the experiment.

The results are mostly what you’d expect. Half of the respondents said they’d like to continue working from home even after the COVID-19 crisis is over but most of them thought their companies wouldn’t allow it. Forty four per cent of the respondents felt that they were more productive while working from home. One of the results that surprised me is that baby boomers were much more in favor of remote work. Three quarters of the older workers wanted to continue working from home and felt significantly were more productive doing so.

Take a look at the Zippia article for more of the details. They don’t show the cross tabs but they do breakdown some of the results by age groups. It’s an interesting survey and it will be interesting to see what happens in the long term.

Posted in General | Tagged | Leave a comment

Using Org Mode to Create LaTeX Documents

Posted on 2020-04-15 by jcs

Over at Opensource.com, Peter Prevos has a nice post on how to write LaTeX documents with Org mode. This is an advantage, he says, because it allows the writer to concentrate on the content of what they’re writing rather than worrying about LaTeX syntax or what the final result will look like.

Although making things simpler for beginners by using Emacs may seem counterintuitive, Prevos makes a good case for it. First, as already mentioned, it eliminates the need to be fluent in LaTeX. The simple Org syntax along with the fairly intuitive LaTeX math notation makes typing even technical documents easy.

Second, there’s no need to master Emacs either. As Prevos says, Emacs is only hard to learn when you reach the stage where you want to fine tune things. Beginners can simply accept vanilla Emacs and learn the finer points as they go along.

Finally, the document can be fine tuned by adding custom bits of LaTeX to either the header or a code block. This is easy to do after the document is mostly written and looking up arcane bits of LaTeX syntax won’t interfere with the flow of content creation.

There are a couple of miner mistakes in the post that are hardly worth mentioning since they don’t affect Prevos’ overall message. First, he calls the Meta key the Mod key and secondly he appears to think that all exporting involves Pandoc. As I say, neither of these is a serious matter and they won’t affect a user’s ability to produce nice documents with Org mode at all.

I like his post because it shows how knowing just a little LaTeX and Emacs is enough to produce beautiful documents easily without having to worry very much about LaTeX syntax.

Posted in General | Tagged , | Leave a comment

Making Money in Self Publishing

Posted on 2020-04-14 by jcs

Those of you who have been with Irreal for the long term know that I’ve always been highly skeptical of the publishing industry’s claim that almost the whole cost of publishing a book is editing and marketing and that things like printing, storing, and shipping the physical book represents a negligible part of producing and selling a book. The subtext is that self publishing won’t really result in greater profit for authors. Writers like Cory Doctorow have taken on the whole process and even accounting for economies scale found that the printing and shipping were major costs and writers can, in fact, increase their profits by taking on more of the production cycle.

If you’re an author wondering how to maximize the return on your books, Michael Lucas has a very interesting post that follows the money on a typical book sale. Lucas considers the market for physical books which seems a harder problem because rather than selling easily transferred bits, the author needs to produce and ship a physical product. The post considers various ways of handling the pipeline and shows the author’s share of a hypothetical \(\$10\) cover price for each of the strategies. It’s an enlightening post and well worth reading if you’re a writer considering selling your books on your own.

Posted in General | Tagged , | Leave a comment

Software Antibloat

Posted on 2020-04-13 by jcs

Back when dinosaurs roamed the earth, there was a Pascal development system for MS-DOS called Turbo Pascal. It was lightening fast, had a built-in IDE, and fit on a single \(5 \frac{1}{4}\) inch floppy. It even included the source for a fairly functional spread sheet written in Pascal. The whole thing cost \$50.

This was before reasonably priced—let alone free—C compilers were available so it was widely used and a lot of code was written with it. Given the size of practically any of today’s tools, it seems amazing that you could fit it on a single floppy. James Hague has an interesting post comparing the size of Turbo Pascal with some modern software related objects.

There are header files that are larger than the whole Turbo Pascal compiler/IDE, which for version 3.02 was 39,731 bytes. Yes, yes, today’s systems are far more complex and programs have to worry about operating in a GUI environment but consider that the binary for the Unix true command under MacOS Catalina is 30,944 bytes and all it does is return true (i.e. 0) when called. It doesn’t even do any I/O and it’s essentially the same size as a complete Pascal compiler and IDE. Here’s the code for the FreeBSD 10.0 implementation:

int
main(void)
{
        return 0;
}

which I’m sure is essentially the same as MacOS’.

It’s probably a mistake to try to draw any profound conclusions from all this but we should find it at least a little shocking as a graphic illustration of what software bloat really means.

Posted in General | Tagged | Leave a comment

Emacs and Vi(m)

Posted on 2020-04-12 by jcs

Just in case you aren’t tired of the editor wars, Ron Wills has a short post that compares the two editors. There’s a lot of that going around, of course, but I like Wills’ post because his conclusions are neatly congruent with mine.

Two main points:

  • Many think of Emacs as being an editor with a Lisp extension language but Wills (and I) think that’s backwards. Emacs is actually a Lisp interpreter with a built-in editor as its font end.
  • Arguing about which editor is better is silly because they are two different types of applications with different intended uses. Vi is meant to be a lightweight editor that’s fast to load and easy to use. Emacs is, of course, also an editor but that’s only one of its faces. Emacs is a platform for performing just about any function you can perform on a computer. Which editor you think is best depends on what you’re looking for.

Wills and I agree on that last point. Use whichever editor best fits with your workflow. They’re both great editors. And who knows, maybe your needs will change and you’ll try the other. Lots of us have been down that path. In both directions.

Posted in General | Tagged | Leave a comment

Emacs as Malleable Software

Posted on 2020-04-11 by jcs

Konrad Hinsen has an interesting post positing that Emacs is one of the few pieces of malleable software extant in the modern software environment. To understand what that means, you should first read the definition of malleable that Hinsen links to. When I read it, I was struck by how similar it is to the GPL except that, like Emacs, malleable software should contain a built-in method of changing the software to your liking. The idea, as with the GPL is that users should be a able to adjust their software to fit their workflows.

Hinsen says that in the 70s and 80s, malleability was a common design goal but that only Emacs has any real traction today. His post considers why this is and contrasts Emacs with Smalltalk, another piece of software designed with malleability in mind. The difference, he says, is that Emacs is useful out of the box for the end user, while Smalltalk—which is, in some ways, more malleable than Emacs—is useful for developers but not much use at all for an end user.

Thinking of Emacs’ advantages in terms of malleability is a useful viewpoint. On the one hand, it’s really no different from what we always say but on the other, it gives us a framework for understanding why those advantages are advantages and matter so much.

Again, be sure to read the definition of malleability. You can’t really understand the post without it and it is, in some ways, the most interesting part of the post. This is a useful post if you want to understand what makes Emacs so special.

Posted in General | Tagged | Leave a comment