Irreal

Marcin Borkowski (mbork) has a nice post on opening a Dired buffer for an external drive. Plugging the drive into a USB port causes it to automount but then you have to call Dired on the path to the drive, which can be long and complicated. Mbork’s solution to this is to automate the process.

If there is more than one drive mounted, his function will give you a completing read list to choose the one you want the Dired buffer for. It’s a small thing but like many things we do with Emacs, it helps smooth our workflow.

His code is both short and obvious, and nicely demonstrates how simple it is to do this sort of thing. This is an example of how easy it is to make Emacs into a secret weapon that can automate away many routine but tedious tasks. As Mbork says, it took him about 10 minutes to write the code but since he’s always mounting external drives, it won’t be long before he’s amortized that effort.

Knut Magnus Aasrud has an interesting post on OPML. If you haven’t heard of OPML before (I hadn’t) it stands for Outline Processor Markup Language and is a file format for outliner applications. It’s fairly general but has found particular use as a file format for exchanging subscription lists between feed readers and aggregators. It’s an unholy collection of nasty XML—although some think “nasty” applies to all XML—but it has the advantage of holding your subscription list and being exportable to HTML so that you can share it others on, say, your blog.

Of course, if you’re an Emacs user you have no need for OPML because you already have a builtin solution¹ that does the same thing. I’m talking about using elfeed-org with elfeed as your feed reader. With elfeed-org you can list your feeds in a Org file and add descriptive text to each entry if you like. Naturally, this is exportable to HTML or most any other format you can think of so if you want to share it as a blogroll on your blog or someplace else, it’s easy. You can even export it to OPML so its capabilities are a strict superset of OPML’s.

It’s just another example of how Emacs has our backs. As I’ve said many times before, if you’re reading RSS/Atom feeds—and you should be—you can’t do better than elfeed. And if you want to see the actual articles instead of just the text, take a look at elfeed-webkit.

Just a quickie today. I came across this reddit post about cl-callf. It was something I had never heard of. One of the Lisp idioms is to toggle a boolean with

(setq bool (not bool))

I use it all the time but when the variable is named AVeryLongAndStupidName instead of something reasonable like bool, it can be a pain because you have to repeat the name. Of course, no true Scotsman Lisper would use such a name but occasionally one comes across such monstrosities.

It turns out that Elisp has the macro cl-callf that lets you write the idiom as

(cl-callf not bool)

There’s also the related cl-callf2. You should check out the documentation for both because they’re a bit richer than the above suggests.

I’m not sure why Emacs thinks this is a Common Lisp thing because as far as I can tell there is no callf in Common Lisp. It’s probably due to the fact that the variable can be a place rather than a simple variable in which case cl-callf does the equivalent of a setf, a Common Lisp form. In any event, it can save you some typing when using a common idiom.

Mike Zamansky is using some of his newfound free time to learn more about AI. He’s going through Andrew Ng’s Coursera ML class, which requires working in Python. Zamansky used to do a lot of Python but has recently switched to Clojure as his go to language. From his previous Python work, he’s familiar with the idea of virtual Python environments and wanted to upgrade his workflow.

In this latest video he talks about Conda and Direnv to help automate his Python workflow. Conda lets you set up separate environments for such things as the Python version and the packages available to it. This is really handy if you have several different Python projects going on or you want to replicate the environment of someone else’s project.

Of course, you still have to activate the appropriate environment before you start working in it. That’s where Direnv comes in. The idea is that you put a special file in the directory of your project and it will set up whatever environment you need when you enter the directory. It can, for example, activate a Conda environment but it’s more general and not really tied to Python. You can use it anytime you want to automatically set up an environment.

You can get all the details from Zamansky’s post and the associated video. It looks as if Direnv can be a little fussy to set up but he has links to his configuration to help you get going. The video is 15 minutes, 20 seconds long, so you’ll have to set some time aside but, as usual, it’s worth your time. Even if you aren’t using Python, you may find that Direnv can ease your workflow.

I’ve written about Denote before but those posts were usually about advanced features that Prot, the author of Denote, was working on. If you don’t know anything about Denote, those other posts may not have meant a lot to you.

Emacs Elements to the rescue. He has a short video called Emacs Note Taking Recommendation that’s a brief introduction to Denote for those with no experience with the app. Unlike the advanced features that Prot talks about in his videos, this video shows how easy it is to get started with Denote. There are only a few commands that you need to know to start using it effectively.

One of it’s really nifty features is the ability to import existing notes into Denote. When you do that, Denote will use the existing file date when renaming the file. It can also add the appropriate metadata, such as tags, to the file. Take a look at the video for the details.

One of the most useful things I learned from the video is dired-narrow-regexp. It’s part of the dired-narrow package and does just what its name says. You specify a regular expression in a Dired buffer and it will narrow the buffer to files matching the regexp. It’s very handy, especially since I already had the dired-narrow package installed.

The video is only 4 minutes, 16 seconds so you should not have a problem finding time for it. It’s a good introduction to Denote and worth a few minutes of your time.

A month ago, I wrote about James Dyer’s experiment with marking the active window. His original idea was to make the fringe of the active window a different color so that it stood out and was easy to discern from the others.

Almost immediately, Ignacio Paz Posse commented on his solution which was to make the mode line of the active window a bright color. I loved his solution and adapted it for my own use. I haven’t looked back. I’m still using Posse’s solution and really like it.

Meanwhile, Dyer continued to evolve his method and even made it into a package. Now he has put it on Melpa along with his latest updates. Take a look at his screen shot to see what it looks like. It’s an excellent solution to marking the active window. I still prefer Posse’s method but many will, I’m sure, want to use Dyer’s solution. The Github repository for the project is here. It’s reasonably configurable so you can adjust it to your tastes.

Over at the Emacs subreddit, jackn3 noticed that a lot of experienced Emacs user describe Emacs as a program that’s fun to use and he wondered if the other redditers felt the same and if so why. The responses to his question are interesting.

A surprising number of the comments mention Lisp and how easy it is to configure or expand Emacs using it and how much fun it is to do so. I’m all in on Lisp so of course I agree with this but it’s surprising and heartening how many Emacs users agree. I guess all those comments about parentheses, how terrible Lisp is, and how Emacs would be much better if only it were written in JavaScript or some other non-Lisp language are a minority opinion. Or more likely the opinion of people who aren’t actually Emacs users. Regardless, a significant number of the commenters mentioned Lisp as one of the things that make Emacs so enjoyable.

By far the most prevalent answer to Jackn3’s question was that its configurability makes it easy to adapt Emacs to your way of working instead of the other way around. That’s been a constant theme here at Emacs. It’s hard to overstate what a win it is to have an editor that you can configure to match your workflow.

If you have a few minutes to spare, take a look at the post. The answers will make you glad that you’re an Emacs user.

Emacs Elements has posted another useful short video. This time it’s about an easy way to use ediff. The first thing he mentions is that you can mark two files in dired and they will be used as the default when you call ediff.

That’s good to know. Then he mentions a complaint. When you quit ediff the buffers for the two files remain selected and visible. The majority of the video demonstrates his solution to this. His final workflow starts in dired. You mark the two files you want to compare and simply press = to invoke ediff. When you’re done and quit ediff, your window configuration is restored to what it was before.

It seems like a worthwhile customization, especially if your main use case is just comparing two files. He has a link to the code he used so you can copy and paste if you’re interested. My only criticism is that he saves the window configuration in register b. That’s fine until you already have the b register in use. Long ago, I learned a trick from Magnar Sveen to deal with this. When you’re writing Elisp code, there’s no reason to restrict yourself to the usual single character names. You can name it whatever you like. That’s because the register code uses symbols as the names for registers. See my original post on this for the details.

In any event, if you’d like to slightly simplify your ediff use, take a look at the video. It’s only 2 minutes and 6 seconds so there should be no problem finding time for it.