If you’ve been wanting to get a copy of Mickey Petersen’s excellent Mastering Emacs, here’s your chance:
You don't need a new TV – what you DO need is my book on Mastering #Emacs. It's just $20 for the next 4 days! Click the link below to activate the 50% off coupon:https://t.co/yH5hohw44j pic.twitter.com/Mgpai0XzbX
— Mickey Petersen (@mickeynp) November 24, 2017
If you’re an Emacser or want to be one, this is the book for you.
Mike Zamansky has his latest video up. This time it’s about Dired. Dired is one of the great features of Emacs but many users are only dimly aware of it and don’t make full use of its capabilities. Zamansky’s video is an excellent introduction to some of those capabilities. One of those features, writable dired, is extraordinarily useful and something I use all the time. Zamansky has a nice demonstration of using it to rename several files at once.
One feature that Zamansky didn’t mention is doing a regular expression search on a set of files by marking them in Dired and then typing A. You can also do a query replace by typing Q. There are many more commands like these—take a look at the GNU Dired reference card for details.
As with all of Zamansky’s videos, this one is definitely worth your time, especially if you aren’t using Dired regularly. The video is about 16 and a third minutes long so you’ll need to put aside some time for it.
Regular Irreal readers know that I avoid Google and its applications as much as I can. I use DuckDuckGo for web searches, use Org mode for writing and publishing—and when I must, NeoOffice to interact with documents from the unenlightened—and use mu4e and the Apple Mail.app for email. I still have a gmail account but for years have only used it for mailing lists and now even that has been migrated to mu4e. Now I only check it once or twice a week to make sure there’s nothing else I should migrate.
Mostly, I’ve eschewed Google because of privacy concerns: I don’t like the idea of Google, or anyone else, mining my documents for private information and selling it to anyone willing to pay. That’s a compelling reason for me to stay away and I’m always surprised when folks I consider otherwise sensible say they use gmail, gcalendar, and google docs.
Now there’s an even better reason to stay away. It’s bad enough that Google is reading through your “private” documents but completely unacceptable to lock your documents when they find something they think they don’t like. As the story at the link reports, these “unacceptable things” are often false positives. Even if they aren’t, mind your own business. You shouldn’t be reading this stuff, Google, but if you are and stumble across something you think is illegal then call the police. Otherwise, as I say, MIND YOUR OWN BUSINESS.
But really, I don’t feel sorry for the people who are losing their data. At all. Google has proved over and over again that you shouldn’t depend on their apps. If you’re using Google apps for your critical tasks, sooner or later you’re going to get burned. Just ask this guy.
A couple of years ago, I wrote about Josh Stella’s use of Emacs by a CEO. I’m always interested in how non-technical people use Emacs so I took note when Stella’s piece popped up again. I reread his post and mine and have to say that I didn’t really do justice to Stella’s post. It’s really excellent and you should give it a read if you haven’t already.
There’s an interesting discussion of the post on the Emacs reddit that’s also worth reading. Stella joined the conversation and said he would write a followup to his original post. I look forward to reading that and will, doubtless, write about it when it appears.
I really like ivy-occur and the way you can take a list of Ivy completion candidates and put it in a separate buffer that you can manipulate in any of the usual Emacs ways. The easiest way to use it is to type Ctrl+c Ctrl+o in a selection list.
It turns out that you can customize what gets put in the ivy-occur buffer for a specific command by writing a function to fill the buffer and registering it with Ivy. One really nice example is that is set by default is the swiper command. You can do a Swiper search and capture all the candidates with ivy-occur. That’s useful if you want to interact with more than one of the selections but what’s really nice is that the buffer inherits grep-mode and can be made writable with the usual Ctrl+x Ctrl+q. That makes it really easy to make multiple changes to a buffer, especially if you leverage something like iedit or multiple-cursors.
Recently, abo-abo announced a new ivy-occur customization: this time for find-file type commands. It results in the occur buffer becoming a Dired buffer. That means you can use the power of Dired to manipulate the list of files. As a real-world example, I often preview my blog posts locally in my browser. That causes the post to be rendered in HTML and placed in a file that the browser can display. Ideally, I delete that file after I publish the post but I usually forget and end up with several useless HTML files in my posts directory.
I used to deal with that by bringing up Dired, typing * . html to mark all the HTML files and then delete them by typing D. With the abo-abo’s latest change I can just type Ctrl+x Ctrl+f html$ to get a list of the HTML files and then Ctrl+c Ctrl+o t D y to delete them.
Follow the link to abo-abo’s post for all the details. And if you aren’t already using Ivy/Counsel/Swiper, you really should try them out. As I keep saying, they are my most useful package.
UPDATE : git-mode → grep-mode
I came across a nice Webinar on keeping a laboratory notebook. It’s from the National Institute of Health and is therefore aimed at medical researchers and the type of labs they work in. Still, there are, I think, valuable lessons for those of us in software engineering even if we don’t work in a formal lab setting.
I’m a big believer in keeping a notebook that contains the same sort of information discussed in the Webinar. I record problems I work on and the steps I take to solve (or try to solve) them. Naturally, I keep mine electronically in Org mode. I try to use the method recommended by Howard Abrams in his really great video on Literate DevOps. I’m not doing DevOps but I really like his approach of embedding the code he used to solve a problem in an Org file that explains the problem and what he’s doing to try to solve it. That’s especially useful if the problem comes up again because I have working code that solved it last time.
If you have to fill out activity reports, keeping a lab notebook provides an excellent record of what you’ve worked on and—if you track your time—how long you worked on them. It takes a bit of discipline to keep an accurate and comprehensive lab notebook but is well worth the effort.
The video is a little over 13 minutes long so you may need to plan some time for it. If you’d rather, you can read the slides and associated narrative instead.
Derek Banas has posted a nice introduction to Emacs video. It covers roughly the same material as the built-in tutorial with the addition of setting up a Clojure programming environment. Banas covers installing Emacs on both macOS and Windows. One of the commenters complained that he didn’t cover setting it up on Linux but it’s hard to imagine a Linux user not knowing how to install an application. He uses version 25.3 of Emacs so he’s working with an up-to-date Emacs.
Watching the video really brought home how much we all customize our Emacsen. Since he was using a stock install, he didn’t have things like minibuffer completion for file names and commands. It seemed painfully slow compared to how we work when we have something like Swiper/Counsel/Ivy or Ido/Smex installed.
My major complaint is that he used “window” and “frame” interchangeably. That distinction is confusing enough for n00bs without adding to the entropy in an introductory video. On the other hand, the production values for the video are excellent. It was very professionally done, including seamless switching between macOS and Windows.
If you’re an experienced Emacs user, the video probably won’t tell you anything you don’t already know but it’s an excellent resource for beginners. The video is a few seconds over 52 minutes so you’ll have to schedule time for it.
Here’s a really nice tip from Wilfred Hughes’ Emacs Command of the Day Twitter feed:
M-x magit-log-buffer-file: shows all the commits that affected the current file. Great for understanding the history of some code! pic.twitter.com/psiuHb2cQm
— Ⓔ Command of the Day (@ecotd) November 18, 2017
This is just the thing if you need to examine to the commit history for a particular file. I ran it on one of my oldest files in Git (9 years) and could see all the changes in a buffer of only 161 lines instead of trying to pick them out from the thousands of lines in a full log listing.
Take a look at the documentation to see some additional capabilities of the command. You can, for instance, select a region in the current buffer and the command will show only the commits that affected those lines.
You can, of course, do the same thing interactively from the Magit menu but not as easily. If you find yourself needing to examine the commit history of a single file (semi-)regularly, it’s worthwhile remembering the magit-log-buffer-file command.
Fuco1 writes that today smartparens is 5 years old. To celebrate, Fuco1 has released Version 1.11.0. Over the last 5 years, smartparens has become a ubiquitous and very popular package.
In the unlikely event that some Irreal reader is not familiar with smartparens, it’s a replacement for paredit that is useful outside of the Lisp world. Take a look at the README for the details. The TL;DR is that it provides paredit-like functionality for other languages.
Paredit’s central idea is that it forces you to maintain a syntactically correct Lisp program by enforcing matching parentheses and quotes. Smartparens can do that too but you can also choose to run it in non-strict mode that makes dealing with other languages (and plain text) easier.
If you haven’t tried it out, you really should. It brings the benefits of paredit to all of your buffers. If you aren’t already a paredit or smartparens user, you need to fix that. Paredit, especially, can be hard to get used to but the benefits are worth the effort. In Lisp, especially, it serves as an on-the-fly error checker.
Bastien tell us that there’s a new Org mode (a bug fix) out:
#emacs #orgmode 9.1.3, a bugfix release, is out! And @ThierryStoehr will give an introductory presentation this weekend at https://t.co/NmNtsoaBlu cc @capitoledulibre
— Bastien Guerry (@bzg2) November 16, 2017
Just before writing this post, I updated my package repository but the new Org is not yet there. I’m sure it will be available in Melpa soon.