Irreal

Mike Zamansky has another video up in his Using Emacs Series. This time it’s about dictionary and thesaurus apps for Emacs. Like many of us—or, perhaps, most of us—Zamansky uses Emacs for almost every chore that involves text: he reads and writes his email with it, he reads his RSS feed with it, and he writes his blog with it. Up until now, he hasn’t integrated a dictionary app into his workflow. He usually just switches to his browser and looks up the word in one of the on-line dictionaries.

That, he says, is kind of lame so he wants to be able to look up words from Emacs. I’ve been doing that ever since abo-abo introduced his excellent define-word package. I use it multiple times a day either to check a definition or as a backup to flyspell, which on my machine takes a conservative view and often produces false positives. Its use is so integrated into my workflow that even when I’m not in Emacs, I’ll switch to it so I can look up a word. I get annoyed when I’m on my iPad or iPhone and have to use some other method of looking up a word.

Zamansky settled on the dictionary package. It’s a nice package and easy to use. It’s also more flexible than define-word because it can handle several dictionaries. You can even have a local dictionary server if you’re off-line a lot.

For his thesaurus, he looked at powerthesaurus and synosaurus. He settled on synosaurus while I’m using powerthesaurus. Either one seems a good choice. Synosaurus can use either a local thesaurus (Wordnet, which must be installed separately) or the on-line OpenThesaurus, which does not appear to support English synonyms.

I found this video particularly useful. In the first place, it reminded me about the try package, which is useful to easily experiment with packages before committing them to your configuration. Because Zamansky learned about powerthesaurus from Irreal, it’s a nice bit of what goes around comes around that I learned something about the package from his video. It turns out the powerthesaurus-lookup-word-dwim command is much more useful than the powerthesaurus-lookup-word command that I had been using.

Finally, no discussion of Emacs dictionaries could be complete without—again—mentioning Draft #4 and why you are probably using the wrong dictionary. If you do any type of creative writing you should definitely follow the above link and see what you’re missing. Pointers for installing the 1913 + 1828 Webster’s Revised Unabridged Dictionary and the necessary software is available here.

The video is just short of eleven and a half minutes so it should fit easily into a coffee break. If you don’t yet have a dictionary and thesaurus interface in Emacs you should definitely watch this video. Even if you do have apps installed, watch it anyway: you may, like me, learn something new.

As you probably know, Emacs now has a C API that allows you to write extensions in C or any language that provides C bindings. Via Wilfred Hughes we have a pointer to this excellent documentation on how to use the system.

The documentation is fairly long and detailed. There are examples of how to use some of the functions and how to initialize your module. There’s no point in going over everything in this post so I’ll just refer you to the documentation if you’re interested. Be aware, though, that this API does not mean you can now write your extensions in C and not have to know anything about Lisp. Emacs is a Lisp machine and you will still have to understand general Lisp ideas and how data is represented so that you can communicate with it from your C (or other language) module.

When it comes to eliminating workflow friction, few do it better than Matus Goljer (Fuco1). His latest post describes a fix for a problem that I didn’t even know existed: When Org pops up a log note buffer (after a change of task status, for example), the input method reverts to English. That’s fine if English is your native language and you’re shamelessly provincial like me. As I say, I didn’t even know it’s a problem. But English is not Goljer’s first language and he, of course, prefers to use an input method appropriate for his native tongue. The problem is, the log note buffer reverts the input to English.

As Goljer notes, that’s ironic given that the current maintainers are also not native English speakers. In any event, he put together a few lines of Elisp that solved the problem for him. As he says, he spent a total of about 2 minutes on it, far shorter than the time he spent searching for a solution in the manual.

If you also use a default input language other than English, be sure to take a look at Goljer’s post for an easy fix. If you are a native speaker, you might also want to check out his post just to see his code. I learned a couple of new Elisp functions that I didn’t know about so it was worth it for me.

Continuing yesterday’s theme of moving to Emacs, let’s discuss some ways of easing the transition. Nikhil Soni has a nice post that describes how he got Emacs to provide the features he was used to from editors like VSCode, Atom, and Sublime.

In particular, he wanted Emacs to give him these functionalities:

1. Duplicate current line
2. Move a line up or down
3. Multiple cursors
4. Auto-completion
5. Fuzzy search for file name
6. Project tree view
7. Go to function or class definitions
8. Return to previous cursor position
9. Find all function references
10. Markdown preview

Most serious Emacs users already have solutions for these but Soni goes through them one-by-one and shows how he implemented them. Almost every item was implemented by loading a package or with a (very) few lines of Elisp. Soni shows the Elisp in his post but also provides a pointer to the file in his configuration that provides them.

It’s a nice post that demonstrates that there’s nothing—other than bling—keeping you from upgrading from VSCode, Atom, or Sublime. Or so I say. Some partisans of those other editors will doubtlessly strongly disagree. That’s alright. As I’ve said before, the choice of an editor is a personal, not a moral choice. Of course, if you want the best editor…

Christoffer Stjernlöf over at Two Wrongs has a very well done post on Why You Should Buy Into the Emacs Platform. Posts on “Why I moved to Emacs” are common, of course, but Stjernlöf has written a comprehensive post that recognizes Emacs as more of an environment than just an editor.

He notes, for example, that you can edit code with any old editor but only Emacs can give you Magit. He says that Magit alone is reason enough to adopt Emacs but there are many other applications available with the Emacs platform. You can even write your own applications for Emacs if you like.

There’s no point in me listing all the Emacs features and packages that Stjernlöf admires; you should go read his post. Nonetheless, it’s worth noting that in keeping with his holistic view of Emacs, Stjernlöf lists many ELPA packages that he finds useful. Evaluating a piece of software by taking into consideration addons that third parties wrote my seem like cheating but it isn’t. Almost all of us have several packages installed to make our editing easier or to deal with tasks such as Email or RSS. It’s the packages that make Emacs an environment worth spending the time to explore and learn.

In any event, Stjernlöf’s post is interesting and worth a read.