[HN Gopher] Bad Emacs defaults
___________________________________________________________________
Bad Emacs defaults
Author : ctrlmeta
Score : 100 points
Date : 2023-10-11 13:10 UTC (2 hours ago)
(HTM) web link (idiomdrottning.org)
(TXT) w3m dump (idiomdrottning.org)
| avgcorrection wrote:
| 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
| pama wrote:
| 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.
| globular-toast wrote:
| 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.
| pama wrote:
| 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.)
| ceving wrote:
| show-trailing-whitespace is quite annoying in ansi-term. Emacs is
| actually my tiling wm, because I need tiling only for terminals.
| clankyclanker wrote:
| 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)
| pmontra wrote:
| > why is the font blurry? My poor eyes
|
| 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:
| @media (prefers-color-scheme: dark) {body, a, a:visited {
| color: #feec7c; background-color: #1e0708; text-shadow:
| 0 0 3px #fde02d, 0 0 12px #b74312;}}
|
| Maybe that shadow is the blurriness you are experiencing.
| Unfortunately I can't check, I don't even know how to switch my
| browser to dark mode.
| dpifke wrote:
| 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.
|
| [0]: https://github.com/lewang/ws-butler
| kqr wrote:
| 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.)
| mst wrote:
| 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.
| ceving wrote:
| I never use indent in markdown. I always use ~~~. This makes
| copy/paste much easier.
| pmontra wrote:
| I use ``` code ```
|
| of course as first characters of lines. It appears indented
| here on HN.
|
| I didn't know about the triple tilde.
| pmontra wrote:
| Another way is to delete whitespace only in some modes. Example
| from my .emacs (setq-default show-trailing-
| whitespace t) (defun delete-trailing-whitespace-hook()
| (add-hook 'before-save-hook 'delete-trailing-whitespace))
| (add-hook 'ruby-mode-hook 'delete-trailing-whitespace-hook)
| (add-hook 'python-mode-hook 'delete-trailing-whitespace-hook)
| (add-hook 'lisp-mode-hook 'delete-trailing-whitespace-hook)
| systems wrote:
| ;; 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
| diekhans wrote:
| 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.
| jrockway wrote:
| I'm pleased to report that after turning off backups and auto-
| save files over a decade ago, nothing bad has ever happened.
| a-french-anon wrote:
| I just put them in a central place, personally:
| (setq auto-save-file-name-transforms '((".*"
| "~/.emacs.d/autosave/" t))) (setq backup-directory-alist
| '(("" . "~/.emacs.d/backup")))
| pama wrote:
| I like backups as a reminder that some file is not under
| version control.
| jpmattia wrote:
| 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.
| eviks wrote:
| 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
| nextos wrote:
| 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.
| mksybr wrote:
| I would rather the default change to put backup files in
| XDG_CACHE_DIR then not have them
| ParetoOptimal wrote:
| 100% agree. See my other comment using no-littering.
|
| If you place your emacs config in ~/.config/emacs it's
| pretty close to ideal.
| nextos wrote:
| 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.
| ParetoOptimal wrote:
| That's a good point. It seems smart to use the default
| backup behavior whenever tramp is used.
| jonnycomputer wrote:
| 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).
| gwbas1c wrote:
| Interview with an Emacs Enthusiast in 2023 [Colorized]:
| https://www.youtube.com/watch?v=urcL86UpqZc
| PaulHoule wrote:
| 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?
| crabbone wrote:
| 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.
| elsjaako wrote:
| I also don't understand why the backups are done the way they
| are. Why not just copy the current file to the backup, and not
| break hardlinks?
| tmtvl wrote:
| I agree, backup-by-copying should be t by default.
| pama wrote:
| 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.
| mksybr wrote:
| They're changing font size, not fonts. I often C-scroll to zoom
| in, if there isn't a lot of text as I rather big fonts over
| lots of whitespace.
| eviks wrote:
| Speaking of understanding:
|
| > 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...
| pama wrote:
| 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.
| sourceless wrote:
| As someone with astigmatism, the glow on the text makes it near
| impossible to read.
| tom_ wrote:
| 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.
| drewg123 wrote:
| 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.
| jerf wrote:
| 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.
| [deleted]
| onedognight wrote:
| That file is there while there are unsaved changes. Save the
| file or undo the changes and it goes away.
| ParetoOptimal wrote:
| > Emacs decides to leave one of its .#filename symlinks around
| that don't point to anything,
|
| Yeah, it breaks other various compilers like ghc too.
|
| I fix it with: (use-package no-littering
| :demand t :config (no-littering-theme-
| backups) )
|
| https://github.com/emacscollective/no-littering
| brensmith wrote:
| 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.
| dahart wrote:
| 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.
| gwd wrote:
| 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.
| dahart wrote:
| 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
| 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.
|
| [1]
| https://link.springer.com/article/10.3758/s13414-018-1527-6
|
| [2] https://www.grammarly.com/blog/spaces-after-period/
| bspammer wrote:
| 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.
| LanceH wrote:
| The rule was definitely on the typewriter.
| dahart wrote:
| 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.
| IggleSniggle wrote:
| The Oxford comma wasn't a rule when I was a kid, but at
| least that rule has some good reasoning behind it!
| dahart wrote:
| It was a rule somewhere, right? It was printed in a style
| manual in 1905. (I am totally assuming you're not 115
| years old. ;) )
| IggleSniggle wrote:
| 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.
|
| The comma, btw, was slightly wider.
| spookthesunset wrote:
| Also learned two spaces and our class was taught on some
| ancient 8088's
| dpifke wrote:
| I still use double-space after sentences because I like
| semantically distinguishing end-of-sentence from mid-sentence
| abbreviations.
|
| i.e. if point is at the beginning of "This is Mr. Smith's hat.
| It is green." I want next-sentence to advance to "It", rather
| than "Smith".
| kqr wrote:
| 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.)
| BeFlatXIII wrote:
| 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.
| Finnucane wrote:
| 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.
| zvmaz wrote:
| I wonder if there's anyone who uses Emacs defaults and only that.
| emidln wrote:
| 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.
| Narishma wrote:
| I do. I also use vim defaults. Yes, I'm one of those weirdos
| using both emacs and vi.
| mst wrote:
| I prefer -vi- defaults so: 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
| ataylor284_ wrote:
| 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.
| db48x wrote:
| 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!
| cyrialize wrote:
| 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.
| mst wrote:
| > 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.
| snicker7 wrote:
| YAML was a mistake. Couldn't count how many issues I and my
| colleagues encountered due to white space misalignment.
| entropie wrote:
| 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.
| jonnycomputer wrote:
| Is this in text mode? I don't think this happens when editing
| python or bash scripts.
|
| But as a default for any mode that cycle is ... nuts. Though
| I'm sure there must have been some reason for it.
| ParetoOptimal wrote:
| 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/
___________________________________________________________________
(page generated 2023-10-11 16:00 UTC)