Irreal

Mike Zamansky has posted his second Learning Elisp video. In this episode, he briefy discusses defining variables, both global and local. The rules are a bit different from most other languages but still simple enough to understand easily.

In keeping with his taking things slowly, he doesn’t mention the closely related concept of closure but presumably that will come after he’s laid a bit more groundwork. If you have any experience at all with Elisp, nothing in this video will be new but it’s just what a n00b needs to get started.

He was originally going to include functions in this video but decided it would be too long so he decided to defer functions to the next video. Once that’s done, his plan is to move into the “interesting stuff” and show how to use Elisp to write interesting and useful functions.

The video is 11 minutes, 58 seconds long so plan accordingly.

As most of you know, I’m a Mu/Mu4e user and have been very happy with it. It has, I think, the correct paradigm for handling stored email: everything goes into a single repository and emails are retrieved with its outstanding search capability. Stored messages are indexed so these searches are very fast. You can, of course, use the normal method of multiple mailboxes but why would you?

Another of Mu’s benefits is that it runs in Emacs. That’s a benefit that it shares with Notmuch a similar package that has excellent search and indexing too but also implements a tagging workflow.

Michał Sapka was tired of using Webmail because of its inflexability. He used Neomutt for a while but decided he’d like to fold his email into Emacs. He quickly settled on either Mu/Mu4e or Notmuch and—apparently randomly—chose Notmuch. That was a good choice for him because his workflow includes working with GitHub Pull Requests and he brilliantly leverages Notmuch’s tag system to automate it as much as possible. He goes into detail on how his workflow functions so be sure to take a look at his post.

Another nice thing about his post is that gives an excellent explanation on how to configure Mbsync. If you’ve been around Irreal for a while, you may remember that that was the thing I had the hardest time with when I moved to Mu4e. It’s definitely a worthwhile post if you want to move your email to Emacs.

Dmitriy Pshonko has an interesting project for those of us who like to (a) stay in Emacs and (b) use the mpv media player. The idea is that you can list your media files with dired and it will tell you where you left off in the file if you started but did not complete it. Files that you’ve completed are marked done and the rest are simply listed.

I almost always consume these files in one sitting but sometimes I get interrupted and it would be nice to have a way of picking up where I left off. I don’t use mpv so I haven’t installed this package but if I did use mpv, I certainly would. It’s in MELPA so installation is simple and configuration consisted of setting a hook. The README explains how to do this directly or with use-package and is in any event a one liner.

If you’re an Emacs and mpv user, this package seems like a very nice addition.

I ran across a post by James Dyer, Dired Duplicate Here Revisited, that was interesting and I thought was worth writing about but I wasn’t sure there was enough there for a post. Then I saw this post by Álvaro Ramírez and thought they complemented each other and together can serve as the basis for my own post.

It turns out that Ramírez had the same thought and that his post was inspired by Dyer’s. It started with Dyer wanted a quick way to duplicate a file in a Dired buffer. His workflow results in a frequent need to do this so it made sense to make it as frictionless as possible. His code to do this is simple and straightforward.

Ramírez, of course, extended the idea by including it in his dwim-shell-command framework. He uses Bozhidar Batsov’s crux-duplicate-current-line-or-region that duplicates a line or region. It’s similar to Joe Casadonte’s and Steve Purcell’s whole-line-or-region that I use. In any event, he leveraged his muscle memory for that by using it to invoke his dwim-shell-command template to duplicate one or more files in a Dired buffer.

If you also have a need to duplicate one or more files in a Dired listing, take a look at these two posts. They present two excellent solutions.

Charles Choi has another thought provoking post: this time it’s about Emacs defaults. He begins by noting that Emacs exemplifies the idea that you should separate policy and mechanism by providing a mechanism but leaving the actual policy to the end user. Put another way, Emacs allows the user to determine how certain functions will behave. That’s tremendously powerful and liberating.

The problem, he says, is the default policies. For any given action—whether or not it’s configurable—Emacs has to something and that something is the default policy. Choi’s complaint is that the default very often violates the principal of least surprise. I’d screw down on that by saying it violates the principal of least surprise for today’s users. Things like the CUA conventions are what new users might expect but not what long term Emacs users expect. The right thing for new users is probably to enable the CUA bindings by default but that would confound and anger long term users. My point is that it’s not as easy as doing “what people expect”.

The majority of Choi’s post is devoted to default choices with which he disagrees. Most are hard to argue with. There’s no reason, for example, why bookmarks shouldn’t be saved immediately rather than risking them in an Emacs crash.

Some, such as the number of spaces ending a sentence are not as straightforward as he and others imagine. Yes, we are no longer using typewriters and the original rationale for using two spaces no longer applies but, again, old time users may expect the two space rule. Even those who’ve never used a typewriter can make a coherent case for it: it’s easier to write scripts and distinguish end of sentences from things like “Mr. Jones” if sentences end in two spaces. This is a raging question even outside the Emacs community.

In others, such as Magit prompting you if you have an unsaved buffer that might effect the current operation, I think he’s just plain wrong. Almost every time I see that prompt it’s because I have, in fact, neglected to save a buffer. Of course, we all have different work flows so you may disagree.

Finally, his suggested defaults includes some useful things that I didn’t know about. For example, I run Emacs in full screen, which means that when I run Ediff the control panel is not visible. Choi explains how to fix this. similarly, when you invoke Man, the focus stays in the current buffer making it hard to negotiate the man buffer. Again, this is configurable and it seems to me to make more sense to do as Choi recommends.

It’s a good post and you may even learn something useful like I did.

The Minions aren’t going to like me saying this but I’ve stumbled upon a nice and actually legible dark theme. idlip Dilip has a new, high-contrast theme, Haki, that started with Prot’s modus-vivendi and some of Daniel Mendler’s packages to design a theme that was perfect for him.

Take a look at his screenshots to see what it looks like in a number of Emacs modes. Notice how everything is legible. There is no dark blue on black or other unreadable hideousness. Just sharp, high-contrast colors. And I love the irony of the top post in his Elfeed screen being Irreal’s Red Meat Friday: Dark R Sessions in ESS.

Even though it’s relatively new, Haki is already available in MELPA. The README has installation instructions and a use-package recipe. I will not, of course, be abandoning my light mode non-theme but if you’re in the intersection of people who (1) like dark themes and (2) like being able to read the text in the buffer you should definitely take a look.