Bad Emacs defaults (opens in new tab)

Author’s friend’s comment is funny:

    ;; Basically, I was laboring under the impression that
    ;; `sentence-end-double-space' was telling Emacs the /right/ way to do
    ;; end-of-sentence spacing, but really it's just letting it know how sentences
    ;; work.  So setting it to nil lets you do sentence-level stuff, even on people
    ;; who are /wrong/.  So great.

I assume they were mostly kidding and this was only meant to be funny, but I learned the 2 spaces thing in college and then didn’t discover until a couple years ago that it had fallen out of fashion decades earlier, even before I went to college. IIRC the reason for the 2 spaces rule is because you need it in print, for non-fixed-width fonts, where the space character is really narrow. I think I even read that there never was a 2-space rule for fixed-width fonts? (*Edit just to say I think I (mis)remembered this story completely backward, and the corrections below are accurate. Print had different sized spaces already, typewriters need 2 to match.)

Anyway. I loved emacs back in the day, and for a long time, but over many many years my .emacs file bloated up to like a megabyte. (That might* be a slight exaggeration, but I’m not sure.) I can’t maintain it anymore. I probably have a very very enormous list of bad emacs defaults.

> Emacs famously has its idiosyncratic brace style and indentation style using a mix of tabs and spaces that no-one else uses.

Specifically, 'one indent is four spaces, two indents is one tab, repeat', which caused utter carnage for newbies editing YAML files since literal tabs aren't valid YAML.

Back in the day, I built consensus to switch the perl https://p3rl.org/Catalyst framework over to defaulting to an apache style config in the scaffold generator specifically because about 75% of our "confused newbie" questions on IRC at the time were people whose emacs config had broken their YAML config file.

Of course we're -ahem- a few years on from that now, and people generally have already had at least one pitched battle with YAML before installing/adopting another thing that uses it, but still, oh gods but that was frustrating for a while.

I agree with some of them, but why is the font blurry? My poor eyes.

Replace show-trailing-whitespace with automatically-deleting-whitespace, though.

  (defun x/delete-whitespace ()
    (unless (or (string= major-mode 'diff-mode)
                (string= major-mode 'hexl-mode))
      (delete-trailing-whitespace)))

  (add-hook 'before-save-hook 'x/delete-whitespace)

Most of these suggestions are either bad or useless. The only one I can get behind is to use spaces for indentation instead of using a mix of tabs and spaces.

Other than that: author has some very unique problems (changing fonts so often that they need to adjust how Emacs window fills the screen). Most people change fonts... never. A small fraction -- once or twice, at the time they install and configure the system. The author might be the only person in the world with that problem, but acts as if everyone does the same, and needs a solution.

Author doesn't understand why file backups are done they way they are done and advises to make them less reliable.

Putting all backups in the same directory will be inconvenient for files named in the same way.

C-h is one of the first keys anyone learns about Emacs and it's used all over the place in various combinations. Turning this functionality off in favor of a command that already has a key for it is just stupid.

Sentences need two spaces between them to distinguish them from acronyms, abbreviations and other uses of punctuation (like in proper names of products or references to pieces of code). This is the easiest way to deal with this problem. If you don't write two spaces at the end of a sentence, the editor will not be able to reliably determine where the sentence ends, and will screw up your formatting every now and then.

I spent all last weekend trying to configure an Doom Emacs instance following the latest guides and watching countless tutorials. I tried it on three different OS and was unsuccessful with different reasons each time.

I've come to the conclusion that Emacs is a black hole, and people who profess their love for it in 2023 are likely exhibiting some form of the sunk cost fallacy. Life is too short to spend all your time configuring it.

I'm pleased to report that after turning off backups and auto-save files over a decade ago, nothing bad has ever happened.

Post should really be called "Historical emacs defaults". Most of them were products of an era where those defaults were, in fact, the best defaults. Versioned backups were lifesavers before version control systems were ubiquitous and easy to use.

I'll also note that folks have been going back and forth about ^H & DEL at least since the 80s.

I wonder if there's anyone who uses Emacs defaults and only that.

Moving files to backup instead of copying is better. First, the file modification dates remain meaningful. When a backup is made, the backup file has a last modified date of when it was last changed and the new copy has the current time. It is also reversible if creating the new file fails for some reason. The backup file can moved back to the original location with a single file system operation and retains the right modification date.

It's also more robust in case of errors. Emacs can write new data to a temp file, confirm it succeeded then rename working to backup and new to working. You never have a situation where the working or backup file ends up half written.

My favorite manifestation to date of Emacs file handling is that if I use emacs to edit a post in my Hugo-managed site, and Emacs decides to leave one of its .#filename symlinks around that don't point to anything, hugo gets an error reading the directory and decides the entire directory is busted and doesn't read it in. So suddenly entire years of my blog start disappearing.

Granted, hugo is handling this particularly gracelessly, but it's not the only thing that gets confused and upset by the dangling symlinks that point nowhere.

As someone with astigmatism, the glow on the text makes it near impossible to read.

I think that the default backup behavior is useful: it fits the idea that the backup is more important than the new file, and it gives copy-on-write powers to hard links. If Emacs sees the file is version controlled it will not back it up by default, which also makes sense. The option to change defaults is there and may make sense for some users, like the author of this page. Having hard links to files that you edit and don’t version control and don’t want a copy on write behavior is potentially not a good idea, but if/when you need it, you hopefully thought through your editor quirks as well.

Translated title: “emacs defaults I happen not to like”

Which is not an unreasonable topic for an article though as it happens I disagree with almost all of them.

Emacs is a perfect case of “YMMV — and you can adjust it”.

    (setf dired-kill-when-opening-new-dired-buffer t)

To make dired not open a new buffer every time you navigate to a directory.

While efforts are being made at modernizing quite a few things where it makes sense, many may have better luck with using emacs-bedrock:

> An extremely minimal Emacs starter kit uses just one external package by default, and only GNU-ELPA packages on an opt-in basis. Intended to be copied once and then modified as the user grows in knowledge and power.

https://sr.ht/~ashton314/emacs-bedrock/

The curse of decades-long popular software:

- For the long-tail of software you can just ship it without worrying about the defaults or future backwards compatibility concerns because it won't hurt that many

- For popular software though the early defaults that work great for that era (and maybe a hundred people) will annoy all the tens of thousands of future users

Does this handle the case of editing 2 files with the same file name in different directories? Eg, in an OS kernel, its common to have "sys/amd64/include/param.h" and sys/arm64/include/param.h" open at the same time.

With respect to end of sentence spaces. I'm an "old" and learned on typewriters and type two spaces is etched into my muscle memory and my brain. It wasn't until 2016 that while working collaboratively on a large google doc (which was occasionally brought into Word by others) that I was made aware that two spaces were no longer the norm.

It was like an editing PVP game where these would be fixed in near real-time by others in the document we were working on :-)

Yes the web text today removes these today but I still prefer reading text in the old RFC document style where it's not only fixed width fonts, but also right and left column justified. In emacs this can be done by selecting a region and doing a C-u ESC q

:-)

Why are you trying to create more noise in my home directory, your suggestion of new 'defaults' are also bad, it should be ~/.local/share/emacs/backups and ~/.local/share/emacs/autosaves

I'll add my personal peeve: Ctrl-Z in a terminal, as we all know, works (via SIGSTOP and process group handling) to return control to the shell that launched the process. And emacs supports similar behavior (even though its tty is in raw mode) for symmetry, and that makes sense.

But at some point the emacs folks decided that in a X11 window, Ctrl-Z should be bound to the same kind of idea: it minimizes the window! So you're happily typing along and hit C-x <something> and... your window just disappears because you missed and hit the adjacent key. Terrible default, have had it disabled for decades.

    ;; Highlight end of buffer
    (setq-default indicate-empty-lines t)

is my most important one, when i open a file i need to know where it ends, vim has his by default i am not even sure if you can disable it in vim

The / at the end of a terminal line where the line in the file goes off the edge, using ^S for incremental search. Not being installed by default on most Linux distro.

These two things are incompatible with using cut-and paste in Windows, not to mind some other OS. One reason I switched to vi was I found vi worked better in mixed workflow where I sometimes used an IDE like IntelliJ IDEA, used a lot of web applications, and did a lot of cut and paste, which “just works” with vi assuming you go into insert mode when pasting.

Also at the time I was doing a lot of sysadmining where I would have to use somebody else’s account where there might be no emacs and certainly not my customizations or be working on a broken machine where the package manager might well be screwed up so installing emacs is not easy, besides the stakeholders on that machine have gotten along fine without emacs so why install some package just for me?

I'm a relative emacs noob, and have just switched from Doom emacs to rolling my own with a literate config file. I started noticing more and more ~ backup files in all my working directories. Needless to say this is a great tip for those of us who don't understand emacs defaults.

When I first started with Emacs I went with a ton of packages. Each time I started my config over, I'd learn more about defaults I like and my config become thinner.

I'm a fan of using packages that hook into Emacs defaults. Like providing data for xref for example.

Setting backup-directory-alist to ((".*" . ".emacs.bak")) keeps the files local to the actually files, without the cognitive overload of being adjacent to the edited files.

show-trailing-whitespace is quite annoying in ansi-term. Emacs is actually my tiling wm, because I need tiling only for terminals.

Emacs is just bad, overall.

tabs are evil and emacs with defaults..., who would do such a thing?

Interview with an Emacs Enthusiast in 2023 [Colorized]: https://www.youtube.com/watch?v=urcL86UpqZc