Geany improved a lot in protecting users from unintentional file overwriting when a file was changed outside the editor. However, Geany is missing one step. After the file content was changed, Geany informs users, offering one of three options: discard changes and reload the buffet content, discard the file content and overwrite from the buffet, or Cancel (means do nothing). Often users don't want to discard anything and select Cancel. However, later, when we intend to save, Geany doesn't remind anymore that the buffer content was older than on disk. There are many reasons why text editors should always confirm with users before overwriting the file. That is the standard behavior of the most of editors, such as vim, gedit, emacs, and much more. Geany should match other editors in this aspect, too.
So the problem isn't that Geany _doesn't_ warn you about overwriting, it's about _when_ it reminds you?
Buffers that are changed are always newer than the file so there is no warning on that, or you would get it every save.
And when the user selects cancel on the file changed dialog the buffer becomes a normal changed buffer, and the user can change it, so there is no following warning because there is no way of checking its newer or older than the file.
Might be I was not very clear. Geany is one of few editors that monitors file status right during the session. That is great! When a file was changed outside we receive a warning "The file '/....' on the disk is more recent than the current buffer." Reload/Overwrite/Cancel We select Cancel to see changes. Right? But, people can be distracted, and later we can press "Save All", for example. This file will be overwritten without further warning. One day I lost a content in a similar way, and after it I researched what other editors are doing in that case. gedit, emacs, vim, and many other editors warn every time when "the file on the disk is more recent than in current buffer", and not just once.
What exactly is the logic of those editors? And how would it interact with Geany's existing testing?
Maybe I didn't make the Geany logic clear. When Geany detects a file on disk has changed after the user selects "cancel" the date/time on the buffer has to be updated to match the disk, or the info bar will keep reappearing. So now when the buffer is saved it matches the date/time of the file, so no warning would be generated even if the test was done at save.
The other editors don't do the check until save time and so never update the buffer date/time before that, so they can generate a message at save time.
Oh, right! You update the timestamp on cancel, otherwise it will be looping. Then, might be, to add Save As button? Reload-Overwrite-Cancel-Save As ? Then we will have all the control in place.
Yes, a pull request to add save-as to the infobar options would likely be accepted.
Can't you just use `Cancel` and then `Save As` instead of complicating the infobars?
Oh well, one dissenting voice, make that "might be accepted"
I agree with Matthew Definitively I can use Save As right after Cancel, and we don't need to .complicate things. I took another look, and I realized what confused me. Usually Cancel means "do nothing". But, here Geany updates the timestamp. Let's tell about it. Add an information pop-up after Cancel, like: "Be aware! Buffer timestamp is updated." or something similar. As for me it will be sufficient.
Closed #1885.
I reopen this issue. I really was using “cancel+save as“ or, even better, “save as+cancel”. But, why should we use two operations instead of one? In this case “Save as” has exactly the same priority as overwrite and reload. I added "Save As" button in my copy, and you can see the attached screen shot. The message bar doesn't look terrible. I also renamed Cancel button. It is semantics, but I believe "Ignore" is more clear in case of multiple choice. The pull request will follow.
Reopened #1885.
Can we have "Undecided" too?
Yes, as for me, Undecided sounds better. I will use it instead of Ignore.
No, "Undecided" is not a good button label. I suggested it as a way to try to gently imply that I thought the whole thing was getting silly. Sorry that you took it seriously.
Info bars are meant to convey information that is important but not urgent, it does not need immediate resolution. So info bars deliberately do not stop normal operations, unlike dialogs which must be actioned immediately. Thats why the file change notification was moved from a dialog to an info bar. The fact that the file on disk has changed does not need to be actioned immediately, the info bar does not need to be dismissed, editing can continue and the bar remains as a reminder. So info bars should not occupy large amounts of screen space and by that criteria I am afraid the result is in fact "terrible".
The button label "Cancel" is the standard GUI button label for "close and do nothing" so that is what that button should be (in English anyway).
Since info bars do not block the user interface (unlike dialogs) the user is not restricted to just the options the info bar provides. So there is no need to provide copious options on the info bar. As @codebrainz pointed out you still have access to the normal features of the application. For example, in the case of an unexpected file change notification a user could decide to load the changed file into another buffer to look at it, see what changed, and decide what to do. The info bar does not need a "Load file into another buffer" button to allow them to do that.
The info bar should only have "Cancel" and maybe the most common operation available as a convenience.
Well, just one more remark. Currently after the Info bar appears the buffer becomes unmodifiable.So, we can't do anything with the content until we make a decision. Isn't it?
On Tue, Oct 30, 2018 at 5:39 PM elextr notifications@github.com wrote:
No, "Undecided" is not a good button label. I suggested it as a way to try to gently imply that I thought the whole thing was getting silly. Sorry that you took it seriously.
Info bars are meant to convey information that is important but not urgent, it does not need immediate resolution. So info bars deliberately do not stop normal operations, unlike dialogs which must be actioned immediately. Thats why the file change notification was moved from a dialog to an info bar. The fact that the file on disk has changed does not need to be actioned immediately, the info bar does not need to be dismissed, editing can continue and the bar remains as a reminder. So info bars should not occupy large amounts of screen space and by that criteria I am afraid the result is in fact "terrible".
The button label "Cancel" is the standard GUI button label for "close and do nothing" so that is what that button should be (in English anyway).
Since info bars do not block the user interface (unlike dialogs) the user is not restricted to just the options the info bar provides. So there is no need to provide copious options on the info bar. As @codebrainz https://github.com/codebrainz pointed out you still have access to the normal features of the application. For example, in the case of an unexpected file change notification a user could decide to load the changed file into another buffer to look at it, see what changed, and decide what to do. The info bar does not need a "Load file into another buffer" button to allow them to do that.
The info bar should only have "Cancel" and maybe the most common operation available as a convenience.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/1885#issuecomment-434479890, or mute the thread https://github.com/notifications/unsubscribe-auth/Al5v5M8yzmmKBGNlxkUU3aSbklH-PxPuks5uqMcJgaJpZM4UsYx0 .
Just another remark. I took a quick look at gedit. Their info bar has two buttons: "Reload" and "Ignore". The buffer is also unmodifiable. After I press Ignore and tried to save I got another info bar with buttons: "Save anyway" and "Don't save". (That was basically my very first point. But, you explained why gedit and geany behaviors are different ) However, if you found that the result is in fact "terrible", no problem, we definitely can leave everything as is.
On Tue, Oct 30, 2018 at 10:53 PM Yury Dubinsky yury.dubinsky@gmail.com wrote:
Well, just one more remark. Currently after the Info bar appears the buffer becomes unmodifiable.So, we can't do anything with the content until we make a decision. Isn't it?
On Tue, Oct 30, 2018 at 5:39 PM elextr notifications@github.com wrote:
No, "Undecided" is not a good button label. I suggested it as a way to try to gently imply that I thought the whole thing was getting silly. Sorry that you took it seriously.
Info bars are meant to convey information that is important but not urgent, it does not need immediate resolution. So info bars deliberately do not stop normal operations, unlike dialogs which must be actioned immediately. Thats why the file change notification was moved from a dialog to an info bar. The fact that the file on disk has changed does not need to be actioned immediately, the info bar does not need to be dismissed, editing can continue and the bar remains as a reminder. So info bars should not occupy large amounts of screen space and by that criteria I am afraid the result is in fact "terrible".
The button label "Cancel" is the standard GUI button label for "close and do nothing" so that is what that button should be (in English anyway).
Since info bars do not block the user interface (unlike dialogs) the user is not restricted to just the options the info bar provides. So there is no need to provide copious options on the info bar. As @codebrainz https://github.com/codebrainz pointed out you still have access to the normal features of the application. For example, in the case of an unexpected file change notification a user could decide to load the changed file into another buffer to look at it, see what changed, and decide what to do. The info bar does not need a "Load file into another buffer" button to allow them to do that.
The info bar should only have "Cancel" and maybe the most common operation available as a convenience.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/1885#issuecomment-434479890, or mute the thread https://github.com/notifications/unsubscribe-auth/Al5v5M8yzmmKBGNlxkUU3aSbklH-PxPuks5uqMcJgaJpZM4UsYx0 .
Currently after the Info bar appears the buffer becomes unmodifiable.
Hmmm, the cursor still works, but text entry doesn't. Not sure why.
Hmmm, the cursor still works, but text entry doesn't. Not sure why.
The document is locked/read-only when the infobar is shown. IIRC this was discussed quite a bit back when those infobar changes were being developed.
oh, now I see where is the confusion. It is weird, but from the beginning we were talking about different things. You assumed that after timestamp change we were getting a nice info bar, and still we could be working with the content. It would be great! Then it would be really insane even to think about "save as" button or Ignore instead of Cancel. However, I was talking about locked content and confusing Cancel button. So, most probably it is a bug. Just one more fact. When the bar is on and the content is locked, I still can use Save As from the file menu. Then obviously the bar stays the same. But, the buffer becomes "dirty" and the content becomes editable.
On Wed, Oct 31, 2018, 10:33 Matthew Brush <notifications@github.com wrote:
Hmmm, the cursor still works, but text entry doesn't. Not sure why.
The document is locked/read-only when the infobar is shown. IIRC this was discussed quite a bit back when those infobar changes were being developed.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/geany/geany/issues/1885#issuecomment-434710199, or mute the thread https://github.com/notifications/unsubscribe-auth/Al5v5GxiFkUKbMr2pcC76cGcl2tclR4mks5uqbTRgaJpZM4UsYx0 .
@codebrainz yeah, with tabs enabled I can see it goes to readonly colour, I guess its ok if its deliberate. Does point out we should indicate readonly in more than one place, but thats another topic.
@dyura if the document is set readonly then yes the rest of the GUI is still available, just not editing of that file.
I think [this commit](https://github.com/geany/geany/commit/5117940ff6e6457b24e7ee0989d3092ff38bac...) and associated comments is what I was thinking of.
Please, let me understand correctly, what should I expect as an user. I am typing in a file. The file was changed outside the editor, and in the middle of my typing the file becomes red-only. Correct? Is it what I should expect?
Judging by @kugel-'s [previously linked commit message](https://github.com/geany/geany/commit/5117940ff6e6457b24e7ee0989d3092ff38bac...), that sounds correct:
This avoids accidental changes the file until the infobar is ackowledged. The document can still be viewed and scrolled through but modifications and saving are disabled. Of course ignoring the document by changing to another one is also possible.
Closed #1885.
github-comments@lists.geany.org