I think it is hiding whether it already loaded the file, not whether it saved your modifications. An unsaved file should be marked as such, always. Not doing so is insane.
It would make me leave Emacs for it only if there were modes for most programming languages I use, and they were better than the Emacs ones. That would be tough.
edit: actually.. it saves automatically. There is no "if" (barring bugs.. but a bug in saving could destroy your code in any editor).
> Open files can be in a “dirty” state, i.e. they may have unsaved changes and this needs to be visible to the user. Zed argues that there is no good reason anymore for for files to be in a dirty state, ever. The days where saving to disk took a minute are over. Constantly saving files simplifies a lot of things and good undo functionality and version control can help in reverting a file to its previous state, even after saving or after closing and reopening a project.
edit 2: from the vision, a lot of its "innovations" were actually implemented on Emacs.. like "Unifying file navigation and creation" and editing remote files.
From the page linked from the OP link:
> Zed has no concept of open files (or tabs). You can navigate between files quickly and efficiently using its goto UI (Command-E/Ctrl-E), which sorts files based on date of last opening and can be used to quickly find the file you’re looking for. Whether the file you’re selecting is already in memory or is loaded from disk (or over the network) is completely transparent. Why would you care?
When reading about Zed (http://zedapp.org/vision/) the author makes the case that having to track open files is a pointless. It is an interesting view of the world. I personally have too much muscle memory working against me, but I can see the perspective.
Vim with autowriteall, undofile, undolevels, undoreload, nohidden -- basically will just be editing thing represented on disk -- with survival of undo and so forth between undoes.
I know this sounds weird, but a Chromebook. Even though I use a Windows/Linux dualboot as my main computer, I like Chrome OS because it's fast, and Chromebooks have great battery life.
There are IDE's for it, like Zed.
I did it for awhile, but I'm on a macbook air now.
If you are going 100% chrome os, the coolest editor is probably zed. It's a little different from notepad++ though :)
If you are willing to enable developer mode, you can use crouton to run any editor that can run on debian or ubuntu. I used crouton to run sublime text, plus a web server etc for web development. Crouton can even run linux apps in a tab within chrome os which is cool.
I didn't really like chrubuntu as much. It seemed a lot less stable and it never worked as well as chromeos for me.
Oh, chrome os does have a terminal. It's pretty limited but you can use it so ssh and stuff.
Downsides:
Using crouton I had some weird hardware problems. I had to do a lot of trouble shooting to get usb -> serial adapters working correctly. I don't remember why. To get my n64 controller to work I had to recompile the kernel, even though it's plug and play with regular ubuntu. I had some hdmi issues too.
I quickly ran out of space on the 16 GB SSD after installing linux. I upgraded the SSD but that required completely disassembling the chromebook.
If I did it again I would try something like GalliumOS. The hardware is decent for the price but I would rather have a proper linux install. Chrome os didn't suffice for development and crouton/chrubuntu always had problems.
I get what you are saying. I used to use :e!
a lot to discard changes I didn't want to keep.
Now, with autosave on, I just use undo or manually revert the changes. The undotree plugin helps if the state I want to revert to was a really long time ago. There's also version control (e.g. in git you can use a detached head).
With autosave, I like that I don't have to think about buffers being a distinct concept from files on the file system. The buffer contents and the file contents are always the same (except for new buffers with no associated file).
BTW, I also don't keep a track of or micromanage my buffer list (e.g. I don't use the :ls
command or the :b-family
of commands). Any file I want to open, I open from the file system (using :edit
, the dirvish plugin, or fzf plugin).
The influence for this is Zed: http://zedapp.org/vision/ I'm glad that I can customize Vim easily to the tune of Zed's philosophy.
I don't recommend Sublime myself, because it's not open source and its future is unsure (version 3 was promised long ago…). So you shouldn't tie yoursefl to it. For something similar there's Atom and Zed (http://zedapp.org/).
Zed is pretty cool. It can do all the things you listed except that there are no tabs, which was a deliberate design choice (go tabless for a while, it's an interesting experience).
Hint: with Zed it's ctrl-e rather than ctrl-p. You will use it a lot since there are no tabs.
As long as you have SSH access to the server, Zed is a really good option!
It has a remote editing function that uses a Zed server as a proxy to make the changes to the server code. Very cool.
I wish him well but I'm surprised nobody commented on
http://zedapp.org/features/edit-remote-files/
which seems incredibly insecure and unnecessary to me(I admit I'm not a great programmer or a security expert).
In the vision it states
> Zed has very innovative support for editing files on any Internet-connected server without the need to use WebDAV or (S)FTP. This means you can always use your local Zed editor with all your favorite customizations.
Whats wrong with sftp? I've used multiple text editors that download files locally using sftp or other network abstractions, and sync back on save. It works wonderfully. Trusting a server to proxy files for editing allowing it to theoretically send commands to overwrite any file the proxy user has access to(I'm guessing it should be able to do that) sounds like a terrible idea(assuming the proxy app doesn't sandbox the directory it gets passed but only starts the file management at that spot). Sure you can run your own server(and examine its source) but
Not to mention that the instructions instruct the user to download the proxy app over http each time.
The only advantage I can see is that it may work around some firewall/VPN config issues(though wouldn't it possibly have other issues talking from the remote computer to the zen server). Unless the reason for this is to work around limitations around implementing sftp/smb/etc. in javascript.