Irreal

Over at TAONAW JTR has a nice post on a couple of tramp tricks. They’re pretty simple and don’t require any heavy duty configuration or setup. The first is to set dired-dwim-target to t. The variable is a bit more configurable but just setting it to t will change the default dired target (for copy and rename commands) to the directory of another open dired window, if there is one. This is particularly useful if the other dired window is pointing to a remote machine. It’s a fast way of copying a list of files from one machine to another.

The second tip is very simple but, according to JTR, can make transferring files from one machine to another with tramp much faster. The tip is to use scp rather than ssh when connecting to a remote machine. That’s simple a matter of connecting to /scp:user@machine:/path rather than /ssh:user@machine:/path. Tramp is smart enough to connect over ssh and do the right thing if your path points to a directory.

Take a look at JTR’s post for a few more details and for some further advice on bookmarking remote directories. It’s a short post so it’s easy and quick to read.

I’ve written many times that almost all my computer time is spent in Emacs and my browser (Safari). What all us everything-in-Emacs devotees want is to do away with using an external browser. We yak yak yak about eww but in our secret hearts we know that it can’t really replace a browser. Yes, you can learn to live with its limitations but it really can’t replace a full-fledged browser.

While looking around for today’s subject matter, I came across this Howard Abrams post from last December. In it, he describes his method for dealing with browsers. He has the special requirement of needing a different browser for work than he does for personal use. Additionally, he wants to use eww when he can.

It turns out that it’s fairly easy to automate this. By “automate” I mean that he can provide a list of Websites for which he wants to use a particular browser and default to eww for sites not in the list. Most of this is built in but he does have to provide a function for each browser he wants to use.

Take a look at Abrams post for the details. Most of us don’t need to use multiple browsers, of course, but Abrams post shows how it’s possible to adapt Emacs to your workflow and if not solve, at least ameliorate the browser situation.

I’ve written many times how important the Ivy/Counsel/Swiper package is to my workflow. Other than Org-mode, it is the most important package in my Emacs panoply. Even so, it does so much that I don’t make use of all its capabilities.

I was, therefore, very interested in a post by Jeremy Friesen in which he describes his move from Ivy/Counsel/Swiper to Selectrum. Friesen has been a happy Ivy/Counsel/Swiper user since he became an Emacs user a year ago but decided to switch to Selectrum. His reason for doing so—as far as I can tell—is that Swiper et al. have grown organically, added some special cases, and therefore become more complicated at the source level. Selectrum, on the other hand, tries to adhere to the Emacs API and is therefore simpler.

I have to admit that I don’t really understand the objection. Unless you’re planning on hacking on the package, its complexity is a minor matter. Yes, complexity unchecked can lead to maintenance problems in the long term but I’d pretty sure we’re nowhere near that point now. In fact, every time I see a problem reported on, say, reddit, the first comment is usually from abo-abo with a solution or an announcement that he’s already pushed a patch.

Still, I understand that some want a simpler solution that doesn’t try to do so many things. If that describes you, give selectrum a try. If you like having unused capabilities in reserve for the day that you do need them, maybe you should stick with Ivy/Counsel/Swiper.

As all of you know by now, I’m a big fan of mu/mu4e for handling email. For me, one of its major attractions is that it runs in Emacs. For those of us who prefer to do as much as possible in Emacs, there are two popular email options: mu4e and notmuch for Emacs.

Protesilaos Stavrou has a really good demonstration of using the notmuch email client. This is the best presentation of notmuch functionality that I’ve seen. Notmuch is actually a command line utility that indexes and searches your email repository (much like mu) but it also has an Emacs interface that acts as a mail client in Emacs (like mu4e).

The big difference between notmuch and mu4e is that notmuch depends heavily on tags while mu4e doesn’t offer much support for tags and relies on its powerful search capabilities instead. Stavrou shows how to leverage the power of tags to get various views of your email. This works because the tags are essentially bits of metadata added to the messages so you can characterize a message as finely as you like by adding appropriate tags. The problem with this is that assigning appropriate tags is much like deciding what directory to store a message in. With mu4e, I can just throw everything into a single directory and use search to find a target message. On the other hand, tags can narrow a search more quickly. Either approach is fine and neither seems intrinsically better.

I even learned a useful trick from the video. It turns out that Ctrl+c Ctrl+z
while in message-mode will delete everything from point to the signature line. That’s really useful when responding to an email and since it’s a message-mode feature, it works in mu4e too.

The video is just short of 24 and a half minutes so you’ll need to schedule time. Like all of Stavrou’s videos, it’s worth the time.

Phil Newton does a lot of writing. He’s written a book and has a blog and does all his writing in Org mode. That sounds pretty much like me but unlike me, Newton likes to write in what he calls a distraction free writing environment. I’m perfectly happy to write in a normal Org-mode buffer but I appreciate that others prefer a more uncluttered work area.

Newton prefers his text a little bigger, and likes it centered in the buffer. All that’s easy to do and Newton has a .dir-locals.el file in his writing directories to enforce his preferences. That’s nice because other buffer types—such as source code buffers—are unaffected and display as usual.

Almost everything he does, with the exception of Olivetti mode, is stock Emacs so you don’t need a lot of packages. He mentions that his inspiration for this environment is WriteRoom. Someone in the comments notes that Emacs has writeroom-mode that replicates most of the features in Newton’s environment and a few more.

If you’re one of those people who wants to see as close a possible to a blank page while writing, take a look at Newton’s post and checkout writeroom-mode. Newton’s setup, in particular, is so simple that it will be easy to adapt it to your ideal writing environment.

Jakub Kadlčík just finished a year with Emacs. Before that, he was a Vim user for 10 years. He felt that he had reached “peak learning” with Vim except for writing plugins, which VimL made unattractive to him. Emacs’ extension language, on the other hand, is a Lisp, which Kadlčík was interested in trying.

His post, A year with Emacs, is the story of what he’s learned in that year. It resonated with me because most of his reactions were the same as mine. I didn’t opt for Evil and I hadn’t refined my workflow enough to keep a single Vim instance running all the time but otherwise his reactions were the same as mine.

It starts with keeping Emacs running all the time. If you’re used to almost any other editor it seems like a strange way to operate but with Emacs it’s the natural thing to do. It also explains why I get a bit grumpy with people who complain about the long Emacs startup time. It’s certainly longer than Vim but those few seconds are amortized over the often months-long running time of each invocation so if you’re using Emacs correctly the startup time doesn’t matter.

The other thing that really resonated with me is what Kadlčík described as Emacs giving him more Vim than he had before. By that he meant he was able to subsume many of the tasks that used to require separate apps into Emacs. That meant that he had a single unified interface (Evil/Vim in his case) for dealing with those tasks. In other words, Emacs is the ultimate IDE.

Like me, Kadlčík discovered that his system was effectively reduced to Emacs and a browser. Sure, he occasionally needs to fire up some other app but most of his work is done in Emacs or the Browser.

He also mentions:

• A literate configuration file with Org-mode
• Mu4e for email
• Circe for IRC
• Magit for dealing with Git
• Edit with Emacs to edit browser text objects with Emacs

Except for Circe and Edit with Emacs, I use all those packages. I don’t use IRC and, sadly, Safari doesn’t support Edit with Emacs or anything like it.

This post is a splendid list of what you can expect when you move to Emacs. If you’re coming to Emacs from Vim, Emacs can help ease the transition with Evil. Either way, Emacs offers a different, better workflow.