-
-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Add Reload
command
#1099
Comments
If the document on disk has changed and you don't have changes it'll automatically reload the content. IOW, it reloads silently, unless you have pending changes in which cases it does nothing - until you save. If you want to reload and you think there are changes on disk, just save - you'll be prompted to use theirs or yours or compare and merge. Checking behavior in VS Code I see similar behavior - if changes occur if the document has been changed on disk it'll notify you on save by asking to compare and overwrite which is similar to what MM does (except you get more choices). |
In the meantime I realized that So my request boils down to make
In my environment this works fine with some externals programs, especially with my favorite source code editor. However, it does not work with some others, especially not with my favorite compare and merge tool.
MM has this feature for quite some time, as far as I remember, but until recently the
|
Hmmm... I can duplicate teh issue with 'Use Theirs' although a brief look at the code makes me wonder why that is. Use Theirs should just reload the document from disk even if there are changes and that's what the code is doing. I'll have to check... As to Compare - you can configure your Diff tool. i use BeyondCompare: executable has to be able to accept two filenames for parameters (which any diff tool should support). MM also hunts for a few diff tools by default on your system if they are installed in their default locations. |
Ok I fixed the issue with the 'Use Theirs` not reloading. Also modified the Context Menu to add the Reload from disk option and now display a less busy context menu if the Window is small. If window.height > 1100 then continue to show the old full menu. All the hidden options are available on the Tab context menu but the editor menu is just too big if there's not a lot of screen real estate. |
#1 - not adding a Reload button to the file menu. It's enough of an edge case as is. as to menu spacing. The horrible practice is to have menus with a million things on it 😄 #2 - You can't be serious. The files are different and the external file most likely has changed. The dialog lets you know that the files are different since the last time MM loaded or saved. There are scenarios where you might have saved and the external file update occurs but doesn't notify for various reasons. You might have a change and undo it (now unchanged again, but you the external file was saved in the meantime). Again these are all edge cases at best and being extra careful to avoid overwriting is more important than a little bit of potential convenience that may result in overwritten data. This logic for this is complex enough with all the scenarios and the fact that notifications are sometimes lost by Windows so you may end up without a notification when you should get some so being sure that the files you are saving are different between the last CRC check is the safe route. |
As to the odd crash - I was able to duplicate that once, but not since. Not quite sure what could be happening there other than the tool keeping the file open and in some weird state. What's odd is that the WebView is failing - I would expect that to fail when the file is loaded, unless the file result is null perhaps, but that is being checked for. What tool do you use? (I use BeyondCompare here) |
I understand your reluctance to devote more time to what seems like a minor issue. If that's the case, simply acknowledging it would suffice. However, it seems you're mixing up different aspects in your argument, when the situation is actually quite straightforward:
Your logic eludes me. When a user triggers |
I also use BeyondCompare. |
#1 - LOL! Done with this one... we can quibble over semantics but at the end of the day that's my call. If you want to keep this up start a new Issue please. #2 - I don't follow your scenario. It's really hard to have a scenario where you have to reload in the first place - any external changes are immediately propagated into the document if there are no changes. It's hard for me to even set up a repro case because as soon as I change the file it updates in MM. That's my point. There should very rarely be a reason to reload because the document is automatically updated (unless the update events are not firing which is very rare but does happen). if one does get by and doesn't update the document. You are conflating different operations. Reload only shows a dialog that reminds you that you have changes and gives you a chance to abort. Save gives you the compare dialog... |
Just to be clear so that we're talking about the same thing: For both scenarios I use VS Code with the same file open as in MM 1) Reload with changes in MM
This is correct behavior. 2) Reload with out Changes in MMThis scenario very hard to even simulate because if I don't have changes in MM the document automatically updates when I save changes in VS Code. I have to fake it by typing into MM (dirty doc), saving in VS Code, then undoing the changes in MM. Now I have a dirty doc on disk and clean doc in MM.
This is also what I expect. Note If the document is really unchanged the green Save button in the toolbar should be disabled. If it's not then the doc has some change (whitespace or encoding or a previous document update from a change. 3) Save Without Changes
4) Save With Changes File has not changed
5) Save with Changes and File has changed externally
|
FWIW - I took a look at the menu styling and removed a little of the padding to save some space. Nothing as drastic as the crammed LibreOffice menu but it still is more compact. Thanks for the inspiration... |
Firstly I would like to restate the fact which triggered this thread: MM does not detect external changes reliably, unlike other editors such as Visual Studio, VS Code or Notepad++. Often, this misbehavior requires manually reloading the current document. Such a situation can reproduced easily with Beyond Compare as follows:
All editors except MM almost always (presumably >99.9%) detect the change immediately, at least on my computer. However, this is another issue. I have repeated all your tests and more for BTW: Do you have an infrastructure for automated GUI tests? Test Cases for
|
Case | Internal change unsaved |
External change on disk |
Passed | Remarks |
---|---|---|---|---|
1 | no | no | yes | needless operation but harmless |
2 | no | yes | yes | supposed to happen automatically |
3 | yes | no | yes | shows dialog "Refresh Document" |
4 | yes | yes | yes? | shows dialog "Refresh Document" |
You wrote that case 2 is very hard to even simulate. It can be reproduced with Beyond Compare as mentioned above.
Sorry, I reported case 2 wrongly in the preceding post.
Unfortunately, I conflated Reload
case 2 with Save
case 2, which was the one I actually wanted to restate. See also next section.
In case 4 the dialog "Document Save: File Conflicts" instead of dialog "Refresh Document" may be a preferable option.
Now the user has to cancel the Reload
command and then apply the Save
command in order to preserve both internal and external changes.
Test Cases for Save
(Ctrl+S
)
Case | Internal change unsaved |
External change on disk |
Passed | Remarks |
---|---|---|---|---|
1 | no | no | yes? | only with Ctrl+S : needless operation; changes Modified timestamp |
2 | no | yes | yes?? | only with Ctrl+S : shows dialog "Document Save: File Conflicts" |
3 | yes | no | yes | normal case |
4 | yes | yes | yes | shows dialog "Document Save: File Conflicts" |
Again, case 2 can be reproduced with Beyond Compare as mentioned above.
Actually Ctrl+S
should be disabled in cases 1 and 2.
However, if Ctrl+S
is not disabled then it should behave like Reload
in case 2.
Ctrl+S
always saves the current file to disk, regardless whether the save button is enabled (green) or not.
In my opinion this is a bad behavior. The Modified
timestamp of a file should never be changed needlessly.
Some apps respect this convention (for example Word and Notepad++).
MM is ambivalent. The Save
command in the File
menu and the corresponding
button respect it, but Ctrl+S
does not.
Hmmm... so this is interesting. I can corroborate what you're seeing with BeyondCompare. However, if I use VS Code to make changes to the document and save I see the change immediately. It looks like for some reason the save operation in BeyondCompare is not triggering the file change event the same way as the save in VS Code or Notepad does (using the Windows FileWatcher). I think that may be part of the reason we see many of the issues you're describing. However, if I then save the file change is detected and I get the dialog that prompts me to choose Mine or Theirs which is as expected given that the file was not updated in the editor. As to Ctrl-S always saving even if there are no changes - given that there may always be situations where the document may get out of sync with what's on disk I believe the safe thing to do is save when asked. The above example exemplifies that very issue - there may be a change that has occurred on disk, but you don't know about it but yet you still want to save your current work even though nothing has changed. I think the simple solution to that problem is, if you don't want the file date to change, don't save. |
I suggest comparing MM's code for the detection of external file changes very closely with the code in VS Code or Notepad++ (both open source). Probably the other editors do it differently.
Your logic is elusive to me. Halfway through, MM has already adopted the approach used by Word and Notepad++. For consistency, just ignore |
Visual Studio Code behaves exactly the same as MM does. That is the model I'm using. As to Ctrl-S always saving even if there are no changes - given that there may always be situations where the document may get out of sync with what's on disk I believe the safe thing to do is save when asked. The above example exemplifies that very issue - there may be a change that has occurred on disk, but you don't know about it but yet you still want to save your current work even though nothing has changed. I think the simple solution to that problem is, if you don't want the file date to change, don't save. We've been through this. If you save and there are changes in the file you'll get the Use Yours/theirs/compare dialog so you get to make a decision what you want to do. This is the safe thing to do, and... let's be honest that should be an increasingly rare situation. There's nothing wrong with the save operation itself and there won't be any changes to that. What has a potential issue is that some disk changes are not being detected or are not updating the document with the changes, when the document is unchanged, and I'm looking into that. Specifically the issue with Beyond Compare which I suspect is writing out the updated file with missing some flag that I'm (or the FileWatcher) looking for modified state detection. |
Alright there's some progress on the Beyond Compare issue which was caused by two things:
But there are other issues related to managing the compare and passing the results back into MM. Started a new issue #1100 |
MM often does not detect changes to files of open documents by external apps upon regaining focus.
Therefore I suggest to add a
Reload
command as it exists in many other editors, allowing users to manually refresh the current document.If the document has been modified with MM then the
Reload
command should prompt the user with a warning that any unsaved changes will be lost, similarly to theClose
command.The text was updated successfully, but these errors were encountered: