Bugs, Linux, and Open Source

Millions of pixels have been sacrificed exclaiming the glories and greatness of open source. Most everybody but Microsoft agrees and even Microsoft seems to have come around lately. At least on paper. There is, to be sure, a lot to say in its favor and most of what I’ve read against it appears more like special pleading than reasoned argument.

It’s surprising, then, to see an argument in its favor that I hadn’t seen before. A couple of years ago, koderski over at the Gamedev subreddit had an interesting observation. He noted that 38% of the bug reports on his game came from the Linux community. That might not seem too surprising except that Linux users are only 5.8% of the game’s user base.

You might think that those figures mean that the Linux version is buggy but when koderski looked at the data we found that only 3 out of the 400 bug reports from Linux users were platform specific. The rest were bugs that existed for all users. As koderski puts it, each Linux user gets you 650% more bug reports. He says that that’s like having a free QA department.

Koderski puts this down to Linux (and by extension, open source) users being trained to report bugs thanks to their involvement with open source, which depends on such user participation. Linus’s law, as formulated by Eric Raymond, famously asserts that given enough eyeballs, all bugs are shallow but this is a bit different. We don’t have fellow developers pursuing the code, just users who noticed that something was wrong and took the time to report it to the developer.

Posted in General | Tagged , | Leave a comment

Laas

As many of you know, I’ve long been fascinated by those who can write LaTeX at speed. By “at speed” I mean, for example, being able to keep up with a math professor’s lecture in the classroom. It seems almost impossible but guys like Gilles Castel showed that it could be done. Castel did his work in Vim but, of course, the same thing can be done in Emacs as Karthink demonstrates.

Castel depended on the Vim equivalent of yasnippet. Karthink also used yasnippet but his main tool was CDLaTeX. Recently, I came across a post that suggested that laas was much more efficient than CDLaTeX. I haven’t tried it but looking at the builtin shortcuts, it seems like it would be very useful for entering LaTeX at speed.

If you, too, would like to take LaTeX notes in your classes or other real time situations, you should definitely take a look at laas. And, of course, you absolutely must read Castel’s and Karthink’s posts.

My days in the classroom are long over but I was trained as a mathematician and if I were back in school today, I would definitely want to be able to take my notes in LaTeX. As I say, it seems like an impossible dream but Castel and Karthink showed that it’s possible.

Posted in General | Tagged | Leave a comment

Document Navigation

Charles Choi, as we know, likes to have things the way he likes to have them. Being an Emacs user, it’s easy for him to scratch many of those itches. In his latest post, he complains about the inconsistent navigation methods for various Emacs documentation commands. They all seem to behave differently and most of them don’t follow the standard Emacs navigation conventions.

He considers, Info, Help, Man, and Shortdoc. The worst, by far, is Info. The only thing I can think of that has a worse UI is the standalone Info utility, which I consider unusable. I never use Shortdoc so I won’t have much to say about it but Help and Man seem to me to be okay, if a little inconsistent.

Choi has his own ideas of what those interfaces should be and wrote some code to implement them. It’s easy to understand and adapt the code to your own preferences. My preference is that all these Emacs functions should follow the standard Emacs navigation conventions. Since these buffers are all read-only, I’d like n and p to behave like Ctrl+n and Ctrl+p.

Some of the documentation—Info in particular—have a complicated structure the needs additional commands to navigate them. For those, I don’t particularly care what they use as long as they’re at least semi-consistent among the different documentation types.

Choi’s ideas are different from mine so take a look and see what you think. One particularly nice idea is his paragraph movement commands. He uses highlight mode to mark the first line of the current paragraph. It’s a small thing but helps you keep your place.

As usual, Choi’s post is interesting and thought provoking. Take a look just to get some ideas as to what, if anything, you’d like to do about these commands.

Posted in General | Tagged | Leave a comment

Multilingual Editing

Protesilaos Stavrou (Prot) has an excellent short video that discusses how to use multilingual characters in Emacs. Prot, of course, is Greek and often wants to write Greek in Emacs. You can do that by switching keyboards at the system level but then—especially with languages like Greek—the Emacs keybindings break because the system is sending the wrong code to Emacs.

Happily, there’s another way: toggle-input-method bound to Ctrl+\ by default. This mode allows you to type with a non-English character set but still have Emacs perform correctly.

You can set a “default” input method that will become active when you type Ctrl+\ but if you add the universal prefix, Emacs will allow you to choose the input method you want. For example, I have my input method set to TeX so I can enter things like em dashes and various mathematical constructs but I’m currently learning Spanish so if I want to write in Spanish, I can toggle the input method to Spanish. Regardless of what input method I’m using, Emacs and its keybindings continue to operate.

Finally, there’s activate-transient-input-method, bound to Ctrl+x \, that allows you to switch to the default input method for the next character only. That’s nice for me when I simply want to add an em dash (—) but otherwise use my normal English input method. Prot uses it to add single Greek characters to his English text. As with toggle-input-method, adding the universal prefix will allow you to select the input method for the next character.

Prot’s video is 10 minutes, 59 seconds so it should be easy to fit it in. These are really useful commands even if you aren’t bilingual.

Posted in General | Tagged | Leave a comment

Literate Documentation with Emacs and Org Mode

Back in 2019, I wrote about Mike Hamrick’s excellent talk on using Emacs and Org mode for writing technical documents. I’ve mentioned it a couple times since and sometimes watch it again for some of the many great ideas embedded in it.

For the SeaGL 2023 conference, Hamrick updated his talk and showed how to produce a much more complicated document using Literate Document techniques. The goal was to produce a document showing how to build Emacs on a bare-bones Linux system. That means he has to worry about installing the necessary prerequisites, and getting everything configured for a successful Emacs build.

That sounds like a pain but is pretty straightforward. The wrinkle is that he wants to produce documents for both Red Hat and Debian based systems, which have different directory structures and utilities. He could, of course, write one and clone it making the necessary changes but we all know why that’s a terrible idea. Instead, he wrote a single document with code blocks that configure it for the required system.

In the end, he not only ends up with a nice looking document tailored to the target system, but the document includes code blocks that will actually do the install including downloading the prerequisites and making any necessary configuration changes.

The talk is pretty fast paced but he has a GitLab repo that contains everything from the talk including the final Org document so you needn’t stress about trying to take everything from the video. This is a really good talk and along with the 2019 version is something that everyone writing documents with Org mode should be familiar with. You should definitely invest the time to watch them both.

Posted in General | Tagged , | Leave a comment

Denote 2.2.0 Released

Good news for those of you who been following my posts [1, 2] on Protesilaos Stavrou’s Denote. The changes that I wrote about are now officially available in Version 2.2.0. The two main changes are the ones I wrote about—sorting in dynamic blocks and the denote dired buffer—but there are other significant enhancements as well.

One of those is a revamping of the rename functions to allow blank name components. You can read about these and the other changes in Prot’s announcement, which also links to some videos that describe and demonstrate these changes.

One of the really great things about this project is that Prot has taken pains to write a good manual and keep it up to date. As he says, the videos will eventually go out of date but the manual will always be the source of truth.

If you’re interested in a vaguely Zettelkasten-like note taking application, you should take a look at Denote. Its distinguishing feature is the systematic naming scheme that captures most of the significant metadata about a file in its name. That makes it easy to tell what the file’s about just from the name. If you want more information, take a look at the manual.

Posted in General | Tagged | Leave a comment

Marking Cut Regions

Just a quickie today. Tory Anderson has an interesting post illustrating something that I had no idea existed. You may—especially if you’re an old timer—be familiar with ’’cut marks“. They’re usually used to delimit code that an end user may want to cut out from longer text and use somewhere else. For example

Here is some introductory text that explains blah blah blah
--8<---------------cut here---------------start------------->8---
(defun do-things ()
  (do-something)
  (do-something-else))
--8<---------------cut here---------------end--------------->8---
Some more blathering.  

As Anderson says, they’re not used as much as they were in the past but they can still be useful. Emacs, of course, has a way to insert them automatically. All you need do is mark the region you want to cut and call message-mark-inserted-region to insert the cut marks.

Historically, they were used in emails so Emacs has the keybinding Ctrl+c Meta+m in message mode to insert them but you can insert them anywhere by marking the region and calling message-mark-inserted-region directly. Note that Ctrl+c Meta+m works perfectly well in mu4e and probably all the other Emacs-based mail clients. If you find yourself using it more than once a month outside of email, you can bind your own key sequence to it.

Posted in General | Tagged | Leave a comment

PSA: The Emacs/GnuPG Problem

Most Emacs users are probably aware of the current problem with using Gnu Privacy Guard (GnuPG) with Emacs. The TL;DR is that although you can open GnuPG encrypted files, you can’t edit and resave them. This problem was introduced in GnuPG 2.4.1 and is apparently hard to fix. As of this writing, it persists in all the GnuPG releases after 2.4.0.

A simple solution is to simply downgrade to GnuPG 2.4.0. It’s a simple solution, that is, unless you installed GnuPG with Homebrew. In that case, the solution is a bit more difficult but still not hard. I wrote about how to do it here. In a comment to that post, Michael Alan Dorman notes that another suggested—and far easier solution—is to simply add

(fset 'epg-wait-for-status 'ignore)

to your init.el. That seemed like an easy solution and I resolved to try it the next time I faced the problem.

I’ve just stumbled across a reddit post that suggests that solution will corrupt your encrypted files and make them unreadable. I haven’t had time to verify that yet but I wanted to get the warning out immediately. Hence the PSA. Until the issue is resolved, I’d avoid using that solution and downgrade to version 2.4.0 instead.

Posted in General | Tagged | Leave a comment

🥩 Red Meat Friday: Chrome Atrocities

Metanote: I wasn’t sure if this post really merited being designated a Red Meat Friday item but it is polemical and will doubtless anger some people so I guess it qualifies.

As most of you know, we here at Irreal are not (or at least no longer) fans of Google. Their crimes are well known and documented—at Irreal and elsewhere—so there’s no need to relitigate them here.

But—to channel Arlo Guthrie—that’s not what I’m here to tell you about. Rather, I want to talk about Google’s Web browser, Chrome. The main thing I don’t understand about it is why anyone uses it. Its performance is no longer top-of-the-line and its main purpose seems to be as an information harvester for the Google advertising machine. Yet it is, by far, the most popular browser. Why is that?

Now there’s something new to add to the list of Chrome atrocities: changes to its extension policies and API. In its crusade to fight ad blockers, Google has modified Chrome’s extension API to make filtering more difficult and, worse, demands that all updates (including filter rule updates) go through its app store and review process. That has the effect of preventing the ad blockers from updating the rules fast enough to keep up with Google’s constant changes to its anti-adblocking scripts.

Google, of course, is describing these changes as improvements to Chrome’s security and performance but that’s transparent nonsense. The changes are, in fact, user hostile so I ask again, why is anyone using Chrome?

The TL;DR, if you’ll forgive such a thing at the end of the post, is this: Get rid of every Google service and app that you can. In my case, that leaves only YouTube but, sadly, that’s what this post is really about.

Posted in General | Tagged , | Leave a comment

Why NYXT Is Programmed In Lisp

NYXT is a browser with a workflow inspired by Emacs and Vim. In particular, it strives to be keyboard driven and use Emacs-like shortcuts to speed and ease navigation. The development team takes this inspiration seriously and uses Common Lisp to program NYXT.

Naturally, this brings out the Lisp skeptics and haters who want to know why in the world anyone would choose Lisp as their development language. John Mercouris and Pierre Neidhardt are two of the developers and decided to answer this question once and for all. Their answer is a nice discussion that could serve to answer the same question in any number of domains.

They consider two main factors:

  1. Future proofing and Longevity
  2. Interactive programming

I’ve written many, many times about interactive (or exploratory) programming and why it’s my preferred development method. Mercouris and Pierre give their owns views on this and it’s certainly worth paying attention to them.

The longevity question is one I don’t usually think about but it’s also an important aspect. The idea is that Common Lisp is an extremely stable platform and has been for many years. Unlike Perl, to use their example, there are no backward incompatible changes to worry about. Most Common Lisp—whenever written—will still compile and run today.

To push the Emacs analogy a bit, another advantage that Lisp, like Emacs, offers is that it lets users adapt the language to suit their needs. The macro facility even lets you introduce new syntax if you need to.

Their post is a nice one if you’re wondering why anyone would choose to program in Lisp or if you’re trying to explain to someone else why you do. It’s a nice resource and well worth a couple minutes of your time.

Posted in General | Tagged , | Leave a comment