Last week’s Red Meat Friday was essentially anodyne so here’s something to get (certain) people’s juices flowing:
real software is written in #vim, #nano, or #emacs. if you still use an ide (especially for interpreter languages), go back to high school. 😎
— walid (@walidabualafia) April 28, 2022
Don’t worry IDE users, next week we’ll have another point of view that will annoy all the folks who are laughing now.
One of the hardest things to learn in C—indeed, many say it’s the acid test for a good C programmer—is pointers. Here’s an amusing cartoon (via Karl Voit) that explains it as well as any other explanation I’ve seen.
Pointers pic.twitter.com/TjfX5K54H7
— Joel Eriksson (@OwariDa) May 3, 2022
On top of that, it’s funny and made me laugh. Educational and funny: what’s not to like?
Yann Esposito has an interesting take on choosing tools and the choice between VS Code and Emacs. His post is from a couple of years ago but has aged well. He reminds us of a Microsoft strategy that we all knew about a few years ago but seem to have forgotten: Embrace, Extend, Extinguish. In essence, the strategy was to adopt a popular idea, extend it in a proprietary way, and then use their extended version to shut out their competitors. It’s worked well for them for many years but lately they’ve been presenting a kinder, gentler face.
Esposito is not deceived. He says that in choosing your tools you must always keep this strategy in mind. That brings us to the choice between VS Code and Emacs. Esposito has two points. First, despite the trappings of open source, VS Code is essentially a Microsoft product and there is no reason to believe that they won’t change or evolve the product in any way that they believe benefits Microsoft, even if it’s at the expense of VS Code’s users.
Second, there’s the matter of which is the better choice leaving aside the issue of its Microsoft provenience. VS Code, he says, is certainly easier to get started with than Emacs. It just works out of the box. But down the road, problems start popping up. It’s not extensible and really, really wants you to adapt to it instead of the other way around.
Emacs, on the other hand, is harder to learn and get started with, but its extensibility makes it a lifelong tool that you can adapt to your way of working. Esposito mentions Org-mode, in particular, as an example of this. It’s now part of core
Emacs but it’s worth remembering that it began life as a third party extension leveraging Emacs’ mutability. Similarly with Magit. Neither were developed by core Emacs developers but by users who had an itch that needed scratching.
If you want the easiest plug ’n play solution for your editor, none of this will convince you but if you’re a serious developer who’s willing to put in the effort to learn the best possible tool, Esposito’s post may hold some wisdom for you.
Over at EINVAL, Wojciech Siewierski considers multiple cursors (in Emacs) and whether it’s suboptimal. His post is entitled Multiple cursors considered… suboptimal, which seems rather provocative but the post is actually very even handed and concludes, as you’d expect, that whether or not multiple cursors makes sense depends on the task at hand.
I like multiple cursors and am still in awe every time I watch Magnor Sveen’s astounding demo, especially the last bit where he calculates the total time spent watching his videos. That said, I always find it a bit hard to use and, like Siewierski, usually fall back to keyboard macros. That’s probably because there’s not much to remember when using keyboard macros, whereas multiple cursors has a lot of commands and several edge cases. Doubtless, I’d be better at using them if I made a point of invoking them more often.
One of the most compelling use cases of multiple cursors for me is changing every instance of a word, phrase, or even regular expression. It’s perfect for that but I find that I generally use iedit, again because there’s not much to remember.
Still, there are some cases where you just can’t beat multiple cursors. The examples in Sveen’s video provide several cases of that. I do use and like it and should probably make a point of doing so more often so that I internalize its operation.
Chris Wellons makes a compelling case that multiple cursors is not very efficient in Emacs because it doesn’t play well with the gap buffer mechanism that is at the heart of Emacs editing. I agree with that but don’t care because, at least on the machines I use, there’s no detectable delay. Wellons has other complaints about multiple cursors that you can read about at the above link if you’re interested in the controversy but they mostly concern the edge cases where multiple cursors doesn’t work very well.
I’ve written previously about the PhD workflows of Gilles Castel and Sam Wallace. They’re Emacs based and highly efficient. Now, Tony Zorman has published his own PhD workflow. It’s also Emacs based and has several interesting wrinkles.
The most salient aspect of Zorman’s setup is that he’s using XMonad as his window manager. That provides a lot of automation and integration in his desktop. In particular, he uses the XMonad TopicSpace module to provide a separate workspace for each of his projects. Each topic space has its own directory and startup hook to provide consistent views.
He uses org-roam as a knowledge database and take notes using Org-mode but uses the usual AUCTeX/CDLaTeX combination along with aas for taking formal notes and writing papers. I’d be more reliant on Org-mode than AUCTeX for typesetting my Mathematics but I’m sure he’s used to his workflow and it seems to be working very well for him.
His post has lots of examples and animated GIFs so you can see things in action. The post serves as a great example of using Emacs and XMonad together to build a great workflow. Give his post a read if you’re interested in implementing a research workflow of your own. As I say, he has lots of good ideas.
Jack Baty has a post on how he logs the books he’s read. Logging books you read may be useful information to keep but it’s probably not all that interesting to others. What is interesting, though, is how he uses column view to display the information.
He collects the information as an Org file with each top-level header the title of the book. Specific information about each book—such as author, pages, rating, and other information—is kept in a PROPERTIES drawer. Since the items in the PROPERTIES drawer are tagged, it’s easy to access them to produce reports.
As Baty demonstrates, it’s easy to produce such a report using Column View. You can even perform some elementary arithmetic on the numeric entries as Baty shows by summing the total number of pages he’s read.
Of course, not everyone is a prolific reader or wants to track which books they’ve read. Still, the paradigm Baty illustrates is applicable to many situations: collect the information as tagged data in a PROPERTIES drawer and use column view to display it.
Baty doesn’t even use a capture template to record his data. He feels that the books he’s read are insufficiently numerous to make a capture template worthwhile. I disagree with that but it’s surely an individual decision. For many applications, a capture template is just what you need to ease data collection.
The post is short and worth your attention as a nice way of collecting and organizing data.
Thanks to Karl Voit for the link.
With the COVID-19 pandemic winding down, many companies have started planing for getting their workers back into the office. They are, if you’ll forgive the hackneyed cliché, like dinosaurs after the meteor hit wondering how to get things back to normal. But the old days aren’t coming back and the companies most likely to survive the post pandemic world understand this and are planning for it.
A case in point is Airbnb. Rather than asking how they can get their workers to return to the office, they’re asking how they can leverage what they learned about remote work during the pandemic to hire and retain the best possible people. Their CEO, Brian Chesky, just announced Airbnb’s plan for the new order.
The TL;DR is that virtually everyone in the company can work anywhere they like within the country they’re currently working in without a change in compensation. That includes, for those inclined, a return to the office. Chesky also recognizes the importance of face-to-face interaction so they’re planning (at least) quarterly get-togethers.
There’s more involved in the Airbnb plan, of course. Here’s Chesky’s summary:
Which sort of company would you rather invest in: a company like Airbnb that accepts and plans for the new reality or a company that obsesses over how to force employees back into the office? Who would you rather work for: a CEO who says I trust you to work as you always have or a CEO who thinks that if he takes his eyes off you for a second you’ll start goofing off? Put that way, the questions answer themselves.
This episode of Red Meat Friday isn’t really red meat so much as an account of a skirmish between two bête noires of yore. The two combatants were Microsoft and IBM. Not very long ago they were the two giants in the field and feared by everyone. Younger engineers probably have only vague memories of what Microsoft was like when Gates was still there. They were very aggressive and absolutely committed to crushing anything and anyone they perceived as competition. Still, as an organization they had a West Coast laid-back vibe.
Most younger engineers probably have no memory of the way IBM used to be. That IBM seems like it was from a different century. Actually, it was from a different century. They were straight-laced, buttoned-down, and stiff necked. Andy Tanenbaum (of Minix fame) captures the zeitgeist perfectly in this vignette from his personal FAQ on why he chose an academic rather than industrial career.
“When I was in college, I worked at IBM one summer to earn money. One day I wore a shirt that wasn’t the right shade of white. My coworkers informed me of my transgression and made suggestions for improving matters. In great detail.”
They may still be that way but no one knows or cares anymore.
The story of their squabble is told by Raymond Chen, a longtime Microsoft engineer. The action takes place during the companies’ joint development of OS/2. IBM’s development took place in Boca Raton, Florida. Most of Microsoft’s effort was centered in Redmond but there was a small Microsoft contingent at Boca Raton.
The dispute centered on coffee. The only coffee available at the IBM facility was a particularly execrable slush dispensed by a machine. Naturally, the Microsofties bought their own coffee maker. Naturally, IBM objected. The resulting story is pretty funny and worth reading about. It’s also the only time in a long while that I’ve taken Microsoft’s side on anything.
Over at the Emacs subreddit, tdavey asks if we’re living in the golden age of Emacs. He’s an unlikely person to be asking this question because he’s not a developer or scientist. He is, to use his words, “an ordinary business-type who values Emacs mainly for Org.” Still, he’s a long time user (11 years) so his is an informed opinion.
The TL;DR is that he believes Emacs is “growing and innovating at a very healthy clip.” It’s a position that I’ve often advanced and, indeed, tdavey quotes Irreal as saying that Emacs is at the forefront of editor/IDE development. We agree that the Emacs ecosystem is healthy and robust, and that Emacs really is at the forefront of editor/IDE development.
But is this the Golden Age of Emacs? I don’t know. Certainly it’s a good time for Emacs and to be an Emacs user. I’ve felt for sometime that Emacs is losing mindshare to Vim but felt that was a shift in what people wanted: a really great, fast, efficient editor or an extensible framework that can encompass your entire workflow. I understand that.
What I don’t understand is Emacs losing mindshare to things like VS Code. It’s really just a pale imitation of Emacs but with glitz and bling. I don’t understand what VS Code offers (yeah, yeah, LSP) that Emacs doesn’t do better.
Still, as I always say, use whatever editor works for you. One thing for sure, if you’re an Emacs user, this is a good time to be one.
In another Vim to Emacs story, LowCom over at the Emacs subreddit offers his take on the transition. It’s interesting because his analysis focuses on how Vim and Emacs differ. He says, as I often have, that you can’t really compare them because they are different things. Vim is an excellent, (relatively) light weight, fast editor with a wonderfully composable command set that is easy to learn and remember.
Emacs does have a builtin editor but it’s much more. Probably the best characterization is that it’s a Lisp interpreter that comes with an editor application. But the Lisp interpreter is the important part because it allows you to expand in almost any direction you like. That doesn’t mean just that you can customize the editor application; you can extend Emacs in completely different dimensions such as a mail client, an RSS reader, a Git client, a music player, a remarkably complete Zettelkasten, and almost anything else you can think of, especially if it’s text based.
Low Com doesn’t think much of the default Emacs keybindings so, of course, he uses Evil. There was some pushback on that and much of the conversation in the comments is spent on litigating that issue. I’ve used both and like both. When I moved to Emacs, I just learned the native keybindings and am glad I did. Now I know both.
The traditional argument against the Emacs keybindings are that they lead to RSI. Guys I trust, like Eric Fraga, assure me that Evil really does help combat RSI. I’ve been an Emacs user for about 15 years and spend essentially all day on my computer but have never had an RSI problem so I don’t mind the chording. Still, I understand others aren’t as lucky but as usual, Emacs lets you have it your way.