Annoying detection of missing file
Philippe Lhoste
slightly annoying, and now I find quite buggy/in the way.
If I open a file, then it is removed (by me, by the program having created it as temp
file, etc.), when I activate the buffer (switching applications, trying to restore from
minimized state, etc.), it warns me of the missing file.
This is OK, the information might be useful, and need only a keystroke to dismiss it.
But, I think it should warn only once, with perhaps exposing the state as a status bar
variable (like the read-only state, for example).
Currently I have such file (opened by Filezilla when opening a remote file, deleted by it
because I closed the application) and I can't even restore from minimized because the
dialog box prevents to achieve it (well, I can still use Alt+Tab to restore it, but that's
not the point) nor even close it (the dialog pops up too when right-clicking on the icon
in the task bar!).
I might take time to look how to reduce the annoyance, but if somebody is faster than me
at that (shouldn't be hard, I am busy with other stuff right now), you are welcome! :-)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Neil Hodgson
> If I open a file, then it is removed (by me, by the program having created it as temp
> file, etc.), when I activate the buffer (switching applications, trying to restore from
> minimized state, etc.), it warns me of the missing file.
> This is OK, the information might be useful, and need only a keystroke to dismiss it.
> But, I think it should warn only once, with perhaps exposing the state as a status bar
> variable (like the read-only state, for example).
There was a change recently to use compare the file time and the
buffer time using not equal rather than newer.
The fileModLastAsk field is supposed to avoid asking about the file
multiple times.
Neil
Neil Hodgson
if (newModTime != CurrentBuffer()->fileModTime) {
back to
if (newModTime > CurrentBuffer()->fileModTime) {
Neil
Philippe Lhoste
> Check if this is fixed by reverting line 632 of scite/src/SciTEIO.cxx
Ah, I had no time to work on the issue, but at least I can do the quick test...
If I do this change, I am no longer warned of the disappearance of the file.
Of course, I can alter the file and save it, it restores it.
If the file is changed from somewhere else, SciTE automatically updates the buffer (if not
dirty, of course, and according to my settings).
So with this change, I go back to old behavior, which is already an improvement.
Neil Hodgson
> So with this change, I go back to old behavior, which is already an improvement.
OK, I have reverted the change in CVS. This was done because of the
confusing situation that could arise where you could not easily
restore a window. A better patch would only ever display the message
box once for any external change to the file or deletion.
This was the patch contributed by Andy A. Shevchenko to notice that
a file had been replaced with an older version.
Neil
mozers
> OK, I have reverted the change in CVS.
Andy Shevchenko's patch eliminated real annoying bug SciTE.
Philippe Lhoste's remark is also true.
But why did you remove the hotfix and brought back the old bug?
Enough to correct a little the line 632 from SciTEIO.cxx
if ((newModTime! = 0) && (newModTime! = CurrentBuffer ()-> fileModTime)) {
I - not a programmer. But my patch works well.
--
mozers
<http://scite.net.ru>
Neil Hodgson
> Andy Shevchenko's patch eliminated real annoying bug SciTE.
> Philippe Lhoste's remark is also true.
> But why did you remove the hotfix and brought back the old bug?
Because it bricked SciTE.
> Enough to correct a little the line 632 from SciTEIO.cxx
>
> if ((newModTime! = 0) && (newModTime! = CurrentBuffer ()-> fileModTime)) {
>
> I - not a programmer. But my patch works well.
Worked OK for me so committed.
Neil
mozers
>> if ((newModTime! = 0) && (newModTime! = CurrentBuffer ()-> fileModTime)) {
> Worked OK for me so committed.
OK. But there is another problem.
SciTE does not notice if the file is removed, moved or renamed by other program.
That was before. My patch does not change this behavior.
Attached patch fixes a problem (Author - neo4max)
--
mozers
<http://scite.net.ru>
Neil Hodgson
> OK. But there is another problem.
> SciTE does not notice if the file is removed, moved or renamed by other program.
> That was before. My patch does not change this behavior.
> Attached patch fixes a problem (Author - neo4max)
I do not understand this code or what it is trying to change.
One thing it does is that it sets the dirty flag in a way that does
not match the dirty state of the buffer which causes confusion to both
the user and to the code. For example, when it sets the dirty flag
(and thus the '*' in the title bar) you can perform an action and then
undo it and the '*' has gone. If there is a special file-has-gone-away
state then this should be explicit rather than perverting the meaning
of the dirty flag.
Neil
mozers
> One thing it does is that it sets the dirty flag in a way that does
> not match the dirty state of the buffer which causes confusion to both
> the user and to the code. For example, when it sets the dirty flag
> (and thus the '*' in the title bar) you can perform an action and then
> undo it and the '*' has gone. If there is a special file-has-gone-away
> state then this should be explicit rather than perverting the meaning
> of the dirty flag.
ОК. Please see a new patch (Author - neo4max).
Now creation of the new empty buffer with IDM_OPEN correctly works.
--
mozers
<http://scite.net.ru>
neo_max
> I do not understand this code or what it is trying to change.
>
> One thing it does is that it sets the dirty flag in a way that does
> not match the dirty state of the buffer which causes confusion to both
> the user and to the code. For example, when it sets the dirty flag
> (and thus the '*' in the title bar) you can perform an action and then
> undo it and the '*' has gone. If there is a special file-has-gone-away
> state then this should be explicit rather than perverting the meaning
> of the dirty flag.
version there is a dialog that asks user to keep deleted file open, it
looks like:
void SciTEBase::CheckReload() {
if (!props.GetInt("load.on.activate")) return;
if (filePath.IsUntitled()) return;
if (CurrentBuffer()->fileMovedAsked) CurrentBuffer()->fileMovedAsked
= CurrentBuffer()->isDirty;
if ((!CurrentBuffer()->fileMovedAsked)&&(!filePath.Exists())) {
CurrentBuffer()->fileMovedAsked = true;
CurrentBuffer()->isDirty = true;
SString msg = LocaliseMessage(
"The file '^0' has been deleted, or no longer available. Do
you wish to keep the file open in the editor?",
filePath.AsFileSystem());
int decision = WindowMessageBox(wSciTE, msg, MB_YESNO +
MB_DEFBUTTON1);
if (decision == IDNO) {
Close();
return;
}
CheckMenus();
SetWindowName();
BuffersMenu();
} else
if (filePath.Exists()) { ....
Other editors (UltraEdit, Notepad++, etc), that is used by me, works
by the same algorithm. It means when the file is deleted, editor
automatically sets dirty flag (after "keep file open" dialog), with
all the consequences.
There is one exception: dirty-flag also sets, when the file is changed
by another application and user has cancelled reloading of the file. I
did that for user, who have to know, that the file he editing is
different from the physically saved (by another application) on the
disk at the moment. If it is unnecessary - I can delete it.
Example given by you is also quite correct for other redactors I
mentioned. So, I do not find it as misstake
Neil Hodgson
> Other editors (UltraEdit, Notepad++, etc), that is used by me, works
> by the same algorithm. It means when the file is deleted, editor
> automatically sets dirty flag (after "keep file open" dialog), with
> all the consequences.
> There is one exception: dirty-flag also sets, when the file is changed
> by another application and user has cancelled reloading of the file. I
> did that for user, who have to know, that the file he editing is
> different from the physically saved (by another application) on the
> disk at the moment. If it is unnecessary - I can delete it.
Wouldn't that be better expressed by adding a predicate method
bool DocumentNotSaved() {
return (isDirty || (!IsUntitled() && (fileModTime == 0)));
}
which is used for the '*' and for enabling "Save".
Neil
neo_max
> Wouldn't that be better expressed by adding a predicate method
> bool DocumentNotSaved() {
> return (isDirty || (!IsUntitled() && (fileModTime == 0)));}
> which is used for the '*' and for enabling "Save".
please, where we can use it in our case. I meaning CheckReload()
function.
Neil Hodgson
> Im sure that this function will be usefull. But could you explain,
> please, where we can use it in our case. I meaning CheckReload()
> function.
I'm trying to work out a simpler way of implementing this.
fileMovedAsked is probably not required.
BTW, MB_DEFBUTTON1 is not implemented on GTK+ so should not be used
in SciTEIO.cxx.
Neil
neo_max
> I'm trying to work out a simpler way of implementing this.
> fileMovedAsked is probably not required.
If it is not affect to other parts of the system, I`ll optimize it.
> BTW, MB_DEFBUTTON1 is not implemented on GTK+ so should not be used
> in SciTEIO.cxx.
I`m not completely analize the code of the programm yet.
Neil, thank you for your comments.
Neil Hodgson
> Wouldn't that be better expressed by adding a predicate method
> bool DocumentNotSaved() {
> return (isDirty || (!IsUntitled() && (fileModTime == 0)));
> }
> which is used for the '*' and for enabling "Save".
I tried this change but it makes things a bit inconsistent since it
only notices the disappeared file if load.on.activate is on. I suppose
this is OK since the behaviour within a session will be consistent
unless the user changes load.on.activate. Worse, it only notices
disappearing files for the current tab. It may or may not notice other
tabs as they are selected.
Neil
mozers
> I am dropping treating files no longer on disk similar to changed
> files. Attached is a diff if anyone wants to continue working on this.
Unfortunately neo4max it.
I tested the latest CSV version that includes the patch.
IMHO all the problems solved.
--
mozers
<http://scite.net.ru>
mozers
> I tested the latest CSV version that includes the patch.
> IMHO all the problems solved.
Excuse me, I hastened to reply.
The problem is not fixed.
--
mozers
<http://scite.net.ru>