> 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.
Emacs does not have an "idiosyncratic indentation style". Indentation is mode (file type) dependent. For example, for Python the default is 4 spaces if it cannot infer from an existing file what is being used. For C, it appears to be two spaces.
If your language has a convention, then likely Emacs implements it. If not, you can send a patch to fix it.
I use yaml for over 15 years now and never had any issues. Iam a rubyist, naturally that was how i first met yaml and since then I really like it.
Also with homeassistant I was "forced" to write a lot of yaml by hand and also never had real issues. Maybe its because emacs handles writing yaml fine. Anyways. I like yaml.
Hopefully most distros' default emacs installs do the right thing these days but it's not something I've checked because these days pretty much everybody already has a setup that works for YAML because of how prevalent it is.
(I like YAML for just-about-human-editable data structures but then people try to text template it rather than actually treating it as data and then I want to cry)
I'm pretty sure the reason was to save bytes in the file. 1 tab character is 87.5% smaller than 8 spaces. Back in the day when disk space was extremely limited, people actually did care about this. They saved bytes any way they could.
The standard tab width (in most software, not just emacs) is 8. Basically nobody wants that much indentation, so your options are:
(1) Don't use tabs at all. Just use spaces. If space efficiency is a requirement, that eliminates this option.
(2) Use tabs only and change the tab width to match your desired indentation level. This is a simpler method. The downside is other people need to change their tab width to match yours. They may not want to, or their software may not support it. You have to decide whether you want to deal with that.
(3) Mix tabs and spaces. This is more complicated, but most software will display the files as expected without any tweaking.
TLDR: Tabs save disk space, but tabs are too wide, and changing tab width is a hassle, so mixed tabs/spaces is a compromise.
The benefit of using tabs with a tab width of 8, and limiting screen with to 80 columns (like old text based terminal) is that you limit how many loops and conditions you can nest in a single function due to running out of horizontal space. Eg, it encourages you to break functions with complex nested loops/conditionals into smaller functions.
EDIT: Both the Linux and BSD kernel coding style specify tabs for indentation, and a tab width of 8. The Linux guide says it best: "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."
> "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."
And, yet, that becomes so much religious dogma that people will shoot themselves in the foot.
I fixed a lot of network locking code way back when. I made sure that I had a validation framework to go along with it. It was a gigantic state machine, because that's what locking and protocol are.
But, you know, that thing had single exit point and 4-5 indent levels and extended past 80 characters because it was a goddamn state machine, had states and variables lifted directly from the specification state machine, and tested as a state machine with the validation suite.
But, hey, the kernel devs just had to rewrite it to match 2 indents and 80 character lines. So, they did.
And took 9 months until they passed the validation suite again. They didn't add a single feature. They didn't fix a single bug. But, hey, they dedented it real good.
What finally did the deed was that one of the senior devs finally got fed up, went back to my original code, wrote a Perl script (that's how regular my code was) to rewrite every state block into a function with extremely short, unintelligibly cryptic names and args in order to remove two levels of indent and make sure the function calls would fit in 80 characters.
The final kicker: someone genuinely found a real bug about 5 weeks afterward. They tried to fix it in the "better" code with less indents. They couldn't figure out which state was the problem because they mangled all the names. I went into my old code, fixed it, added a test to the suite and reran the refactoring script--and that's how the bug got fixed.
We're not developing on punch cards and VT100s anymore people--quit being stupid.
(Side note: the main issue that bit the devs is that people who are dogmatic about 2 tabs-80 characters tend to rely on early return to avoid fully-fleshed if-then-else which cause deeper chains. This does not work for state machines. There is no early return--every state should leave at exactly the point when you advance from the old state to the new state at the atomic swap. So, you can do what the senior dev did and cryptify everything, or you can just leave the damn state machine alone and accept 4 indents and 132 characters.)
...tabstop doesn't matter, you put your tabstop to 2 and it works, I get a fancy ultrawide monitor and put my tabstop to 8 and it still just works. The only problem is that you can't build a Christmas tree:
In 2023, we've made that mistake enough that there's a consensus not to do it. But when these defaults were chosen, there was wider variation in styles. (There wasn't even a consensus on how to format braces in C.) Expecting people to never do that would have been a pretty opinionated default.
Also, you touch on another issue: terminal width and wrapping lines. Back then you couldn't just tell people to make their window wider. Their response might be, "At 80 columns, it's already the full width of my screen." Or going back further, "What's a window?"
Notably, (3) is exactly what's used by Go (see https://pkg.go.dev/cmd/gofmt - "Gofmt formats Go programs. It uses tabs for indentation and blanks for alignment. Alignment assumes that an editor is using a fixed-width font.").
I had this same question, because wouldn't the mode author for a given language define this? I can't imagine this is the same across literally all modes that involve indentation and/or braces?
I don't honestly know the details, I'm an heirloom-vi user and was just on the other side of the conversation from the confused newbie multiple times.
So "apparently under some distro configs in some circumstances it does that" is pretty much all I bothered to find out, because the config data structures people were mostly expressing worked fine with a less touchy format. (and this was only the -default- format configured by the scaffold, if you handed the config system a YAML file it was still happy to load it)
I like Emacs indenting style. It emphasizes the fact that in indentation, important are visual columns, not implementation details like tabs or spaces.
;; 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.
I learned two spaces in typing class. I think having two spaces after the period looks better and makes more sense, both in fixed-width fonts and in variable-width fonts. I've never heard an argument against it that wasn't based on incorrect premises ("You don't need to do that anymore! It looks fine without it!" Well, no it doesn't look fine without it, so yes, I'm going to keep doing it.)
But yeah, it's weird the effects of backwards compatibility... so many things decided 40 years ago, which we can't change because it would break someone's configuration.
Googling the question right now, there are two recent developments I was unaware of. There’s a 2018 paper [1] about it showing no perceptual benefit to either spacing, and also in 2020 MS Word changed their spelling checker to consider 2 spaces an error [2]. This second article tells the opposite story from what I thought I’d heard (but maybe this is what I was thinking of) - it says 2 spaces were developed for monospaced typewriters, and not for print.
Your summary of the 2018 paper was incorrect. They found it made no difference to people who typed 1 space. People who typed 2 spaces read 2 spaced text 3% faster with equal comprehension. And the limitations were significant. The subjects were young and had normal or corrected to normal vision. The task was reading paragraphs in order. And I did not see periods inside sentences mentioned.
The way I see it, if some typesetting system thinks one space looks better than two and renders two as one anyway, or if the difference is otherwise imperceptible, then there's still no reason for me to stop using two. It's pure muscle memory and if people can't tell the difference then I'm not going to stop.
Sounds good to me. I wonder if your comment was intended to respond to the sibling comment to mine? Anyway, I’d agree there’s no reason to stop, and anyway 2 spaces has been the rule and still is for some people. Language and technology being fluid is why there’s debate and why the number of spaces has changed over time, and it’s also why it’s okay to do it the way you want to.
Do you think pretty much the entire web looks awful then? Because HTML rendering collapses whitespace by default. Your comment renders with only a single space after the period, despite the fact that you typed 2.
See, this is the attitude I don't understand. I'm not going around adding extra spaces after your periods; why are you so intent on removing mine? Who appointed you the textual aesthetics police? Let people add spaces according to what they think looks best, and the thing most people prefer will win out.
Feel free to add spaces, I’m just glad I don’t see them. I don’t even have to try to police anything to get the aesthetics I prefer, that was my point.
I recall the justification being the opposite. On the fixed-width of a typewriter, you need two spaces to add appropriate visual separation between sentences. With proportional fonts and proper software (or a typsetter using hot metal), they use fractionally wider spaces between sentences than between words: it's more of a 1.5 spaces than double-spaced.
It dates to the time when typewriters were new-fangled inventions in the latter end of the 19th century. In those days, it was still common practice for typesetters to use a larger space between sentences. Typewriter users mimicked that practice. Typesetting changed in the 20th century, now it is more usual to use a normal word space. Perception or ease of use has little to do with it.
I held out like you are doing for many years, but gave in about 7 years ago and to compensate, I omit the period when I write "Mr" and "Dr" (like the Brits do).
I also gave in and started top-posting in email messages.
Then I realized that the 1st sentence was missing the extra space after the 2nd period, and then M-e jumped to the end of the first sentence.
Yeah, my comment rendered as HTML, which stripped the double-space from the original text I entered.
Using double-space means that the source document is unambiguous, thus you preserve options for whatever renders the text—keep the double-space, strip it, convert it to Unicode, etc.
Huh, didn't know abbrev had that limitation (wonder why?). Gave it a go in espanso (https://espanso.org/), and it does work there.
Edit: it would need context awareness too, which somewhat rules out espanso, otherwise space indentation will be difficult. abbrevs at least can be defined per mode, but ideally it would be based off the face (so it could work in comments or strings).
You could bind it to a Compose key sequence, e.g. "Compose+Space Space". (Analogous to em-dash, which is "Compose-Hyphen Hyphen".)
But it's still an extra keystroke. And I worry that I'd cause problems editing non-UTF-8 documents if I retrained my fingers to use it at the end of every sentence and then didn't remember to switch back to the ASCII way of doing things.
Heh, I recently did a "clean sweep" of my .emacs files (inspired by the new support for `$XDG_CONFIG_HOME/config/emacs/init.el` in 27.1) and something like 90% of it was workarounds (some dating back to the late 1990s, for example a "vertical-motion-fix" for something that was fixed in emacs 19.29)
I definitely recommend doing some form of "dotfile bankruptcy" every 20 years or so :-)
(I also ended up doing a crude "load-file-literate" so that now most of my elisp is actually markdown, inspired by https://github.com/skx/dotfiles )
Some languages use a wider type of whitespace than the regular word separator after a full stop when typeset professionally. (Similarly, when there are abbreviations that involve periods, the space after them can be slightly narrower than the normal word separator.)
The wider form of whitespace is not easy to get out of regular text editors and word processing software, so some people choose to emulate it by entering two regular word separators. (This is too wide, though, if we are being precise.)
I'm just old enough to remember using a typewriter for school work. And at least on the typewriter I used, the period key produced a width of exactly a period. In other words, an extra space was absolutely required just to "fill out" the period. And the small period width allowed you to do a "proper" ellipsis.
I didn't quite realize that was the reason for the double space until these comments, though, as we were simply taught that it was required to put 2 spaces after a period.
I’m sure it was for some people, and that’s what I used and learned in college too, but ever since then I’ve seen no end to “rules” about language that lose their qualifiers over time, are applied out of context, or are sometimes just not true and weren’t rules until someone misinterpreted some advice or just decided to demand their way was ‘correct’ and it somehow spread. It’s pretty surprising how many conventions we have that people consider canonical but didn’t used to be.
Ha! Perhaps I should have said "when/where." I was specifically taught the rule was optional. A brief perusal of the Wikipedia article on the subject helps me understand that it should have been taught as "situational." And I learned about Sir Roger Casement's "hanged on a comma," so that's cool.
Since it took me a minute to track down, here's the short of it so that I don't accidentally nerd-snipe anyone:
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.
Yea, this is a detail that Emacs gets right and a lot of other programs fail at. I really recommend not setting `backup-by-copying` because it introduces extra risks. Of course, I also recommend that every computer have a UPS and ECC ram. Defense in depth!
Posix systems, at least, allow a file's timestamps to be set with utime(2) and related system calls, but a problem with this is that utime with an arbitrary time is not permitted in all situations where writing to a file is possible. Backing up those files would either need a separate strategy or have inconsistent behavior.
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.
Also, little by little Emacs defaults are getting modernized. For example, show-paren-mode is now t and use-package ships with Emacs.
Hopefully, at some stage, make-backup-files will be set to nil. It is annoying to log into any server, launch Emacs and discover you have generated lots of litter. I think at this stage backup files should be opt in, not opt out.
I don't know how this works now, but in the past it was a problematic option. For example, if you used sudo and TRAMP to do some local administration tasks, it would store those files in your own account. This was a security issue.
Potentially a problem when editing any file with secrets, right? (though, tbh if your home directory is compromised you are in a lot of trouble already).
It's practically impossible for "most of them" to be the best, these apps weren't designed by unicorns. And your example is a good illustration: the solution to the backup issue suggested in the post doesn't do away with versioned backups (neither does the other approach linked), so the lack of VCS doesn't explain this bad default
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.
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 agree. Emacs defaults are battle hardened and work well in exotic and regular hardware for all kinds of use cases. I modify defaults to remove the extra fluff (tool bars, menus, scroll bars, yes-or-no), but I see their value to new users. Luckily Emacs is the most customizable editor on the planet so everyone can be happy using it and write their thoughts about it.
> command that already has a key for it is just stupid
backspace is one of the most inconvenient keys, so there is nothing stupid about replacing it with a much more convenient alternative (though the Ctrl default of Emacs is another bad default)
And he's changing the font size, not font
> Putting all backups in the same directory will be inconvenient for files named in the same way.
if only it were somehow possible to create subfolders or slighly change the names and store links in the backup...
Even when I used a more traditional "straight" keyboard I didn't have problems with it... Also, it's usually bigger than character and digit keys, so, really, it's not that hard to press it...
> so there is nothing stupid
I literally wrote what is stupid about it. Please take a minute to read the post you are replying to.
> if only it were somehow possible to create subfolders or slighly change the names and store links in the backup...
This is irrelevant. What if you rename the directory where you worked with files that need backups? Even worse, what if you switched two directories. Or deleted and created afresh... There are plenty of cases where renaming of backups will be very confusing / will do something you didn't intend and for zero gain.
It doesn't matter whether you had problems, you just need to understand that it's easy for other people to have them (the fact that it's bigger doesn't change the fact that it's one of the worst) to realize it's not stupid to replace with a more convenient convention that you use elsewhere
You literally wrote what is stupid with two factors, I wrote why it's not emphasizing the 2nd, so? The frequency of use alone isn't enough, backspace is used even more frequently, so it's more important, hence, again, not stupid to swap
> for zero gain
The gain is mentioned right at the top of the post, so that's not zero
My response was relevant to the issue your raised with file names, your new what ifs are what's not relevant to that exchange
No idea what C-scroll does. Is it same / similar to C-x C-+ / C-x C--? If so, I think it's designed to increase / decrease in steps that would fit into desired resolution... but I'm not 100% sure about it. This is something I never really use outside of situations where I have to present (i.e. show my screen on some large screen for many people to see and the need me to zoom in / out).
I didn't really have problems with this even though I too use a tiling manager (StumpWM).
C-<wheel-up> at that spot runs the command mouse-wheel-text-scale
(found in global-map), which is an interactive native-
compiled Lisp
function in ‘mwheel.el’.
It is bound to C-<wheel-down>, C-<wheel-up>, C-<mouse-5> and
C-<mouse-4>.
(mouse-wheel-text-scale EVENT)
Adjust font size of the default face according to EVENT.
See also ‘text-scale-adjust’.
>the need me to zoom in / out
I just prefer it, if I have little text, for it to be big. Why waste it on whitespace?
writing to a temp file then renaming it to the real location is a long held tradition to avoid partial writes and filesystem corruption if power is lost
There are good reasons for the Emacs default that relate to atomic operations in typical file systems, reliability in shady hardware, or power losses and recovery. The argument of the author about hard links breaking is a matter of choice; some people want this copy on write semantics, others call it broken. Most people would want to avoid hard links to editable files anyways.
Can you explain some of these reasons? I feel like there is an opportunity for me to learn something here.
I don't know enough about filesystems to be sure, but I feel like there are more opportunities for stuff to fail with the move-and-copy technique. E.g. when moving the file it could end up existing twice (if creating the new link happens before removing the old one) or being lost (if removing the old link happens before creating the new one).
If you just copy the file, the copying can fail and you don't have a backup. But if the original is still fine then you never notice a problem with the backup, so this option is preferable (as I understand it).
> Most people would want to avoid hard links to editable files anyways.
Why would you want to avoid this? I though it would be something that Linux can easily handle.
1. Atomicity of Rename Operations: On many file systems, the process of renaming a file is atomic. This means that the operation either completes in full or doesn’t take effect at all. This makes it safer in cases where there might be interruptions, such as power losses. If the rename (which creates the backup in Emacs’s default behavior) is interrupted, you’re left with the original file intact.
2. Concern about Move-and-Copy Technique: Your point about the possibility of the file ending up existing twice or being lost is valid in theory. However, in practice, the renaming operation ensures that such intermediate states are avoided. A rename isn’t quite the same as creating a new link before removing an old one. Instead, it’s a reassignment of the file’s metadata, which is generally a reliable operation.
3. Drawbacks of Just Copying: While just copying the file might seem simpler, it can have issues. If there’s an interruption while writing the new copy, you can end up with a corrupted backup. With Emacs’s approach, since the original is renamed (and thus preserved in its entirety), you’re always assured of having at least one uncorrupted version.
4. Avoiding Hard Links to Editable Files: As for the avoidance of hard links for editable files, there are a few reasons:
Ambiguity: Editing a file that’s hard-linked elsewhere can lead to confusion since changes reflect in all linked locations. This can be unexpected for those unaware of the link.
Data Integrity: If there’s corruption in one location, it affects all hard-linked locations.
Backup Issues: Some backup systems might not handle hard links as expected, leading to either duplicate data or missed backups.
Linux does handle hard links well, but their usage needs careful consideration, especially when editing is involved. They’re great for static data that doesn’t change but can be problematic for editable files.
3. Is unclear, copy may result in a corrupted backup, but the original remains uncorrupted, so you also have one uncorrupted version just like if you renamed the file but couldn't restore the original?
4. That's an argument for raising awareness via better tools, not for avoiding the useful links
> 3. Is unclear, copy may result in a corrupted backup, but the original remains uncorrupted, so you also have one uncorrupted version…
Think about what happens when your power comes back and you start editing that file again. Which is the correct version of the file? How can you tell? Suppose the backup file is newer than the original file, and 99% of the size. Is it a partial copy, or did the user delete some lines and then save?
Now consider what Emacs does by default when `backup-by-copying` is nil and the user asks Emacs to save a file:
1. Emacs deletes the existing backup file (atomic),
2. renames the existing file so that it becomes the backup (atomic),
3. writes the buffer content into a new file with a temporary name (not atomic),
4. calls fsync(2) to ensure that all written data has actually hit the disk¹,
5. finally renames the temporary file so that it has the user’s desired filename (atomic).
If the power goes off anywhere in the middle of that process, then no corruption will occur. The state on disk will be easily observable; it will either be a missing backup file but the original still exists untouched, or it will be a backup file but no original, or it will be a backup file plus a temporary file that might be incomplete, or it will be a backup file plus the new file.
In all of these cases the editor can recover automatically without ever losing anything that was already saved on disk. Sure, in most of those cases we lose the _new_ data that wasn’t yet saved, but after all the power did go out in the middle of trying to save that very data. We’re not magicians here; this is the best we can do.
Of course, in practice the power doesn’t go out all that often and users habitually save the document after every few words, right? So backing up by copying is safe enough that most users who prefer it never lose any data. Probably. At least as far as they know; sometimes this type of corruption goes unnoticed, or gets chalked up to other factors such as inebriation or forgetfulness.
By observing the status of a flag "wasBackupSuccessful", which wouldn't be set to true if there is a power loss after the file was copied (this flag could be set as an atomic rename operation on the copied backup file so that you could tell via the observable file system behavior whether the copy succeeded)
But it is now clear what you meant, thanks for the explanation!
They have basically no css on that site. You should be seeing the default font of your browser. However, if you are browsing in dark mode you should see these colors and a text-shadow:
Another option is to use something like ws-butler[0], which only deletes trailing whitespace on lines you've edited. This way you don't create spurious diffs on version controlled files, which confuse code reviewers and `git blame` users in the future.
This is an awesome mode. I enabled it once and then just left it in there and it quietly does its thing. I really miss it in other editors.
(Of course, $employer enforces whitespace style globally with a linter so the files here can't end up in a state where ws-butler is meaningful. Not sure what I prefer.)
The one issue with this is for things like markdown where a code block is space-indented - if you want an empty line as part of the code block rather than two code blocks then you need a line that contains -only- the indentation.
I would expect that emacs being emacs it's trivial to configure such lines to be left alone when relevant, but it's worth remembering that the edge case exists.
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.
Ditto. It's rare, but I've had situations where I've e.g. "git reset --hard" in the wrong directory or otherwise clobbered editted context, and the fact that the editor leaves a side channel to recover from is really helpful. I'd be terrified to turn this off, and in practice none of the tools I use have trouble with these files, so I don't see the advantage.
I have on one occasion deleted a config file that I would have to completely rewrite if I didn't have my Emacs backups. That said, I keep them under $XDG_CONFIG_HOME/emacs/backups, so I don't have to worry about littering.
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.
This one struck me as something that elicits a bad knee-jerk reaction despite there being a good reason for it. I seem to vaguely recall something regarding moving vs copying related to file system atomicity, but can't remember the details right now.
Yes. The move rename operation is atomic in any reasonable file system. With the default behavior Emacs can always keep the previously known good data in place even under power failure, disk failures, etc. if the new file is corrupt you go back to the exact old data (no bits moved in the disk.)
It all just looks like ordinary black on white to me. Somebody else was was complaining of blurry text, also not obviously in evidence on my PC (Firefox, Windows) or iPad, so perhaps browser-dependent.
It changes based on the `prefers-color-scheme` CSS media query. When the value is `dark`, the page shows a yellow font with an orange glow over a dark background, otherwise it shows black on white.
- 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.
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.
I know of at least two `mg` users (a barebones C impl of emacs) that use it for almost everything (including c++ and python). That's `emacs -Q` to the extreme.
While I'm mainly an emacs user, I do enjoy using mg from time to time. Especially nice that it comes with macOS nowadays (used to come with age old emacs version). I could probably do everything in mg, but I just cannot stand the auto indendantion in it when you have 8 spaces of indent and write a newline, the next line gets auto indented with a tab instead of 8 spaces (newline-and-indent assumes tabs are every eight characters..) Sure, this is not an issue if you use only tabs, but most projects just tend to be using spaces. Also, I think in OpenBSD mg there is a flag for enabling/disabling this (IIRC).
au!
set noai
set sm
set cp
setf none
set nocindent
set nosmartindent
filetype off
inoremap <Left> <NOP>
inoremap <Right> <NOP>
inoremap <Up> <NOP>
inoremap <Down> <NOP>
noremap <F1> <NOP>
inoremap <F1> <NOP>
cabbr h you_typed_colon_h_again_you_idiot
nnoremap q <NOP>
autocmd FileChangedShell \* echon ""
set directory=/tmp
set mouse=
set ttymouse=
# try uncommenting this if angry fruit salad still ensues:
# syn off
Yeah, it's a recurring issue and question. Even simple things, due to age of emacs itself, appear alienating to many. Until they absorb the culture and start seeking emacs bindings in other programs (thanks you readline I guess)
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.
Being one of those people that still recommends Emacs and have sunk countless hours in my personal dotfiles: I kinda enjoy doing it, that's why I am doing it. It feels great having a configuration so tailored to me personally that it almost feels like clothing or other lifestyle choices. I mean sure, clothes, makeup, cars and whatever are all also huge wastes of time and resources in our short and mostly dreadful lives, but at least Emacs still brings me joy :-)
As one of those tragics who can't stop tweaking my Emacs setup, I'm not sure I disagree with your conclusion.
That said, I don't think you can draw too many conclusions about Emacs from how difficult it is to turn Doom into your own bespoke setup. It abstracts a huge amount, drastically changes default behaviours, and basically needs an entire new ecosystem of Doom compatible packages, of varying quality, to make it work. I often advise that even if people plan to go Doom or Spacemacs, they should spend a week or two trying out vanilla Emacs with their own customisations applied as they go.
Not only do people tend to warn up to them, but even if they still choose to go down the Doom/Spacemacs/Whatever route, they have a better understanding of what's being abstracted away, and how to sometimes glue things back together when something breaks.
Then don't use Doom Emacs. As a more than twenty year emacs user, I've been using Doom Emacs the last two or three years. Since, I have better things to do than to update every Doom Emacs to the latest unstable version of a few hundred Emacs packages, I've two or three months between updates. This broke regularly the doom script and or straight.el builds. I've debugged it once and found out that that starting with the default Doom configuration works. And then you can add module by module. Whereas installing all modules I wanted, at once, failed.
Therefore, I dropped Doom Emacs and am very happy with my new clean Emacs config.
In my opinion, it’s not something you should try to do all at once. Install Emacs, even the normal “vanilla” Emacs, then start using it. (If you’ve never used it at all, start with the tutorial.) You can configure things as you go. You’ll probably keep trying new options and packages for the rest of your life, spending a few minutes here and there as you try new things or hear of a good idea from someone else.
What do you mean by "configuring emacs"? Despite what the article says, emacs is imminently useable right out of the box. Though you're not wrong about emacs being a black hole :)
Critisizing sophisticated tools though, that's like saying we should go back to drafting tables rather than use autocad because the learning curve is steep. Once you learn the tool it accelerates everything you do.
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.