A very short quickie today.
The ever prolific Nicolas Rougier has another nice snippet for us. It’s a way of enclosing some text in a box. It’s a tiny bit of code but it can produce some very nice output. Take a look at the example at the end of his gist.
It’s another nice example of how flexible Emacs is and how it lets you adapt it to whatever you need it do be.
CleanPrinciple5, over at the Emacs subreddit, asks an interesting question. He wonders why texinfo isn’t more popular. If you are and always have been an Emacs user, you might find that a reasonable question. On the other hand, if you ever tried to use Info without Emacs the question is apt to elicit a, “Well duh!”
Here’s my answer to CleanPrinciple5’s question: The Info utility is basically unusable. In the old days, most of the (useful) GNU documentation was available only in Info format so I was forced to use a TCL application to read it. It was still horrible but at least it was usable. All that got better when I started using Emacs; its Info interface at least makes sense.
The Unix tradition is to use man pages for a summary of how to use a program and, when necessary, a longer document—in PDF these days—to describe details not appropriate for a man page. For example, the yacc man page described the command line options and some other details but the description of how to use it to generate parsers was left to a separate paper, typically in the documents directory or the printed manual. GNU combined those two approaches into texinfo documents.
It seemed like a win and would have been except for the brain dead Info reader. Even after moving to Emacs, Info documents still leave a bad taste in my mouth and I avoid them when I can. I’m sure many other users feel the same.
Still, they’re better than simple PDF documents because they’re indexed and hyperlinked and most of them have a section with the same information traditionally contained in the Man pages. All the information you need in a single document that should be easy to read but isn’t because the readers are terrible.
Update :
Techinfo → Texinfo. Also better distinguished between Info documents and the Texinfo language.
Álvaro Ramírez has a really handy tip for renaming files under version control with wdired. If you don’t already know about wdired, stop whatever you’re doing and find out about it right now. It’s really magical. The TL;DR is that you can set a dired buffer to be editable and any changes you make—typically to the file names—will be reflected in the actual files. Mickey, over at Mastering Emacs, has a nice introduction.
Ramírez really likes being able to change file names with wdired but was unhappy that those changes weren’t reflected in git in a convenient way. Naturally he set out to remedy the situation. As he discovered, he needn’t have bothered. Wdired already has that handled: you just need to set dired-vc-rename-file non nil. Once you do that, git will show the files as renamed and ask you to commit the changes.
On the one hand, this is a small thing but Emacs, of course, makes it easy to do the right thing so even if your files are under version control—not just git—you can rename them and be sure that dired will inform your version control system of the changes. It makes wdired seem even more magical.
The comments to my recent post Emacs And Modal Editing veered off to a discussion of why it’s not really possible to compare Emacs and Vim. Ag ibragimov expressed a point of view that I’ve long held: Emacs and Vim are really two different type of applications so it makes no sense to compare them.
I have always said that whether you embrace Vim or Emacs is a matter of your world view regarding editors. If you are looking for a fast, relatively light weight editor that excels in editing text and doesn’t bother with anything else, Vim is the correct choice. If you are looking for a Lisp Machine-like operating environment that serves as the center of your computing workflow, then you should choose Emacs. They’re both really good editors and which is right for you depends on that worldview.
All this was in the context of the editor wars, one of our oldest and most cherished holy wars. As I’ve said many times before, the editor wars can be funny and are often a source of entertainment but you shouldn’t take them seriously. These days, I doubt anyone does.
That brings us to this post by Odd-Distribution2887 from the Emacs subreddit. His worldview, I submit, is clearly that of the Vim user and he would probably be happier there. He appears to think that he should want to use Emacs but why should he? He should use whatever editor is in most accord with his workflow and disposition.
That’s not to say it’s a lifetime commitment. You can, and lots of folks do, change their mind and switch from one to the other. I spent at least 25 years with Vi(m) before I changed to Emacs. If you’re interested, you can read my two part series on why I changed here and here.
The takeaway from this post is that neither Vim nor Emacs is “better”. It’s simply a matter of what you’re looking for in an editor.
Richard Stallman writes to announce that he’s appointed a new Emacs maintainer. Not to worry, Eli Zaretskii is still a maintainer but Andrea Corallo will now be a co-maintainer along with Zaretskii and Stallman.
Corallo, of course, is the engineer who brought us native compilation, inarguably a tour de force.
Whatever you think of RMS, he does have a good record of appointing excellent Emacs maintainers. As I’ve written recently, heading up Emacs development takes a lot of knowledge and work and I’m sure Eli can use a bit of help.
I extend my best wishes to Corallo and am confident that he will be another in a long line of excellent maintainers. You can consider this post as my thanks to him in advance. As I’ve said repeatedly, we all owe those who step up to take on this task a huge amount of thanks.
Over at the Emacs subreddit, meedstrom raises an interesting point: why is everyone hating on the Dash library? The short answer appears to be “dependencies”. Using the Dash library increases the number of dependencies and everyone knows that’s bad.
The slightly longer answer is that most of the Dash functions have—at least rough—analogs in the builtin libraries and thus using Dash increases the number of dependencies and everyone knows that’s bad.
I’m a huge fan of Magnar Sveen from his Emacs Rocks videos and other work on Emacs. I often find myself using his Dash library because its functions do just what I need doing in a simple way. That said, I’ve never once actually required the Dash library. That’s because it’s used by so many packages that it gets pulled in to just about every Emacs installation. Bad form, I know, but I don’t generally distribute my code so I never think to include Dash explicitly.
Increased dependencies or not, Dash is everywhere and no one that I know of has anything bad to say about its quality. So the argument against Dash boils down to: “Dependencies bad”. Meedstrom raises the heretical thought that maybe—at least in the case of Emacs—dependencies aren’t really a bad thing. He also notes that in order to get the same functionality you need not only the builtin libraries but another third party library (llama) anyway so the hating on Dash is really pointless.
You can read meedstrom’s post and decide for yourself but I find his argument convincing. In any event, Dash isn’t going anywhere so maybe all that negative energy should be redirected to a more deserving target such as … Well, you know.
Three weeks ago—against all I hold true and noble—I was forced to take Google’s side in a dispute between them and the news media. You might suspect I’ve grown soft on Google but let me assure you that’s not the case. As proof, I offer this post on why Google search has entered dumpster fire territory.
At this point, just about everyone knows that Google search has deteriorated to the point that some say it is unusable. It won’t surprise any of you that the reason for this is the usual: the finance suits grabbed control and forgot about anything but growth and the stock price.
If you’ve been following my posts on Boeing, you won’t be surprised at the result. Yes the stock price has risen in the short term but the product responsible for that stock price is being destroyed. When the whole thing comes tumbling down, those responsible will be at a loss as to what happened and will say things like, “Who could have imagined…”.
Edward Zitron has a long and definitive answer to the question of what happened and who was responsible. The story is an old and sad one. The founders have quit active involvement with the company and the first thing the “professional managers” did was to sideline anyone still carrying the torch of the founding principles. As one of the commenters put it, Google moved from being a search company to being an ad company.
Zitron’s post is long and involved but worth a few minutes of your time if only as a cautionary tale. Google is big and powerful but the rot has already set in and it’s probably not outrageous to describe them as a dying company.
Like many of us, James Dyer sometimes has to use Vim even though he’s a dedicated Emacs user. He does this often enough that he’d like to maintain a bit of muscle memory for the Vim navigation commands. He doesn’t want a full blown Vim emulation like Evil or even something like Meow so he rolled his own. His solution is (really) simple: he merely made a few remappings:
It would, of course, be easy to expand this. You do need to find other bindings for the ones yours stealing but at least in this case Dyer says he didn’t use them much anyway.
I know I’m always going on about muscle memory and the problems I have with trying to use two editors but even I have to use Vim sometimes and when I do I may struggle to remember the bindings but it’s mostly pretty easy. What I don’t want to do is rearrange all my Emacs bindings just to ease my occasional forays into Vim land. Of course, my travels over the wall are infrequent so perhaps I’d feel differently if I had to make the trip more often.
In any event, Dyer’s solution may point the way to a solution for those of you have similar problems. Take a look at his post if you, too, occasionally live in two worlds.
No, not that Sunrise, Sunset. This one. Today’s post is just a quickie on some already plowed ground. Eight years ago, I wrote about finding the times of sunrise and sunset from within Emacs. I thought it was sort of interesting but never did anything about it.
Now Charles Choi has resurrected the subject. He likes to walk in the evening and finds it useful to know when the sun will set. It turns out that this is easy to do from within Emacs. One more reason to never leave the comfort of our favorite editor.
The only wrinkle is that you have to know the latitude/longitude of your current location. On macOS, that’s easy to find. Just open the Map application and your current location will be marked on the map. Click on that and it brings up an information block that, among other things, tells you the lat/lon coordinates. I’m sure the process is similar on Google maps or whatever you use on your system.
I don’t really have any need for this because:
Still, it’s good to be able to do as much as possible in Emacs so I added the lat/lon to my init.el and I can now query the sun’s appearance and disappearance right from Emacs. It’s especially nice to do it from the Org agenda. See Choi’s post for the details.
People often say that as you get older you grow wiser and come to understand more and more things. Those people are lying. The older I get, the more things I don’t understand. Case in point.
Why would anyone want to run Emacs in a browser? Let’s face it, one of the frequent gripes about Emacs is that it’s slower than, say, Vim. Why would you want to make it slower by running it in a browser?
Then there’s the security issue. The browser is the leading point of exploit for the normal user so, again, why would you want to put everything you do in Emacs under that threat? It’s worse if, like me, you do the bulk of your work in Emacs.
But wait. It gets worse. Every time your browser updates there’s a good chance it will break your embedded Emacs. It’s bad enough when the OS updates. I can only imagine the problems that would occur if Emacs were running in the browser.
As far as I can see, the constituency for this is the same as that for Chromebooks: those who want to live in the browser. A case could be made for this, I guess, for your Aunt Millie but why would anyone doing serious, technical work on their computer embrace such a thing? In the end, all you’ve done is make Emacs slower, less secure, and given all the wrong people—like Google and Microsoft—more power to control how you use your computer.
I always say, “Use whatever works for you” but the idea of running Emacs in the browser is enough to make me reconsider—or at least amend—that. Really, I just don’t understand why anyone would want to do such a thing but I’m sure my much wiser readers will enlighten me.