Hacker News Reader

Comment by rogerbinns | Hacker News Reader

My pet peeve with editors is how they handle files changing underneath them. I do this regularly enough (eg I might make a quick change using vi, source control update), there could be ssh or sshfs involved, or another tool might be better for doing whatever it is that I wanted.

Emacs has been the only editor that has never lost a change for me. Whenever you try to make a modification it checks the underlying file is as expected, and tells you if not. I tried SL2 and it quite happily ignored the fact that the file had changed. I'm also evaluating AppCode and it has perhaps the worst behaviour - it silently updates the editor window. But some of the time it doesn't notice the change and hence overwrites it. Consequently you can't trust the editor.

gedit also notices changes proactively (compared to emacs' reactively) but I don't use it regularly.

View on HN

> I tried SL2 and it quite happily ignored the fact that the file had changed.

Weird. I use Sublime Text 2 exclusively across all three platforms. Whenever an open file changes (e.g. I sync to Perforce), it pops up a modal dialog box when I bring that file's tab back into focus. If you're referring to a file that's changed in the background as you're actively editing it, I admit I haven't tried that.

Have an edit window open, and then go in via a terminal/vi and change/save the same file. Then see what happens.

Yes, that what's I was describing. It works just fine. When I tab back to Sublime, I get the "<filename> has changed on disk. Do you want to reload it?" modal dialog box. (If there are no unsaved changes in the Sublime buffer that could be clobbered, it just reloads the file silently as you'd expect.)

It didn't work when I tried a few weeks ago. I am running on Linux.

My test just now was on Windows, but I use it regularly on Mac and Linux as well, and I'm pretty sure I would have noticed if it silently clobbered changes like that. You're sure you had unsaved changes to the Sublime buffer for the file when you conducted your test?

Works fine on Linux/Windows when ever something changes on both..

Works fine for me. Ubuntu 12.04 with an Ext4 filesystem. Perhaps you are using an unusual filesystem or working over the network?

I'm using btrfs. In any event it sounds like my test must have been flawed. Perhaps I didn't notice it doing an auto-reload.

I don't know what mechanism SL uses. A lot of my current work is using sshfs with editing happening on Linux and the endpoint being MacOS. inotify won't work for that, but more paranoid and repeated stats will.

Sublime text will auto-reload a file which has changed if you have not edited it, without prompting. It only prompts if you have local changes.

It'll automatically reload if you don't have any unsaved changes, if you have, it will ask you to reload

Works fine for me, on Linux. Mine usually just changes it to the new contents without a modal, but Ctrl-Z can reverse.

Same here (on Mac) - it's always had this behavior for me.

The only problem along these lines I've had with it is in renaming files, where it doesn't appear to be locking onto the inode and the previous-named file still remains in editor and can be saved with the old filename. OOB edits do get reflected back into the editor somehow, though.

Vim produces a warning whenever you focus on the window, asking if you want to keep your current work or load the changed file. If you keep your work, it reminds you yet again if you attempt to save over the changed file, just in case.

Works fine for me - http://i.imgur.com/mnAA8nw.png

If the fine hasn't been changed in SL2, it just reloads it with a message displayed in the status bar. If it has been edited in SL2, it asks if you want to reload the file.

Wow .. wouldn't it be nice to get the diff lines highlighted in ST3. Then you get theirs/mine option on each line (with an 'all' option of course).

Surely not hard to implement (if it's easy to say, it's easy to code, right??)

Considering the massive API changes (out of process etc) with the API this should be an awesome plugin!

You can find out the (highlighted) differences between the in-memory buffer and the on disk version one via "Show Unsaved Changes" on the context menu.

When I halted my evaluation of SL because of this issue I did send them feedback about it, but never got a response. I did have some other far lesser concerns like wasted space if you turned line number off.

I think I've also experienced this, but in my case, I was remotely editing via Transmit/SFTP. So, the problem might be in Transmit cache.

kate[0] can cope too with modified or deleted open files (see http://kate-editor.org/wp-content/uploads/2012/10/step4.png for an example)

[0] http://kate-editor.org/about-kate/

Reply on news.ycombinator.com