Irreal

Over at the Emacs subreddit, weevyl talks about how Emacs completion changed his life. Or at least his Emacs life. His story is about his repeated efforts to move to Emacs and always failing. He finally realized that the reason for his failures was the difficulty of learning and remembering command names. We’ve all been there. You load a new package and suddenly you have some new commands to remember.

Weevyl’s epiphany was that command completion can virtually eliminate this problem. He’s a Helm user but the same principals apply to Ivy and other such packages. When you start to type a command name, you get a list of completions to help you choose the right one. I’m not a Helm user but with Ivy, the search is fuzzy and it’s often enough to start with the package name to get a list of available commands.

I use this all the time and have long since stopped thinking about it but weevyl’s post made me realize what a powerful facility this completion is. You don’t have to try to remember a long list of commands or their bindings. As I said, it’s usually enough to remember the package name to get a list of commands that make it easy to narrow down to the desired target.

There’s lots of agreement in the comments. Several people have almost the same story. Others have written some Elisp to help with this and shared their code so if you’re also finding remembering Emacs command names daunting, take a look at the post. It’s easy to forget how much Emacs does—or can do—to make our workflow easier.

Over that the Emacs reddit, arni_ca asks about key bindings for cursor movement. It’s not quite clear what he’s asking but the theme is moving the cursor without bindings like Ctrl+f, Ctrl+b,
Meta+f,
Meta+b,
Ctrl+n, and Ctrl+p.

As is often the case, all the juice is in the comments. It’s astounding how many different strategies people have for such movements. They range from everything to using the arrow keys to custom Elisp snippets. Take a look at the post to see if any of the ideas will work for you.

By now, you all know my answer to questions like this. I started with this epiphany from Steve Yegge: large scale navigation—more than a few characters or lines—should be made with search. It’s perfectly obvious but it occurs to few of us until someone points it out. The wonderful avy package refines this strategy and offers finer grained control of where the cursor ends up. Avy is probably my most used set of commands. I use them constantly as I write and edit. Following Karthinks, I’ve mostly pared my use down to avy-goto-char-timer although I do sometimes still use avy-goto-word-1. Regardless, if you aren’t already using Avy, you should take a look. It’s the backbone of my navigation.

The other navigation tool I use is an import from Vim: jump-char that lets you jump to the next or previous instance of a character. It’s incredibly useful and, again, I use it several times a day. If you use Avy and Jump-char, you will have most of your navigation needs met.

I’ve written before about relative line numbers. The idea is to label the current line as 0 and the other lines as positive or negative offsets from it. It’s handy if you want to quickly move to another line. As I said before, there are ways—avy in my case—that you might find better for doing that kind of thing.

In another of his useful posts, Bozhidar Batsov gives his own take on relative line numbers. Batsov says that relative line numbers are particularly useful if you are an evil user but even users of conventional Emacs can find it useful. If this sort of thing interests you, take a look at Batsov’s post for some details.

As I said in my previous post on the matter, I’ve never been able to warm up to the idea. I seldom have line numbers enabled but when I do I find it just as easy to jump to an absolute line number. Actually, I don’t do that either, I just use avy to get where I want to go. It generally provides finer control over where the cursor lands and is just as easy to use.

Of course, as I always say, that’s the beauty of Emacs. You can adapt it to whatever your preferred workflow is. If relative line numbers seem like a good idea to you, take a look at Batsov’s post.

The other day, in response to my The Power Of Elfeed post, René Trappel wrote to me offline about his Elfeed package that enables content search. He calls his package “Cuckoo Search” for reasons you can discover at his Github repository.

By default, Elfeed doesn’t search the content of a post, just the metadata such as title, date, and tags. With Trappel’s package you can do finer searches. If you often want to do fine grained searches for posts that previously appeared in your feed, take a look at Trappel’s package.

I’ve always found the default search adequate but it’s easy to imagine needing the additional capability offered by Cuckoo Search. The package is not yet available in ELPA but Trappel gives a recipe for installing it directly from his Github repository. I’ll probably wait until it appears on ELPA to install it unless I find myself needing its capability in the mean time.

For a very long time I’ve been using swiper-isearch in place of the default isearch because I like the way it lists the results in the minibuffer, lets you scroll through them, and pick the result you want On the downside, it’s not always clear which target you’re looking at when you have long lines, which I often do because I write with visual-line-mode enabled, but I’ve stuck with it out of habit.

Now Bozhidar Batsov has come along to blow up my comfortable status quo. It turns out that isearch is way more powerful than most of us knew. It’s not a secret. All this “hidden” power is described right there in the docstring. It’s incredible that it’s not better known.

There are a bunch of commands to add or delete characters or words to or from the search string, often from whatever happens to be at point. There are also several toggles such as case sensitivity, whether or not to search for invisible text, regular expression mode, and others.

Finally, you can edit the search string in the minibuffer, scroll through a history of the last 16 search strings, and, as mbork told us the other day, you can search for the symbol at point. There’s more so take a look at Batsov’s post or the docstring. As Batsov reminds us, you can see all the options when you’re already in isearch by typing Ctrl+h b.

This is a really useful post and has me thinking that maybe I should return to isearch. Of course, I can have both; the real question is what should be bound to Ctrl+s.

As you all know, I’m fascinated by non-technical people who use Emacs. You probably also know that I have profound dislike of Google and especially their Docs suite, which brings together everything we hate about Word with surveillance and censorship.

Over at the Emacs subreddit, myprettygaythrowaway asks for advice. Their girlfriend is a non-technical writer who is using Google Docs but would like to leave that behind and move to Emacs. Unfortunately, myprettygaythrowaway is an Emacs n00b, doesn’t feel competent to advise their girlfriend, and therefore asked reddit for advice.

Some of the answers amount to, “Why would you want to leave Google Docs? It’s the perfect environment for your needs.” Happily, there are saner responses. The best, in my opinion is to use the Emacs Writing Studio, which is made for precisely this type of user and doesn’t require any coding to set things up.

Some commenters suggest using LaTeX to produce nicely finished documents but, of course, that isn’t necessary. With Emacs—or without it, for that matter—you can write in Org mode’s simple markup language and easily export it to LaTeX and from there to PDF. More importantly, for those involved in publishing, you can also export it directly to Docx, which many publishers demand.

Contra the naysayers, Emacs can be the ideal environment for this type of user as numerous professional writers can attest. Even one of the commenters falls into that category and wonders why he spent so much time using lesser solutions.

If you, too, would like to escape from the Borg or its lessor demons, you can take heart from this post. It is possible and it’s not that hard.

Lars Ingebrigtsen has an interesting post on his EWP his package for publishing blog posts to WordPress. I’m a long term Org2blog user and really like it but, sadly, my host provider, that I’ve been with for many years, no longer supports the necessary protocol.

I was, therefore, interested in Ingebrigtsen’s package. But as far as I can see, it doesn’t support Org mode which is a deal breaker for me. I write everything in Org and have no interest in learning another system. Ingebrigtsen says that the problem with most WordPress publishing apps is that they don’t make it easy to do things like add links, embed videos, and other such matters.

But, of course, Org makes all that easy. I write my blog posts in normal Org mode, convert them to HTML, and paste them into my WordPress portal. It’s not quite as seamless as Org2blog but it’s not too bad. Still, I’d love a system where I could just write in Org and press a button and post to WordPress like I used to be able to do with Org2blog.

If you’re not an Org devotee and want to use WordPress, take a look at Ingebrigtsen’s post. It may be just what you’re looking for.

I’ve written many times how I was a Vi/Vim user for many, many years. I think that I’m just now coming up to the point that I have more time with Emacs than I did with Vi/Vim. Most of my previous life was spent with Vim, although I did use the original Vi for some time.

Vi didn’t really have an extension language and Vim’s was so horrible that everybody hated it. The only configuration I did was to map function keys to do things like enter the date. It was very barebones.

But time moves on. As far as I can tell, Vim has—mostly—been replaced by Neovim, which has Lua as an extension language. I always assumed that Lua was a good extension language and was, essentially, another flavor of Lisp.

Apparently, that’s not true. Over at the Emacs subreddit, CaptainDrewBoy tells the story of his journey from Neovim to Emacs. That, and its reverse, are a familiar story, of course, but I found it worth writing about because of what CaptainDrewBoy says about Lua and the Neovim extension system in general. The thing that struck me was how hard it was to use Lua. You have to make your edit and bounce Neovim for it to take effect. If there’s a syntax error, rinse and repeat.

Contrast that with the Emacs workflow. You write your code and evaluate it. If it’s correct, it takes effect immediately. If there’s an error, Emacs informs you and you simply correct it and reevaluate the code. No need to restart you editor. It’s easy and painless.

CaptainDrewBoy says he’d even be willing to give up things like Magit and Org just for the ease in configuration. Happily, that’s not necessary. With Emacs, at least, you can have it all¹. As usual, the comments are interesting too. Take a look if you’re interested in why someone might want to move from Neovim—a perfectly fine editor—to Emacs.

A few days ago I wrote about my need for something better than the Apple Notes app for my memo book. I’ve been using Notes for 10 years and it works well but I’d like something that takes care of adding time stamps for me and is a little more seamless.

I wrote that I’d discovered Journelly and that it seemed like it might be a good fit for my needs but that it was still pre-beta software. Now Ramírez has announced that he has an official beta program running that you can sign up for. If it seems like something that would be useful for you, you should sign up for the beta and give it a try.

Ramírez says that the app doesn’t (yet) support entering items orally but notes that you can use the system dictation facility for this. My reaction when I saw that was, “Duh. Of course.” I’m pretty sure that’s what’s happening in Notes. I’ve never programmed in the iOS environment so I’m pretty much a luser where it’s concerned and don’t have a good mental picture of what’s happening under the covers.

I’m not ready to commit to adopting Journelly for my memo book because it’s an important part of my workflow but I do think I’ll sign up for the beta and at least play around with it. If it is as good as it looks, I’ll probably use it seriously as soon as there is an official release.