Irreal

As most of you know, I’m a big fan of RSS and use it as my main way of discovering and reading content. It has plenty of detractors but the majority of those are people who are upset that RSS makes it hard to monetize and track content. RSS is perfect for those who just want access to quality content without a bunch of sketchy ads and tracking cookies.

Over at pcloadletter there’s a nice post that says RSS is still pretty great. It’s a spirited defense of RSS but takes an even handed look at the protocol’s good and bad points.

One of the criticisms of RSS that he considers fair is that it doesn’t allow content discovery. That hasn’t been my experience. I discover new content by subscribing to, for example, Hacker News and various subreddits covering areas I’m interested in. To be sure, there’s a bunch of noise but it’s easily ignored and I find new blogs and other resources that are worth following.

Another fair criticism is that RSS can’t render all types of content faithfully. That’s definitely not an issue for me because I use elfeed-webkit to automatically follow RSS entries to their source. Even if you’re using an inferior RSS reader, the point of RSS is to give you a summary of new content and provide a link to the source if you find it interesting.

The pcloadletter post also does a good job of covering what makes RSS a great protocol. Despite what Google and others with an axe to grind tell you, it’s an excellent—for some of us, the best—way of following and reading high value content.

James Dyer has a really interesting post on how he used a bit of Elisp to solve one of his workflow problems. He’d recently abandoned his use of save=desktop in favor of recentf. His reasons for switching don’t really matter—although you can read them in his post—but after opting for recentf he wanted a way to switch to contexts other than files. He wanted to be able to switch to a recent file, a buffer, a bookmark, or a new theme.

All that’s possible out of the box, of course, but Dyer didn’t want to worry about separate keybindings for each of them; he wanted a unified selection method. It took a surprising small amount of Elisp to get this done. A single binding invokes a completing read with all the files, buffers, bookmarks, and themes as possibilities.

Dyer shows the code in his post. It’s amazingly straightforward. The only complicated thing is that he uses some of the more esoteric capabilities of completing read, many of which I didn’t know about.

Even if you’re not interested in building a unified context switching mechanism such as his, his code is worth studying for what it reveals about the features of completing read. It’s a lot more capable than you probably think. As usual, with Dyer’s post, it’s short and won’t take you long to read.

Tony Zorman has an interesting post on joining lines in the presence of comments. If you’re like me, your first reaction is apt to be, “why should I care about this?” After a second’s thought, though, I realized that joining lines is something I occasionally have to do when I start writing an Irreal post in the wrong directory where visual-line-mode does not get set. Once I realize my mistake, I want to move the text to the proper directory and join the lines in each paragraph.

It turns out, of course, that there’s an Emacs command for that: join-line. I’ve always solved the problem by setting the line length to a large value and reformatting the buffer. Using join-line is a much better solution.

For me, that’s the end of the story but Zorman wants to use join-line in programming buffers and it turns out that join-line doesn’t care about or do anything special for comments. That means that

;; Several comments
;; in a row
;; like this

gets concatenated into a single line, which is definitely not what you want.

The majority of Zorman’s post details his solution to this. For comments that start with a single character, the solution is easy. A simple advice-add does the trick. For languages like Lisp, though the solution is harder because the convention is to start whole line comments with two or more ; characters.

For that case, Zorman has to modify the source code of the function directly. The final solution covers all the cases that Zorman cares about and you may find it useful too. Take a look at his post for the details.

Life goes on and things change. Over 10 years ago, I wrote about a hack to run Magit in full screen mode. The hack—apparently from Magnar Sveen originally—was pretty simple. Here it is:

(eval-after-load 'magit
  '(progn
     (defadvice magit-status (around magit-fullscreen activate)
       (window-configuration-to-register :magit-fullscreen)
       ad-do-it
       (delete-other-windows))

     (defadvice magit-mode-quit-window (after magit-restore-screen activate)
       (jump-to-register :magit-fullscreen))))

You can tell it’s old because it uses the now deprecated defadvice.

I just read a post from Jeremy Friesen that does the same thing but in a more modern way. It takes advantage of some variables specifically provided for this type of thing. Take a look at Friesen’s post for the details. The TL;DR is that it’s even shorter than my version and probably protected from going out of date. It’s a nice solution.

On the other hand, my solution is, in a sense, universally applicable. You can, as I have, use it, mutatis mutandis, in a variety of situations. I use it, for example, to run eshell in full screen mode. Once you understand how it works, it’s easy to apply to any situation where you want to run something in full screen, even if the function doesn’t provide a special mechanism for it.

Regardless, if you’re lookng for a way to fun Magit in full screen (actually, in full window) mode, take a look at Friesen’s post for any easy way of doing so. It’s a good post and it’s short so it will take no time at all to read.

Remember the other day when I said I almost always learn something new from Bozhidar Batsov’s posts? I just ran across another example. Batsov informs us that as of Emacs 29, there’s a new command called execute-extended-command-for-buffer (bound to Meta+X) that’s like execute-extented-command (bound to Meta+x) except that the candidate commands are limited to those that make sense for the current buffer. That means commands specific to the current major mode, enabled minor mode, and commands bound to the local key map.

This is useful for those (almost everybody?) who have some sort of completion mechanism in place for the minibuffer. It’s especially useful for those who, like me, sometimes can’t remember the exact name of the command they want to run and depend on the completion mechanism to find it for them.

Meta+X is marginally harder to type than Meta+x but not enough to discourage its use. I suppose that if you find yourself using it all the time, it might make sense to switch the bindings but I doubt that’s necessary for most users.

Thanks again to Batsov for letting us know about this command.

As I’ve written many times before, the Irreal bunker strives to be Google free. We mainly succeed in that endeavor with the single exception of YouTube. It’s far and away the best in class service of its type and more importantly it has no viable alternatives.

It turns out, though, that you can lessen the pain a bit. Michał Sapka has a nice blog post reporting on Yeetube, an Emacs wrapper around YouTube that lets you play YouTube videos (via MPV). It does away with the ads, has less tracking, and allows you to download and save videos for later viewing.

In addition to doing away with the worst aspects of YouTube, it lets you deal with the videos from within Emacs. I haven’t had a chance to try it out yet and I don’t know what the video quality is like versus native YouTube but it seems like a worthwhile project. Take a look at Sapka’s post for the details.

Last Friday, I offered up a Red Meat Friday post that discussed the silly but depressingly widely held idea that Emacs is dying. As I said in that post, this is not an idea that’s held by anyone who actually uses Emacs but appears to be an article of faith held by those unwilling to spend the effort to learn Emacs at even a journeyman level.

Bozhidar Batsov also discussed this issue recently and dismissed it as the usual nonsense that should be ignored. He even says he didn’t bother reading the reddit post that occasioned Batsov’s and my subsequent posts. He does, however, provide a bit of evidence for one of my suppositions.

I speculated that Emacs usage as a percentage of the total possible user base has declined. Take a look at the chart he provides for the evidence. The TL;DR is that while VS Code holds 73.71% of that user base, Emacs is down at 4.69%. Notice that that figure says nothing about the total number of Emacs users. It may have increased, as Batsov suggests, or it may have declined. There’s probably no way of knowing.

One thing for sure, the Emacs editor is going strong, enjoying healthy development, and is probably growing, at least in total user terms. I’d be willing to bet that Emacs will still be going strong long after VS Code has faded into same obscurity being enjoyed by all the other would-be Emacs killers.

As of this writing, no one has bothered commenting on Irreal. That’s probably because Irreal readers are smarter than the average bear and consider everything I said obvious and not in need of further discussion. It was picked up by the Emacs subreddit, however, and there are plenty of comments there if you really want to know what others are saying.