[Geany-Devel] [RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)

Lex Trotman elextr at gmail.com
Sun Dec 9 08:49:44 UTC 2012


[...]

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


More information about the Devel mailing list