[...]
Wrong. You can still give no immediately response, e.g. by changing to another document or just viewing the document. Requiring an action if you are actually going to deal with the document in question is OK for me.
Well, I don't really agree with being forced to do something to continue use of a file, *I'M* in charge of this program, not the other way around </rant> but its not that big a point.
It comes down to whether the user would want the editor to protect them from editing a document that they actually want to reload first. Note that in this scenario edits can happen from 'Replace All in Session', i.e. without even switching to the document that is changed on disk.
Yes, thats a problem scenario, at least if you also do a save-all without checking. I guess setting the file read-only is a simple way of doing that.
But should we then indicate that some replacements were *not* made due to the read_only buffers. ATM the replace_in_session() calls document_replace_all() which calls document_replace_range() which finally checks for read_only and simply returns 0 changes made. Probably replace_in_session should do the readonly check and report how many buffers were skipped for that reason.
Also if you do switch to the tab of the file changed on disk it will have both buffer changed (red text) and file changed infobar conditions, probably more confusing than helpful since I suspect many people have the same idea as Matthew, that red text indicates *any* condition that causes the buffer to not match the file, whereas it really means that the *user* has changed the buffer. This situation will be avoided if the buffer is read_only.
Cheers Lex