Hacker News Reader

Comment by notJim | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

You are correct.

Adding

"ensure_newline_at_eof_on_save": true,

to the user settings fixes this.

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.

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 ; )

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.

>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

"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.

You can use both Emacs and vim in this "judicious use of plugins" style, and there's such an abundance of starter kits and battle tested configurations that the default of either is nothing you need to spend hours configuring your way out of.... There's a reason why these tools are so long lasting, and both absorb every new feature displayed by new editors. TextMate is clearly surpassed by Sublime, even though you could feasibly mod it to adopt those features which make ST2 better.

Emacs (and possibly Vim) could also implement any feature you could reasonably expect from a text editor, and in many cases it already has them, you maybe just don't know.

But this is 2013, and you're not alone, people all around the world are improving Emacs all the time, and have been for 30 years+ ... you don't HAVE to do all the work, you can just use it.

As the man says, Emacs and Vim will be here long after John Skinner has got tired of ST2 and quits developing it.

> I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them.

I have no desires to spend hours configuring my editor, but I need an extensible editor.

> Sublime is perfectly programmable through judicious use of plugins and snippets anyway.

Yes. Sublime qualifies as a programmable editor.

Reply on news.ycombinator.com