Hello
I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed.
I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning.
This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...).
I'm asking for restoring the prompt (by default), at the very least if the file is unsaved.
Best regards
Le 24/06/2015 17:04, Thomas Martitz a écrit :
Hello
I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed.
I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning.
This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...).
How does it loose work? you can undo the reload and you get your stuff back, don't you?
I'm asking for restoring the prompt (by default), at the very least if the file is unsaved.
Would be fine with me, as I don't think reload is something done so often that a confirmation would be much pain. We could restore the previous confirmation behavior.
"offending" commit is https://github.com/geany/geany/commit/660c441b4af272fe4e40eb6a6cda2badb8f17e... I guess.
Regards, Colomban
Am 24.06.2015 um 18:30 schrieb Colomban Wendling:
Le 24/06/2015 17:04, Thomas Martitz a écrit :
Hello
I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed.
I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning.
This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...).
How does it loose work? you can undo the reload and you get your stuff back, don't you?
Ah yes, that seems to work. I didn't even think of that (not sure why, but redo would seem more natural to me here). Anyway the new default behavior seems awkward to, surprising and unexpected in some way.
I haven't looked at the code. Is the diff of the buffer and the file applied and recorded as an ordinary undo action?
I'm asking for restoring the prompt (by default), at the very least if the file is unsaved.
Would be fine with me, as I don't think reload is something done so often that a confirmation would be much pain. We could restore the previous confirmation behavior.
"offending" commit is https://github.com/geany/geany/commit/660c441b4af272fe4e40eb6a6cda2badb8f17e... I guess.
Okay, with the "undo the reload" it's not as bad as I thought. However I still find the new default behavior confusing, especially for regular long time users like me.
However, just restoring the prompt is also not ideal. Since the undo history is now remembered the prompt would be wrong (either way, for unsaved buffer it says "Any unsaved changes will be lost." and for saved buffer "Undo history will be lost.").
I think one could improve the prompt depending on the pref. I think it would best to even incooperate a check box for the pref (like "[ ] Remember undo history" and "[ ] don't ask again" [the latter being insensitive if the first is unchecked]). How does that sound?
Best regards.
On 25 June 2015 at 04:54, Thomas Martitz kugel@rockbox.org wrote:
Am 24.06.2015 um 18:30 schrieb Colomban Wendling:
Le 24/06/2015 17:04, Thomas Martitz a écrit :
Hello
I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed.
If the user asked to reload, why should they then have to ask again?
I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning.
Its just undoable like any other change.
This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...).
How does it loose work? you can undo the reload and you get your stuff back, don't you?
Ah yes, that seems to work. I didn't even think of that (not sure why, but redo would seem more natural to me here). Anyway the new default behavior seems awkward to, surprising and unexpected in some way.
I'm struggling to understand why there is any confusion, reload is an editing action just like any other and can be undone like any other. Seems much safer to me and exactly what to expect. It used to have a side effect that was unexpected and nasty which was why it had a dialog warning of that, now it doesn't, so its just like any other command.
I haven't looked at the code. Is the diff of the buffer and the file applied and recorded as an ordinary undo action?
Thats up to Scintilla how it records the reload.
I'm asking for restoring the prompt (by default), at the very least if the file is unsaved.
Would be fine with me, as I don't think reload is something done so often that a confirmation would be much pain. We could restore the previous confirmation behavior.
Doesn't make sense, should we prompt on every delete action "You are about to delete some characters (maybe even all of them), are you sure?"?
"offending" commit is
https://github.com/geany/geany/commit/660c441b4af272fe4e40eb6a6cda2badb8f17e... I guess.
Okay, with the "undo the reload" it's not as bad as I thought. However I still find the new default behavior confusing, especially for regular long time users like me.
Indeed long time users who are used to the old wrong behaviour need to unlearn the wrong one. But that doesn't mean we should prompt every time we do it right.
However, just restoring the prompt is also not ideal. Since the undo history is now remembered the prompt would be wrong (either way, for unsaved buffer it says "Any unsaved changes will be lost." and for saved buffer "Undo history will be lost.").
I think one could improve the prompt depending on the pref. I think it would best to even incooperate a check box for the pref (like "[ ] Remember undo history" and "[ ] don't ask again" [the latter being insensitive if the first is unchecked]). How does that sound?
Like overkill.
I'm more bemused by the suggestions than strongly anti them, really seems like wiping the users bottoms for them.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 24.06.2015 um 22:26 schrieb Lex Trotman:
I'm struggling to understand why there is any confusion, reload is an editing action just like any other and can be undone like any other. Seems much safer to me and exactly what to expect. It used to have a side effect that was unexpected and nasty which was why it had a dialog warning of that, now it doesn't, so its just like any other command.
To me, reloading the file from disk is clearly not like any other editing command. It's got more to do with file management than editing, and given the previous behavior it's easy to be confused as an existing user. I also don't think any other editor out there works like this so I can see it being unexpected for new users as well.
I haven't looked at the code. Is the diff of the buffer and the file applied and recorded as an ordinary undo action?
Thats up to Scintilla how it records the reload.
I was wondering if we do anything special to support this. I guess not.
Indeed long time users who are used to the old wrong behaviour need to unlearn the wrong one. But that doesn't mean we should prompt every time we do it right.
Some kind of help/guidance for users who do not expect the new behavior (either because are existing users or coming from other editors[1]) would be nice, if possible. And since it seems really unique across editors (and consequently potentially unexpected) some kind of introduction to the feature would be really helpful. I, for one, got really trapped. I'd say the dialog I proposed can accomplish that, while maintaining the ability to never have the prompt again.
[1]: gedit does it similarly to what we previously did.
Best regards.
On 25 June 2015 at 06:54, Thomas Martitz kugel@rockbox.org wrote:
Am 24.06.2015 um 22:26 schrieb Lex Trotman:
I'm struggling to understand why there is any confusion, reload is an editing action just like any other and can be undone like any other. Seems much safer to me and exactly what to expect. It used to have a side effect that was unexpected and nasty which was why it had a dialog warning of that, now it doesn't, so its just like any other command.
To me, reloading the file from disk is clearly not like any other editing command. It's got more to do with file management than editing, and given the previous behavior it's easy to be confused as an existing user. I also don't think any other editor out there works like this so I can see it being unexpected for new users as well.
Welcome to a new paradigm :)
I haven't looked at the code. Is the diff of the buffer and the file applied and recorded as an ordinary undo action?
Thats up to Scintilla how it records the reload.
I was wondering if we do anything special to support this. I guess not.
Indeed long time users who are used to the old wrong behaviour need to unlearn the wrong one. But that doesn't mean we should prompt every time we do it right.
Some kind of help/guidance for users who do not expect the new behavior (either because are existing users or coming from other editors[1]) would be nice, if possible. And since it seems really unique across editors (and
Most [1] other editors call this command "revert" and they clear the edit history, that makes sense, they are "reverting" the buffer to its initial state. So they have prompts.
Geany is just reloading the file contents as another editing action.
consequently potentially unexpected) some kind of introduction to the feature would be really helpful. I, for one, got really trapped. I'd say the dialog I proposed can accomplish that, while maintaining the ability to never have the prompt again.
Since Geany is clearly ahead of the pack here maybe we *should* have a a dialog:
Did you know that reloading is just another editing action and can be undone like all the rest?
It is not like other editors crappy destructive "revert" commands.
[ ] Don't show again
This advertisement is brought to you by the Geany team to emphasise its awesomeness.
:)
Cheers Lex
[1]: gedit does it similarly to what we previously did.
[1]: "Most" on my system consists of gedit and emacs, but I had a quick look at the doco for a few others.
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2015-06-24 02:30 PM, Lex Trotman wrote:
On 25 June 2015 at 06:54, Thomas Martitz kugel@rockbox.org wrote:
Am 24.06.2015 um 22:26 schrieb Lex Trotman:
I'm struggling to understand why there is any confusion, reload is an editing action just like any other and can be undone like any other. Seems much safer to me and exactly what to expect. It used to have a side effect that was unexpected and nasty which was why it had a dialog warning of that, now it doesn't, so its just like any other command.
To me, reloading the file from disk is clearly not like any other editing command. It's got more to do with file management than editing, and given the previous behavior it's easy to be confused as an existing user. I also don't think any other editor out there works like this so I can see it being unexpected for new users as well.
Welcome to a new paradigm :)
I haven't looked at the code. Is the diff of the buffer and the file applied and recorded as an ordinary undo action?
Thats up to Scintilla how it records the reload.
I was wondering if we do anything special to support this. I guess not.
Indeed long time users who are used to the old wrong behaviour need to unlearn the wrong one. But that doesn't mean we should prompt every time we do it right.
Some kind of help/guidance for users who do not expect the new behavior (either because are existing users or coming from other editors[1]) would be nice, if possible. And since it seems really unique across editors (and
Most [1] other editors call this command "revert" and they clear the edit history, that makes sense, they are "reverting" the buffer to its initial state. So they have prompts.
Geany is just reloading the file contents as another editing action.
consequently potentially unexpected) some kind of introduction to the feature would be really helpful. I, for one, got really trapped. I'd say the dialog I proposed can accomplish that, while maintaining the ability to never have the prompt again.
Since Geany is clearly ahead of the pack here maybe we *should* have a a dialog:
Did you know that reloading is just another editing action and can be undone like all the rest?
...even though it's going out to disk like all file actions and unlike other editing action, and is also found under the File menu and not the Edit menu... :)
It is not like other editors crappy destructive "revert" commands.
...even though it used to be ...
[ ] Don't show again
This advertisement is brought to you by the Geany team to emphasise its awesomeness.
And memory manufacturers everywhere :)
Sarcasm aside, I think it's a fine feature, maybe slightly confusing since the existing behaviour changed, and isn't similar to most editors. Other than that, clearing the visible "dirty" state and using sizeof(doc)*n_reloads of memory in Scintilla undo buffer, it's not a bad idea. It's convenient and seemingly safe.
I wonder if there's a more simple way to reduce confusion and increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Cheers, Matthew Brush
Hello,
I hacked up a document message to inform the user about this new behavior, see attached screenshot.
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point? What else can we do for *this* release?
Best regards
Am 26.06.2015 um 07:22 schrieb Thomas Martitz:
Hello,
I hacked up a document message to inform the user about this new behavior, see attached screenshot.
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point? What else can we do for *this* release?
Bump. IMO this should be resolved for 1.25. Should I do a PR regardless of the string freeze?
Best regards.
Le 26/06/2015 07:22, Thomas Martitz a écrit :
[…]
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point?
It would be really better not to indeed?
What else can we do for *this* release?
Hum. If this is an important enough issue, I can see these solutions:
- Default to not keep history (hence prompt);
- Add an extra hidden setting "don't show this message again"-like for a *future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting.
Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle.
Colomban
On 29 June 2015 at 07:41, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 26/06/2015 07:22, Thomas Martitz a écrit :
[…]
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point?
It would be really better not to indeed?
What else can we do for *this* release?
Hum. If this is an important enough issue, I can see these solutions:
Default to not keep history (hence prompt);
Add an extra hidden setting "don't show this message again"-like for a
*future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting.
Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle.
Or just put a BIG notice in the release notes "Reload is now undoable so it doesn't prompt any more"
Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 29.06.2015 um 00:32 schrieb Lex Trotman:
On 29 June 2015 at 07:41, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 26/06/2015 07:22, Thomas Martitz a écrit :
[…]
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point?
It would be really better not to indeed?
What else can we do for *this* release?
Hum. If this is an important enough issue, I can see these solutions:
Default to not keep history (hence prompt);
Add an extra hidden setting "don't show this message again"-like for a
*future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting.
Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle.
Or just put a BIG notice in the release notes "Reload is now undoable so it doesn't prompt any more"
That helps only existing users, and only that fraction that actually reads release notes (I would think the bulk of them doesn't).
Perhaps it would be indeed best to not toggle the default for this release already?
PS: I do love this feature now that I'm aware of the undo'ability, it's not like I want to act against it. I just fear it creates user confusion for both new and existing users alike.
Best regards
On 29 June 2015 at 18:24, Thomas Martitz kugel@rockbox.org wrote:
Am 29.06.2015 um 00:32 schrieb Lex Trotman:
On 29 June 2015 at 07:41, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 26/06/2015 07:22, Thomas Martitz a écrit :
[…]
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point?
It would be really better not to indeed?
What else can we do for *this* release?
Hum. If this is an important enough issue, I can see these solutions:
Default to not keep history (hence prompt);
Add an extra hidden setting "don't show this message again"-like for a
*future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting.
Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle.
Or just put a BIG notice in the release notes "Reload is now undoable so it doesn't prompt any more"
That helps only existing users, and only that fraction that actually reads release notes (I would think the bulk of them doesn't).
Well, yes, thats true, but it is something that can be done anyway, since it has no impact on code or strings or anything else :)
Perhaps it would be indeed best to not toggle the default for this release already?
PS: I do love this feature now that I'm aware of the undo'ability, it's not like I want to act against it. I just fear it creates user confusion for both new and existing users alike.
Certainly it gave you a fright, and its admirable that you try to save others from it, but personally I think you are too worried.
Cheers Lex
Best regards
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2015-06-29 02:24 AM, Lex Trotman wrote:
On 29 June 2015 at 18:24, Thomas Martitz kugel@rockbox.org wrote:
Am 29.06.2015 um 00:32 schrieb Lex Trotman:
On 29 June 2015 at 07:41, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 26/06/2015 07:22, Thomas Martitz a écrit :
[…]
However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point?
It would be really better not to indeed?
What else can we do for *this* release?
Hum. If this is an important enough issue, I can see these solutions:
Default to not keep history (hence prompt);
Add an extra hidden setting "don't show this message again"-like for a
*future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting.
Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle.
Or just put a BIG notice in the release notes "Reload is now undoable so it doesn't prompt any more"
That helps only existing users, and only that fraction that actually reads release notes (I would think the bulk of them doesn't).
Well, yes, thats true, but it is something that can be done anyway, since it has no impact on code or strings or anything else :)
Perhaps it would be indeed best to not toggle the default for this release already?
PS: I do love this feature now that I'm aware of the undo'ability, it's not like I want to act against it. I just fear it creates user confusion for both new and existing users alike.
Certainly it gave you a fright, and its admirable that you try to save others from it, but personally I think you are too worried.
Not only it gave him fright, it lost him work because the change in behaviour is not common/obvious and lacks the visual queues needed to make one realize what has happened.
Cheers, Matthew Brush
Le 29/06/2015 10:24, Thomas Martitz a écrit :
[…]
That helps only existing users, and only that fraction that actually reads release notes (I would think the bulk of them doesn't).
Perhaps it would be indeed best to not toggle the default for this release already?
Makes sense to me, and in the next cycle we add some appropriate feedback so the user can discover the feature.
On 2015-06-24 09:30 AM, Colomban Wendling wrote:
Le 24/06/2015 17:04, Thomas Martitz a écrit :
Hello
I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed.
I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning.
This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...).
How does it loose work? you can undo the reload and you get your stuff back, don't you?
It's not super obvious you can undo because it seems like the document's "dirty" state is cleared, so the tab label isn't red, etc. I didn't realize this feature, even though I vaguely remember when it was committed. It seems fine, but I wouldn't have realized I could just undo. I usually associate file-related actions to clearing the undo buffer, but it might just be what I'm used to.
I'm asking for restoring the prompt (by default), at the very least if the file is unsaved.
Would be fine with me, as I don't think reload is something done so often that a confirmation would be much pain. We could restore the previous confirmation behavior.
I reload a lot :)
I think the only weird behaviour besides the clearing the "dirty" state, is that if you are editing a file, then edit it externally, then come back to Geany, it rightly warns you using a nice document message, giving the choice to reload, overwrite or do nothing. If you press the toolbar reload button, it dismisses the document infobar. That's not in itself necessarily a bad thing, because you're basically saying "yes, i want to reload, go away". However, if you clicked the toolbar save button instead of reload, it asks Yet Again, this time with a modal dialog, what the document infobar is already asking, to save/overwrite the file. It's kind of subtle but seems a bit inconsistent, IMO.
Cheers, Matthew Brush
[...]
I think the only weird behaviour besides the clearing the "dirty" state, is that if you are editing a file, then edit it externally, then come back to Geany, it rightly warns you using a nice document message, giving the choice to reload, overwrite or do nothing. If you press the toolbar reload button, it dismisses the document infobar. That's not in itself necessarily a bad thing, because you're basically saying "yes, i want to reload, go away". However, if you clicked the toolbar save button instead of reload, it asks Yet Again, this time with a modal dialog, what the document infobar is already asking, to save/overwrite the file. It's kind of subtle but seems a bit inconsistent, IMO.
Yes, the rest of Geany probably hasn't caught up with the existence of the infobars, so there are likely to be more "funny" interactions elsewhere. Probably worth an issue.
[...]
And memory manufacturers everywhere :)
Shh :)
Sarcasm aside, I think it's a fine feature, maybe slightly confusing since the existing behaviour changed, and isn't similar to most editors. Other than that, clearing the visible "dirty" state and using sizeof(doc)*n_reloads of memory in Scintilla undo buffer, it's not a bad idea. It's convenient and seemingly safe.
Sarcasm? Moi? But yeah, when Thomas pointed out its actually different semantics from most editors I agree it might be worthwhile mentioning it.
I wonder if there's a more simple way to reduce confusion and increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Menu, what menu? I use the toolbar button. Changing the name won't help here.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2015-06-24 05:47 PM, Lex Trotman wrote:
[...]
I wonder if there's a more simple way to reduce confusion and increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Menu, what menu? I use the toolbar button. Changing the name won't help here.
Then maybe just having it keep the tab label red and asterisk in the window title is enough. I think those would've been enough of a clue for me to figure out I could undo.
Cheers, Matthew Brush
On 25 June 2015 at 10:51, Matthew Brush mbrush@codebrainz.ca wrote:
On 2015-06-24 05:47 PM, Lex Trotman wrote:
[...]
I wonder if there's a more simple way to reduce confusion and increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Menu, what menu? I use the toolbar button. Changing the name won't help here.
Then maybe just having it keep the tab label red and asterisk in the window title is enough. I think those would've been enough of a clue for me to figure out I could undo.
Hmmmm, I didn't notice before that the changed indication went away.
Interesting question, if the buffer has the same content as the file (and we know that because we just reloaded it) but it has an undo history, is it changed or not? I dunno.
Also I missed your previous suggestion to move reload to the edit menu, agree with that, though I am not sure about changing the name.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 25. Juni 2015 02:51:43 MESZ, schrieb Matthew Brush mbrush@codebrainz.ca:
On 2015-06-24 05:47 PM, Lex Trotman wrote:
[...]
I wonder if there's a more simple way to reduce confusion and
increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Menu, what menu? I use the toolbar button. Changing the name won't
help here.
Then maybe just having it keep the tab label red and asterisk in the window title is enough. I think those would've been enough of a clue for me to figure out I could undo.
The red indicates that the buffer is changed and unsaved, in other words the buffer is not the same as the file on disk. So clearing it on reload is the right thing.
After saving, you the indication is also cleared *and* you can undo. That's been fine since forever.
I think a document message would be a fine way to transport this feature.
"The file has been reloaded. You can revert the buffer to the previous state simply by undoing. This message will not be displayed again.
This feature can be disabled by clicking "Always clear undo".
[ Okay ] [ Always clear undo ] "
Best regards
On 25 June 2015 at 15:19, Thomas Martitz kugel@rockbox.org wrote:
Am 25. Juni 2015 02:51:43 MESZ, schrieb Matthew Brush mbrush@codebrainz.ca:
On 2015-06-24 05:47 PM, Lex Trotman wrote:
[...]
I wonder if there's a more simple way to reduce confusion and
increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu?
Menu, what menu? I use the toolbar button. Changing the name won't
help here.
Then maybe just having it keep the tab label red and asterisk in the window title is enough. I think those would've been enough of a clue for me to figure out I could undo.
The red indicates that the buffer is changed and unsaved, in other words the buffer is not the same as the file on disk. So clearing it on reload is the right thing.
Well, thinking about it some more red doesn't really indicate anything about the buffer matching the file, just add a character and delete it, the buffer is the same as the disk, but it stays red.
What it indicates is that there have been edit actions since the last file to buffer sync (save or reload).
After saving, you the indication is also cleared *and* you can undo. That's been fine since forever.
Yes, having determined what red actually means, this makes sense and having reload do it too is fine.
I think a document message would be a fine way to transport this feature.
"The file has been reloaded. You can revert the buffer to the previous state simply by undoing. This message will not be displayed again.
This feature can be disabled by clicking "Always clear undo".
I assume this sets a setting that can be edited elsewhere, since only allowing one shot at making such a decision is bad ("This message will not be displayed again"), in which case its probably good to reference that setting, whatever its going to be.
I still feel its overkill, but so long as its unobtrusive and doesn't appear again I'm ok with it.
[ Okay ] [ Always clear undo ] "
Best regards
Somewhat OT, red is not the best choice for this since about 10% of males have red colour vision deficiency, and most Geany users are probably males.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 25.06.2015 um 07:54 schrieb Lex Trotman:
The red indicates that the buffer is changed and unsaved, in other words the buffer is not the same as the file on disk. So clearing it on reload is the right thing.
Well, thinking about it some more red doesn't really indicate anything about the buffer matching the file, just add a character and delete it, the buffer is the same as the disk, but it stays red.
What it indicates is that there have been edit actions since the last file to buffer sync (save or reload).
After saving, you the indication is also cleared *and* you can undo. That's been fine since forever.
Yes, having determined what red actually means, this makes sense and having reload do it too is fine.
Right, makes some sense too.
However, what to do in this case: the file is saved (clearing the red) and immediately reloaded? Make it red again or keep it clear?
I think a document message would be a fine way to transport this feature.
"The file has been reloaded. You can revert the buffer to the previous state simply by undoing. This message will not be displayed again.
This feature can be disabled by clicking "Always clear undo".
I assume this sets a setting that can be edited elsewhere, since only allowing one shot at making such a decision is bad ("This message will not be displayed again"), in which case its probably good to reference that setting, whatever its going to be.
There is a various pref for the "keep edit history on reload" as of git master (on by default). "Always clear undo" would set this to off.
I still feel its overkill, but so long as its unobtrusive and doesn't appear again I'm ok with it.
[ Okay ] [ Always clear undo ] "
Best regards
Somewhat OT, red is not the best choice for this since about 10% of males have red colour vision deficiency, and most Geany users are probably males.
Too bad for those 10%, but red is universal for "be careful here" / "something needs your attention", like traffic lights.
I think the color can be changed though gtkrc/css, too.
Best regards.
[...]
Right, makes some sense too.
However, what to do in this case: the file is saved (clearing the red) and immediately reloaded? Make it red again or keep it clear?
Well reload syncs file and buffer, so its cleared again. Seems right.
[...]
There is a various pref for the "keep edit history on reload" as of git master (on by default). "Always clear undo" would set this to off.
Ok, maybe it should refer to this pref instead of using different terminology, "keep edit history on unload" and "always clear undo" are not immediately obvious as equivalent things.
[...]
Too bad for those 10%,
What a nice response :(
but red is universal for "be careful here" / "something needs your attention", like traffic lights.
But traffic lights have an alternative indication, the position of the light.
I think the color can be changed though gtkrc/css, too.
Not in the manual so it doesn't exist.
Raised #531 for that, won't hijack this discussion further.
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 25.06.2015 um 08:17 schrieb Lex Trotman:
[...]
Right, makes some sense too.
However, what to do in this case: the file is saved (clearing the red) and immediately reloaded? Make it red again or keep it clear?
Well reload syncs file and buffer, so its cleared again. Seems right.
Sorry, I misread your previous mail (read it as "reload should make it red") since you earlier referred to reload as edit action .
Best regards
