1. 26
  1.  

    1. 15

      My favorite conspiracy theory: Emacs has bad defaults on purpose, because using it unconfigured is so unbearable that it serves as great motivation to learn how to write Elisp. (Bonus: also works for XMonad/Haskell!)

      Things can get weird when your files don’t end in a newline.

      I’ve actually had production data loss due to a design bug in cron where if the last line doesn’t end in a newline, it gets completely ignored with no warnings! Very fun, and also the first time a piece of software made me want to punch the author.

      1. 5

        Unfortunately parsing newline or EOF is a really common oversight that AFAIK almost every significant grammar has encountered at some point (so don’t go punching any authors ;]). It requires a lookahead to define properly so many parser generators can’t even do it natively in the grammar itself (but there are plenty of workarounds).

        For example:

        file: LINE_COMMENT* EOF;
        WHITESPACE: ... -> skip;
        LINE_COMMENT: '#' .*? [\r\n]+;
        

        This won’t parse any comment that ends in an EOF instead of a newline. But you can’t simply accept [\r\n]+ | EOF to terminate the line comment either as it will consume the EOF (and the file rule will fail). If you remove the EOF from the file rule (and also don’t check that all input was consumed), the last line(s) that fail to parse will be silently ignored similar to the cron behavior you describe.

        1. 5

          so don’t go punching any authors

          In the end I had to settle for making fun of those absolute nincompoops in the comments section on various tech web sites; not quite as satisfying but still OK.

      2. 4

        I’ve actually had production data loss due to a design bug in cron where if the last line doesn’t end in a newline, it gets completely ignored with no warnings! Very fun, and also the first time a piece of software made me want to punch the author.

        I’m not sure if this was the cause, but traditional UNIX lex / yacc required inputs to end with a newline and would not detect an end-of-file marker without it. This fed into the C specification (fun fact: it is undefined behaviour in C if your file does not end with a newline character and the compiler is allowed to do absolutely anything when it encounters it because the original C compiler would fail in weird ways).

        1. 5

          absolutely anything

          Nasal demons!

          It just occurred to me that probably most of the people here are too young to have used Usenet in anger. The explanation:

          Recognized shorthand on the Usenet group comp.std.c for any unexpected behavior of a C compiler on encountering an undefined construct. During a discussion on that group in early 1992, a regular remarked “When the compiler encounters [a given undefined construct] it is legal for it to make demons fly out of your nose” (the implication is that the compiler may choose any arbitrarily bizarre way to interpret the code without violating the ANSI C standard). Someone else followed up with a reference to “nasal demons”, which quickly became established. The original post is web-accessible at http://groups.google.com/groups?hl=en&selm=10195%40ksr.com.

      3. 1

        A warning would be ideal, but if you go stuffing invalid text files in all over the place you gotta expect things to break sometimes…

        1. 8

          No.

          If your definition of “valid” depends on differences that are literally invisible to the naked eye, then it’s a bad definition and you need to make a better one.

        2. 1

          I don’t see how this is relevant to the parent comment

    2. 7

      I know about these settings and the only one where I make the same choice is require-final-newline. I strongly disagree with some others like the C-h one.

      I very much appreciate that unlike most software these days Emacs doesn’t try too hard to chase the latest fads and that it values stability. A stable default that I disagree with is much better than constantly changing behaviors and having settings you relied on disappear with every release.

      Emacs is one of the few pieces of software where a new release is something I look forward to instead of worrying about what functionality will be gone this time.

      1. 11

        unlike most software these days Emacs doesn’t try too hard to chase the latest fads

        The latest fads like … representing backspace as ctrl-H? Or the latest fads of putting backup files in a backup directory instead of any old place on the disk?

        I mean, I agree with your overall statement, but I don’t see the connection to any of the things suggested in the article. They all seem to be timeless improvements that would have been worth doing in the 90s as much as today.

      2. 4

        Re ^H, I also disagree with the article and agree with the Debian keyboard configuration policy.

        More broadly I am mildly vexed by the common conflation of backspace with backspace+delete. It’s kind of sad that we lost backspace and overstrike in the transition to video terminals: I don’t know if it still occurs anywhere other than the weird co-operation between man and pagers. I am also grumpy about the words used for legends on keyboards. Bah.

    3. 2

      I went looking through this article to see if any of these were new to me, and realized the vast majority of these are already in my config - one of these days I should get around to writing a similar post. My .emacs is littered with comments about weird defaults.

    4. 2

      A project that is so big is difficult to make everyone happy. There may be users sticking with un-configured emacs and the defaults (bad in many’s opinions) work for them. Even if it is not, the compatibility reason can win.