> App should just save automatically.

Oh god please no. Apps that save automatically are the worst idea ever. I want to be able to make exploratory modifications, and then commit to disk AT A TIME OF MY CHOOSING. The computer doesn't know what I'm thinking, and it can't tell the difference between "messing around" content vs "serious" content.

I can see it now: I hit undo a bunch of times to get back to a previous state, copy some content that I wanted to bring back, then redo a bunch of times to get back, except I fatfinger it and hit paste by mistake. Now my whole redo path is gone, and I can't even reload to the state I was at before hitting undo thanks to the braindead program that "helpfully" saved my document behind my back.

Or even worse: I make some exploratory changes, then decide after changing a LOT of things that it won't work. The app crashes/the computer dies, whatever. I reopen the app and it's saved all the changes I don't want anymore. Maybe if I'm lucky it would have saved an undo path (unlikely), but even then, how far do I have to undo to get back to the sane state I was in?

Save means "I'm sure this is what I want. Persist these changes".

Personally, I think in a perfect world there would be a more widespread distinction between "save" (something that happens automatically whenever changes are made, to "save" the data from some unexpected calamity like power failure) and "commit" (what you're talking about, which most people think of as "saving"). I doubt it would realistically catch on any time soon outside of tech circles, though, due to the confusion it could cause the average user - "New, open, print, commit, exit... now where the hell is the damn save button?!"

Actually, it's the concept of 'save' that is unintuitive. The EPOC systems just kept your data, and it's one of the nice features that sublime gives you. In an ideal world, a document would keep its entire change history as a graph (not just a single line), and you wouldn't 'save' a copy, you'd name a particular revision of it so that it was easy to get back to later.

Then you would have to have millions of buttons for the millions of things people do with files. The beauty of the filesystem is that a single function (save) can be extended by other programs into many things. (Source control, file transfer, editing in another program, ect.)

The fact that you don't manually save does not mean the files aren't represented on a file system. Source control, file transfer and editing in another program can work unchanged.

Though you would need to worry about atomicity when having a file open in two editors constantly "auto-saving" the document; you'd need some way to synchronise state. Probably easiest to make file write access exlusive by default.

That's a great idea if we all had a versioning file system (or for that matter if the filesystem could be a bit more abstract from the actual bits on the disk), most of us do not. Because there are many cases I can think of where you don't wanna save.

Exactly. Save itself is the problem. Every change you make should be by default persisted. You shouldn't 'save' a current state, you should make named revisions you can roll back to easily.

> What if...

Are you talking about the "share" button? On Android this is three dots in an equilateral triangle, with two of three sides connected by a line.