Published 2025-02-24
Started 2025-02-21
tag(s): #random-thoughts #emacs
I tweaked the original, shorter, post title. Don't tell me it doesn't look like the title for an anime episode right now! 🤡 I love it.
I wrote quite a few times about how I like to keep my Emacs configuration small (most
recently here). The idea is
that then I have less dependencies, and also less code of my own to maintain.
The added benefit is that I learn more about built-in packages. While the editor is infinitely
configurable, there is a wisdom to the defaults.
I know that this is argued quite a bit in the Emacs subreddit: that out of the box Emacs is
outdated, that the bindings are not ergonomic, or that without XYZ package the editor is
unusable.
The topic of defaults also comes up once in a while in the Emacs dev mailing list.
As time goes by, I find that more and more things make sense. To be fair, some others don't...and I am sure the whole thing is highly subjective, what works for some people, doesn't work for others. This is a tale of the latter.
I am using a custom mode line configuration, and started to wonder if it wasn't better to use the default. You can see below a comparison between them, with my customized mode line on top.
One consequence of using a mix of Windows and Linux at work, is that sometimes files have different coding systems (UTF-8 vs ISO-Latin-1) and different end of line conventions. Emacs auto-detects a lot of these things, and they are reported in the mode line. It can be a bit cryptic, but it is concise, it's the first section in the screenshot above.[1]
For the longest time, though, I didn't need this information often (or, at all), because I was
using exclusively Linux. And also I couldn't find a good way to include it in my custom setup,
other than the same ultra-condensed default.
But now sometimes I need to deal with special characters or line endings directly, so it could
be handy to have that information available.
When using Datum to query databases, I
sometimes output queries to a file, and after I edit it, I send more output. So I
enable auto-revert-mode in the buffer for this file.
Sometimes I forget that I enabled the mode, and since my mode line dropped the list of enabled minor modes (they only show in the echo area, on mouse hover) - I end up toggling auto-revert unnecessarily.
I used the default mode line for a couple days, since it shows the coding info and list of
minor modes enabled, solving my two "problems".
But I found a number of other problems that I couldn't get around to, except with more
configuration, which then defeated the purpose of not using my own version.
First of all, the default line is busy. Once you split your frame, it is very
likely it will get truncated.
There's some duplication of information, for example, since I use git for all my VC needs,
reporting either the project name or the repo name is good enough, I don't need both.
Also it doesn't include the size of the active region. You can still get this information
with M-=, but it is something I use often enough that I noticed it was
missing.
And having the encoding and EOL at a glance wasn't handy at all. Like, it would have been
useful a couple times in the past months, but not something I need as much as I thought.
After trying telephone-line, doom-modeline, smart-mode-line, powerline, mood-line...I see now why these packages tend to grow so much. It is tempting to add the option to have X or Y information available. And if your mode line is a package that other people use, you will end up getting those requests sooner or later.
Bottom line, I will keep my custom, minimal setup. And I found good alternatives to my
problems.
As mentioned, hovering the text of the major mode shows the lists of the minor ones active in
that buffer.
And for the coding system, the command describe-coding-system (bound to C-h
C by default) shows the information. Is it calling it less convenient than having it in
the mode line? Yes. Isn't it more annoying to have that text in the mode line taking valuable
space when I need it once every three months? Also yes. So.