3 ms·

This is interesting. I guess it's so that if you cat a file, it doesn't clobber your cursor? I've always noticed that git will say "No new line at end of file",

by notJim 14y ago

This is interesting. I guess it's so that if you cat a file, it doesn't clobber your cursor? I've always noticed that git will say "No new line at end of file", but I've never really known if that's a bad or good thing, or why it matters.

bingaling 14y ago
Some unix tools (I can only recall Vixie cron at the moment) won't read the last line in a file if it isn't terminated with a newline.
benatkin 14y ago
When someone opens up a file created with Sublime Text 2 with vim or emacs and saves it, it clutters the commit messages. It's clutter whether the file contains other changes or not. It still shows up in diffs unless you suppress whitespace.
- notJim 14y ago
  I would argue that the person with their vim set up to create that clutter is to blame here. If there's no objective reason to fix it other then "well, this is what vim does", then fix vim.
  - codygman 14y ago
    If i'm not mistaken, it is the lack of inserting a newline on sublimes part that is to blame here. It doesn't just break vim, but other software such as cat, git, etc.
    - benatkin 14y ago
      You are correct.
    - drcongo 14y ago
      Adding "ensure_newline_at_eof_on_save": true, to the user settings fixes this.
  - benatkin 14y ago
    Some might argue that when you save a file that hasn't changed that should be a no-op. I don't think so, though. I appreciate a program that does exactly what I tell it to do.
- martinced 14y ago
  First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical)... But I'll bite. First the parent mentioned "if you're on Unx". What makes you think you* are the one correct with your text editor's behavior and that the traditional Unxy way of doing it is not correct? (and OS X is a Unx variant). Then it's trivial to modify Emacs so that it exhibit the behavior you want. Is it trivial to modify Sublime Text Editor 2 to that it behaves on Un*x like vim and Emacs do? I'll never ever understand "programmers" who aren't using a programmable text editor. But I don't care: time is on my side. Emacs was there 35 years and still shall exist long after all these glorified Notepad shall long be dead ; )
  - benatkin 14y ago
    The diff tools can ignore the reality of the files, but it would be a foolish default. It's right because the vast majority of newcomers believe that they are adopting UNIX and having a newline and the end of a file is an important tradition. There are some good places to upset the status quo but this is not one of them.
  - pretoriusB 14y ago
    >First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical). As long as you (or anyone else) doesn't write any new cooler diffs (though part of what you ask already exists), what they "should do" doesn't matter and doesn't change the fact at all. Actually it reminds me of the "sufficiently smart compiler": http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler
  - nicholassmith 14y ago
    "I'll never ever understand "programmers" who aren't using a programmable text editor." I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them. Sublime is perfectly programmable through judicious use of plugins and snippets anyway. A subset of that, I'll never understand emacs users.

by notJim 14y ago

bingaling 14y ago

Some unix tools (I can only recall Vixie cron at the moment) won't read the last line in a file if it isn't terminated with a newline.

benatkin 14y ago

When someone opens up a file created with Sublime Text 2 with vim or emacs and saves it, it clutters the commit messages. It's clutter whether the file contains other changes or not. It still shows up in diffs unless you suppress whitespace.

notJim 14y ago
I would argue that the person with their vim set up to create that clutter is to blame here. If there's no objective reason to fix it other then "well, this is what vim does", then fix vim.
- codygman 14y ago
  If i'm not mistaken, it is the lack of inserting a newline on sublimes part that is to blame here. It doesn't just break vim, but other software such as cat, git, etc.
  - benatkin 14y ago
    You are correct.
  - drcongo 14y ago
    Adding "ensure_newline_at_eof_on_save": true, to the user settings fixes this.
- benatkin 14y ago
  Some might argue that when you save a file that hasn't changed that should be a no-op. I don't think so, though. I appreciate a program that does exactly what I tell it to do.
martinced 14y ago
First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical)... But I'll bite. First the parent mentioned "if you're on Unx". What makes you think you* are the one correct with your text editor's behavior and that the traditional Unxy way of doing it is not correct? (and OS X is a Unx variant). Then it's trivial to modify Emacs so that it exhibit the behavior you want. Is it trivial to modify Sublime Text Editor 2 to that it behaves on Un*x like vim and Emacs do? I'll never ever understand "programmers" who aren't using a programmable text editor. But I don't care: time is on my side. Emacs was there 35 years and still shall exist long after all these glorified Notepad shall long be dead ; )
- benatkin 14y ago
  The diff tools can ignore the reality of the files, but it would be a foolish default. It's right because the vast majority of newcomers believe that they are adopting UNIX and having a newline and the end of a file is an important tradition. There are some good places to upset the status quo but this is not one of them.
- pretoriusB 14y ago
  >First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical). As long as you (or anyone else) doesn't write any new cooler diffs (though part of what you ask already exists), what they "should do" doesn't matter and doesn't change the fact at all. Actually it reminds me of the "sufficiently smart compiler": http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler
- nicholassmith 14y ago
  "I'll never ever understand "programmers" who aren't using a programmable text editor." I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them. Sublime is perfectly programmable through judicious use of plugins and snippets anyway. A subset of that, I'll never understand emacs users.