Irreal

Sometimes you want to move a file you have open in Emacs. More often, perhaps, you simply want to rename the file. Emacs has some functions that do this but none of them are entirely satisfactory. The write-file function comes close but it leaves the old file in place and the rename functions don’t take care of the buffer. Zachary Kanfer has an interesting bit of Elisp that does the right thing.

His code copies the file to a new location (or name) using write-file so that the buffer name is changed and any changes later saved will be written to the new file. If the move is successful, the old file is deleted.

This seems pretty simple and it is but it’s surprising how often it comes up. If you find yourself in this situation more than once it’s probably worth your while to add Kanfer’s code to your init.el.

I’ve written about the community sourced Awesome Emacs before but it’s worth revisiting it because

1. It’s really useful.
2. It’s always being added to.

This time, I ignored the Table of Contents and just read down the list of packages and other goodies. Being crowd sourced, it offers an up-to-date list of Emacs resources that reflects a broad cross sections of interests and needs. For instance, it covers packages and modes for languages such as

• C/C++
• Python
• Ruby
• Common Lisp
• Scheme
• Clojure
• Elisp
• JavaScript
• CoffeScript
• TypeScript
• PureScript
• PHP
• Java
• Go
• C#
• Rust
• Erlang
• Elixir
• Haskell
• Swift
• Scala
• Lua
• SML
• Groovy
• OCaml
• Nim
• D
• Elm
• Stan

The packages in each category are listed more or less in the order of popularity so you can get an idea of how useful others have found a particular package. I like the list because it’s an easy place to surf for new and useful packages. You can do that with something like MELPA, of course, but that list is so large it can be intimidating. If you haven’t seen the list, take a moment to browse through it; you may find something useful.

The other day I saw this tweet

I see no point in using software, because it's "vintage" :) I know #vi or #emacs has many devotees, but I have never understood why. https://t.co/I9VEmMZNIL

— Paul Littlebury (@jaffamonkey) November 5, 2016

and immediately thought of Paul Graham’s essay about Blub programmers. I don’t mean to beat up on Mr. Littlebury, who I don’t know but am sure is a splendid fellow. I do think, however, that rather than reveling in his lack of knowledge he might investigate why so many of the best engineers do use Vim or Emacs.

His main complaint appears to be that Vim and Emacs are old. To that point I recommend Vivek Haldar’s observation that editors are like wine. You want an editor that’s old because, as Haldar says, “You want the text editor that has been around long enough and used by enough geeks that every conceivable pattern of manipulating symbols on the screen has been thought of, and crystallized into a re-usable pack.”

We use a vintage editor not because of some weird retro fetishism but because we want the best possible tool to get the job done. And nano? Really? It’s a great editor for people who don’t use editors. It’s definitely not what I have in mind when I think of powerful tools. On the other hand, it does, apparently, help protect you from the old ones.

Marcin Borkowski (mbork) has an interesting post on something I didn’t know about. He needed to write his own format-like function, presumably with %-tags not defined by the format function. It’s not too hard to write something like that but he asked about it on the Emacs help mailing list and got pointed to format-spec. That was just what he needed.

All the values are ultimately printed by princ so you can use it to print just about any Elisp object. You probably aren’t going to have a lot of use for format-spec but when you do need it, it’s just what you want. As Borkowski notes, you can use format-spec-make to help build the value list. I found the documentation for the two functions a bit ambiguous but the code is short and easy to read and resolved the questions I had about the functions.

I sometimes feel that I have the most unorganized Emacs configuration strategy imaginable. I don’t worry about autoloading or other quick-loading strategies and I throw my entire configuration (other than machine and OS specific items) into my init.el file. All the really cool guys have their configurations broken out into separate files, carefully optimized for the smallest possible loading time.

I was, therefore, happy to discover that I’m not alone. Selah not only has the same strategy but argues that it’s the correct strategy. He used to obsess over Emacs loading times like the rest of us but realized that he spent far more time tweaking his configuration for optimal load time than he did waiting for it to load. That’s because like most of us he didn’t load it very often. He says he loads it only about twice a week. Even that seems like a lot to me. My Emacs instances generally run from a week to a month before I reload it because I get into an error condition or need to refresh a package. Reloading takes me about 5 seconds so it makes no sense worrying about reducing the time—except maybe as an interesting engineering problem.

Selah says that he likes everything in a single file because he doesn’t have to spend time remembering where things are as he did when he had everything broken out to multiple files. I like keeping everything in a single init.el for the same reason. Yes, you can locate things reasonably quickly with some form of grep or indexing (such as a TAGS file) but as Selah notes, that means you have to perform a context switch and think about something besides the problem you’re solving. The other advantage of having a single file is that it makes it easy to convert it to an annotated Org file. I haven’t done that yet but it’s on my TODO list.

UPDATE [2016-11-29 Tue 10:17]: Correct post’s author.

UPDATE [2016-11-30 Wed 12:41]: iniit → init.