2024-04 Austin Emacs Meeting

by

There was another meeting a week ago of EmacsATX, the Austin Emacs Meetup group. For this month we had no predetermined topics. As always, there were mentions of many modes, packages, technologies and websites, some of which I had never heard of before, and some of this may be of interest to you as well. I was only on for an hour before I had to drop off. This post also includes my opinions and commentary beyond what was discussed at the meeting.

#1 was the organizer.
#2 was present.
#3 was not present.
#4 was a developer in Seattle.
#5 was a new attendee.
#6 was another developer in the Bay Area, who did not speak much but posted some comments in the chat.
#7 was another developer who was also more chatty in the chat.
#8 was our electrical engineer in Central Texas.
#9 was our professor in OKC who was mostly silent, and did not do much professing.

Here is a list of the modes and packages that were mentioned (except big ones like Org, Doom, Spacemacs; some of these were only mentioned once or did not become the focus for very long):

Here are the non-Emacs topics that came up:

#1 talked about the new Emacs release with fixes: Irreal post here, link to release notes here, NEWS file here. One change going forward is that Org will not run Lisp code blocks. A few people on the call said this would disrupt some of their workflows. Perhaps it is time to learn Common Lisp.

Quite a few people on the call build Emacs from source. #2 runs Emacs 30. I built from a 29 branch, but I cannot open sqlite files. I either skipped a step or do not have a library installed. I hope that when Pop!_OS upgrades to the upcoming Ubuntu LTS that they will be using Emacs 29 with all the latest features.

A few members talked about the process of finding new work as a software developer. One commonality is to get take home assignments, spend a lot of time on them, and never hear back. One member made an elaborate project with unit tests, and put it in a container, and never heard back. Another said they always take longer than you anticipate.

#5 introduced himself. He has been using Emacs for about four years, and started out with Prelude. If I did not have my own config, I would probably go with Prelude. He found Eglot easier to use than lsp-mode. Most people on the call seemed to prefer Eglot for most languages. #4 pointed out two packages that can improve performance of LSP: emacs-lsp-booster and lsp-bridge. I found a comment on HN about Eglot v. LSP: Eglot was started by an Emacs maintainer, and is more integrated with Emacs and is written in more idiomatic Emacs Lisp, while lsp-mode has more features because it was written by developers who know LSP better than Emacs.

One of the members said they are working on a project using Java 8, and they have to use an older JDK and an older version of Netbeans. I was on a project using original Struts and JDK 8. I am generally pro-Java, but I will not work on a Java 8 project. Java has moved forward in the past decade. I am tired of being on projects where “business” decisions make the lives of the technical people more difficult. If you take the attitude that “if it’s not broke, then don’t fix it”, eventually you find yourself in a position where it will break, and you will not be able to fix it.

The group talked about tables: Org tables (easy to create) and regular Emacs tables (can have multi-line cells). A few member recommended a video on Org tables by Gavin Freeborn. The command org-table-convert will convert from an Org-style table to table.el format and back.

#8 has used org-babel with Ledger, the command line accounting program. Since it is text, it works well with Emacs; here is the documentation for ledger-mode. I have been using GnuCash since 2003. There is a program to export GnuCash files to Leger. One issue is that it only works with Ledger 2.x files, and Ledger reached version 3 over a decade ago. The dream of living in Emacs keeps slipping away.

Ledger was originally written by John Wiegley. He also wrote use-package and Eshell, and uses his own fork of Org mode. Living the dream.

The topic turned to manuals: We know we should read them, but many do not. As Molly White noted, there is a difference between being smart and wise. To be fair, some are not written well. One member said they like Komodo’s manual. I assume they meant this; I did not know Active State was still around. Another member said they liked the PGF/TikZ manual. The Emacs manuals also got some praise. One person said that reading manuals is a super power. I think taking notes is also a super power. On just about every software project I have been on, everybody seems to think they are in a competition to see who can spin the most plates in their head. I find this ironic, since the whole point of software is to do your thinking for you. People have found notes and small web pages I have made helpful, but I have never tried to write an actual manual. Perhaps if I do, I will follow the advice here, here, on HN here, and on YouTube here (with another post here).

#4 asked for advice on running Emacs on Windows. He thought Magit was slow on Windows due to a lag in creating processes. I use Emacs on my work laptop. I downloaded it using the Scoop package manager (site here, Wikipedia page here, Github repo here). I mostly just use it to take notes and make TODO lists in Org. Another user said one annoyance they have with Emacs on Windows is that org-id-get-create is quite slow.

I think they should change the name to something like emacs-git. Nobody knows how to say “Magit”. Every time it is mentioned on the calls, it seems like everybody says it differently. The FAQ states that it is like “magic” with a “T” at the end (with an emphasis on the first syllable). Some people emphasize the second syllable. Some say it with the “G” making a “G” sound, others with the “G” making a “J” sound (the English “J” sound, not the German “J” which sounds like a “Y”). Some people say “maggot”. I looked at some of the videos linked on the Magit site, and they are all over the map. I could not find any videos of original developer Jonas Bernoulli saying it, so perhaps we should just defer to John Wiegley.

Then we talked about Eshell. #8 asked if it was possible to run Coreutils in Eshell. I assume he was referring to this. That list of commands looks a lot shorter than the list of the Eshell built-in commands. There are 104 commands in Coreutils, and 51 in Eshell. So if you want all of them in Eshell on a non-Linux system, you will have to install the package and make sure they are in your path. And I don’t want to be That Rust Timeshare Guy, but there is a Scoop package for a Rust port of Coreutils. There are 17 commands that are common to Coreutils and Eshell: basename, cat, cp, date, dirname, du, echo, env, kill, ln, ls, mkdir, mv, pwd, rm, rmdir and whoami. Or, since Emacs is the source of all that is good and true, we could say that there are 17 Eshell commands in Coreutils.

The order that Eshell looks for commands is: Your Eshell aliases, the built-in commands, commands along your OS path, then Lisp functions in your config. One thing to remember if you want to live in Emacs all the time is that if you use an Eshell command with an option that it does not have, Eshell will not run the builtin command, but go down the list and try to find the command along the OS path.

#1 said he did not think he would be able to live in Eshell. He is paying for the Meetup group, so we will forgive his blasphemy. He did wonder if it was possible to pipe the output of a command to a buffer. I reminded him that he showed us this back in the month of November (or, as I call it, No-vim-ever):

ls  > #<mybuffer>

Someone pointed out that Eshell also supports zsh’s predicates and modifiers out of the box. One example they gave was:

ls *.txt(m-3)

which will list text files 3 days old or less. I have never used zsh. Bash uses Emacs key bindings, and Eshell uses zsh.

WRT living in Emacs, I do not think that I will be able to use Eshell for networking commands. I know a lot of people love the fact that you can pipe the output to a buffer, but sometimes I do not want that. Sometimes I just want the output to print on the screen like in bash. At some point I will read the manual. Perhaps there is a way to force some commands to stop writing to a new buffer.

There was some meta discussion about the group. I found out at least one person joined the calls because of my notes. At least I am not driving people away. We asked the organizer how much it costs, and it is about $30 a month. At some point I plan on writing a post stating that if we want the web to be more than ads and algos, we need to start paying for things we have not paid for, and paying for more things. Pay for a web host account, pay for an email account, donate to your Mastodon instance, donate to Firefox, and perhaps your Emacs Meetup. Or just our Emacs Meetup.

They started talking about ways to get more people engaged in the group. At this point I dropped off, so I have no idea what will await me next month. One new change is there is an EmacsATX subreddit. Come for the customization, stay for the cats.

This post was created in Emacs with Org Mode and Love. You’re welcome. And stop looking at your stupid phone all the time.

I give people numbers since I do not know if they want their names in this write-up. Think of it as the stoner’s version of the Chatham House Rule. I figured that numbers are a little clearer than “someone said this, and someone else said that, and a third person said something else”. Plus it gives participants some deniability. Most people’s numbers are based on the order they are listed on the call screen, and the same person may be referred to by different numbers in different months. A few regulars have regular numbers.

I am not the official spokesperson for the group. I just got into the habit of summarizing the meetings every month, and adding my own opinions about things. The participants may remember things differently, and may disagree with opinions expressed in this post. Nothing should be construed as views held by anyone’s employers past, present or future. That said, if you like something in this post, I will take credit; for things you don’t like, blame somebody else.

Image from F.256 No. 118, a 15th-century Gospel in the collection of N. P. Rumyantsev, housed in the Russian State Library; image assumed allowed under public domain.