Irreal

I long ago gave up using Gmail due to privacy concerns. Still, lots of folks—and companies—still use it because, among other things, it does have the advantage of portability that doesn’t depend on your current ISP or your OS. Gmail is easy to use as long as you use their Web UI.

If you’re an Emacs user who’d like to deal with email from within Emacs, however, things are bit more difficult. The hard part is retrieving mail from Gmail’s IMAP server. You’d think you could just use your usual credentials but that doesn’t work.

Jakub Kadlčík has a post that explains how to configure mbsync to deal with Gmail. The difficulties mostly involve generating and using a special password. I’d like to beat up on Google for making things so difficult but they’re simply trying to make the process a bit more secure and, truth by told, setting things up for Apple Mail is similar.

I’ve never configured mbsync for Gmail but I did for Apple Mail and found it difficult because I couldn’t find any write-ups on how to do it. As with Gmail, the difficulty is not the mbsync configuration file, it’s generating the special app password you use. It’s the same with Gmail: the tricky part is knowing that you need an app password and finding out how to get one. That’s where Kadlčík’s post comes in handy. If you’d like to retrieve Gmail with mbsync—or, really, any of the IMAP downloaders—take a look at his post.

One of the tropes of Emacs use is the idea that there’s always something new to learn about the editor. I know that to be true but today it was brought home to me by a new video from Protesilaos Stavrou. The video is nominally about managing window placement but part of that is the notion of “side window.”

I had never heard of them before or even the concept that they implement. It’s no wonder. While I was preparing to write this I looked them up in the documentation but couldn’t find anything at all about them in the Emacs manual. I had to consult the Elisp manual to find any information about them.

The problem that Stavrou is seeking to solve is the inconsistent placement of the windows that pop up for things like HELP. Sometimes a new window is created; other times an existing window is reused. If you’re like me, you probably suspected that the behavior is configurable but haven’t seen or used the mechanism to do it. Window placement configuration is fairly fine-grained so you can pretty much have it anyway you like.

Unless you’re very particular about window placement or want to implement something like emacs-dir-treeview, you probably won’t need to deal with side windows or the other functionality that Stavrou discusses but his video does show how the configuration is possible if you need it. The video is just short of 19 minutes long so plan accordingly.

David Vujic has a nice post on interactive programming—what he calls “REPL driven development”—and the huge difference it’s made to his development workflow. His post, Test Driven Development Deluxe, recounts his frustration with having to switch context from the code in his editor to the terminal so he could run a test. By the time he got back to the code, he’d lost a lot of the context he’d built up while coding.

Vujic is writing in Clojure so he has the power of the REPL at his command. His editor is Emacs so it’s a simple matter to test an individual form or a whole function right in the editor. He loves the instant feedback he gets from that and how easy it is to wrap his test commands into a test function in support of his TDD workflow.

The ability to use interactive programming is one of the main reasons that I try to do most of my programming in some sort of Lisp (Elisp, Scheme, Common Lisp). I still haven’t tried Clojure, though. Maybe after taxes and the rest of the Yak Shaving gets done.

Marcin Borkowski (mbork) has an interesting post on how to deal with two spaces after a sentence when transferring data from Emacs to an external application via the clipboard. The problem is that mbork likes to use two spaces so that he can take advantage of Emacs’ sentence-aware commands but most people—at least most Poles—insist, some strongly, on single spaces.

The one/two spaces between sentences is a long-standing holy war that I’ve written about before. Years after learning to put two spaces after sentences (an artifact of learning to type on an actual typewriter) I became persuaded that the one-spacers had the better story and converted to a single space. That, of course, broke the sentence-aware commands in Emacs but I didn’t mind too much. Then I discovered that, as usual, Emacs lets you have it your way. All you need do is tell Emacs how you end sentences:

(setq sentence-end-double-space nil) ;period single space ends sentence

For one reason or another, mbork chose not to use that solution and instead wrote some code to change the two spaces into one. His final solution will still have problems with code in some languages but appears to be working for him.

As well as being interesting, mbork’s post is also serendipitous. Serendipitous because his code for the changing the number of spaces echoes a point from Thursday’s post. Part of his code wants to move to the beginning of a buffer. He does that with (goto-char 0), which is incorrect because the lowest point in a buffer is 1 not 0. Nevertheless the code works. That’s for the same reason that (goto-char 1) works in a narrowed buffer: goto-char clips values outside buffer to be inside the buffer. Another example of Emacs having our backs.

Finally, mbork wonders if his strategy of using a buffer to make his transformations really makes much difference. The answer is almost certainly yes as Chris Wellons explained and I wrote about here.

Update [2021-02-13 Sat 16:56]: Used actual Elisp in goto-char invocations.
Update 2 [2021-02-14 Sun 14:49]: Added link to mbork’s post.