bugGNU Octave - Bugs: bug #50106, [GUI] Editor keeps track of files...

 
 

bug #50106: [GUI] Editor keeps track of files even when it is closed

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 20 Jan 2017 08:41:03 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * 4.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 21 Feb 2017 09:15:31 PM UTC, comment #13: 

The latest patch (preference) works fine.
Thank you very much for adding this pref, Torsten!

Closing report.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 19 Feb 2017 12:02:00 PM UTC, comment #12: 

Thanks Torsten,
I'll have a look.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 19 Feb 2017 11:26:13 AM UTC, comment #11: 

Changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/75515a7b1b4b
provides a user preference for closing files when the editor widget is closed.

Torsten Lilge <ttl>
Group Member
Sat 11 Feb 2017 02:01:52 PM UTC, comment #10: 

Philip, of course unhiding the editor in case of changed files would only happen if the behavior for closing the editor is "keep files open".

What exactly is the other issue you mentioned with the editor refusing to save a file if the syntax is not correct?

Torsten Lilge <ttl>
Group Member
Sat 11 Feb 2017 12:29:34 PM UTC, comment #9: 

@Torsten:
Your first user preference suggestion in comment #7 looks like a good idea; it at least gives users a choice to make Octave behave Matlab-compatible  (I'm no ML-compatibility fan beyond pure code compatibility but in this case Matlab behaves as -IMO- an unwary user would expect)

Your second suggestion makes sense to me, but only if the first preference you suggest has been set to "keep files open".

The pref for silently reloading externally changed files merely leads to more confusion, I think. At least, I do not like things happening behind my back.


@Dan: A few observations.

Indeed some confusion comes from the Close button that doesn't close but merely hides a pane. On Matlab it closes the pane (that's also what the popup says when hovering over it with the mouse cursor).
More of the confusion can partly be attributed to some sort of ambiguity between "hidden" and "minimized" editor panes, partly depending on whether they are docked or not.

In Matlab closing the editor disconnects the open files. Similarly, closing its Variable Editor also closes the display of those variables - restoring it doesn't "re-open" variables.

Unlike Octave, Matlab's layout prefs (to be compared to Octave's Window drop down list) doesn't have a "show editor" setting like there is for workspace etc.

Another thing is that Octave doesn't seem to open files "exclusively" like e.g., word processors do. This whole bug report wouldn't be there if Octave would lock its open editor files as well (or should that be a user pref?) - of course, leaving opening files "read-only" if they were in use/locked by other processes.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 11 Feb 2017 09:39:50 AM UTC, comment #8: 

I don't think that a setting for changing the behavior of the x of a tab window is a good idea.  To me, that seems more confusing than present behavior.  The drop-down menu Window is pretty consistent in the sense that every pane can be in a "show" or "not show" state.  What would one propose to put in place of "show editor" for the new behavior?  "Show editor" no longer makes sense if the x pane button means "close all files".  Something like:

v Unclose editor files

There is a little checkbox for individual tabs to close the associated file and remove the tab (and a tooltip to go along with it).  That's pretty clear.  The consistency of meaning of the two upper right buttons (the pane icon and the x button) should become second nature after not too long of use.

One thing that could be done is to remove any x from the window panes that is not associated with closing the application.  One would then have to use "Window" drop down menu exclusively.  Not as convenient, but it avoids confusion about what an x might mean.  Note that currently when a pane is undocked, there are two 'x' buttons near one another with the same meaning, which is sort of inefficiently using valuable screen space.

Still, I don't find the current behavior very confusing once one realizes the consistency of behavior of the 'x' and window-pane icon across all panes.

Dan Sebald <sebald>
Sat 11 Feb 2017 07:56:01 AM UTC, comment #7: 

Well, 2:1 ist no that convincing. What about a user setting whether to keep file open or close all files when closing/hiding the editor widget?

In case of an open file that is externally deleted, there is also a message box popping up, even when the editor is closed. I am going to push a changeset that also unhides the editor with focus on the related tab when those message boxes appear in order to clarify their cause and remember the user that there are still open editor files.

If files are externally changed on a regular basis, there is an editor setting for silently reloading them.




Torsten Lilge <ttl>
Group Member
Fri 10 Feb 2017 10:22:21 AM UTC, comment #6: 

Right, so there now is a 2:1 majority to keep current behavior :-)
Fine with me.

Yet I'm happy that Dan recognizes my point about editor behavior when hidden - that was the gist of my bug report.
Another tricky issue Dan dosn't mention is when a file opened in a tab in the hidden editor is deleted from disk by another program or process.

As to annoying: I use the editor for other files than .m as well - think of .csv etc. that can easily be overwritten by Excel/LO or so. Another one is having files open on an external drive or share that gets disconnected/reconncted (by company network hickups, but that's another story).


The editor has more issues ATM; it stubbornly refuses to save a file unless the parser thinks it is completely valid code; IIRC there's a bug report about it.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 09 Feb 2017 10:11:55 AM UTC, comment #5: 

I think the behavior is fine as far as hiding and unhiding the window.  It should retain the open files.  It wouldn't be difficult to accidentally de-select "Show Editor" when meaning to pick "Show Documentation".  The user wouldn't be happy with having to reopen files.  "Hidden" is the proper meaning, as the editor is always present.  There is a "close all" in the drop-down file menu.  That has a different meaning than the pane button with x.  The editor doesn't go away if "close all" is selected.

One thing I did notice that I think should be changed.  When the editor is undocked with the top-right button, if I then redock the editor it is the Command Window that is shown.  I would think the redocked editor pane should remain visible, not go to the Command WIndow.

I do see Philip's point about only checking for changes to file A when the editor window associated with file A becomes active.  That is the way gvim currently behaves.  That would be a little bit tricky programming Torsten, but I think it can be done.  What makes it tricky is that the editor window should not automatically detect exterior changes when NOT active, but it should automatically detect exterior changes when it IS active.  That is, if I'm typing in the window and that file changes externally, I definitely want to know about it.  So, some Qt configuration (or signal/slot) needs to be set/unset (connected/disconnected) when the window is active or inactive.

What is the annoying scenario here?  That Octave runs some commands and that might change a data file that is open in the editor so the pop-window keeps appearing but the user might not particularly care at the moment?

A nice feature (although I don't think the communication is present for this) would be to ask the user whether an open, modified file should be saved prior to trying to parse that file in the interpreter.

Dan Sebald <sebald>
Tue 07 Feb 2017 09:50:31 PM UTC, comment #4: 

Torsten,

A "hidden" editor is very deceiving status. It is different than a minimized editor pane. IMO, if the editor is "inactive"/"closed", or "hidden" as you call it, it should simply not be there, let alone keep track of files at all. After all, it has been closed by a close button.

What Matlab does differently ATM is closing all tabs if the editor pane is closed and not re-open them when the editor is opened again.

For Octave, I'd suggest that only when the editor gets restored ("unhidden") it could check if the file(s) in its tabs are still there, and if so, only then check for changes. I wouldn't unhide it; those pop-ups are just annoying.
When closing Octave incl. a hidden editor pane with open tabs, then the editor pane could pop up.

But maybe this should be brought up in the maintainers ML.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 07 Feb 2017 08:50:44 PM UTC, comment #3: 

Thanks for the description, now I got it.

In my previous tests, I have closed the editor tab which really closes the file whereas closing the editor just hides the editor widget, but the file remains open (as well as it tab) within the hidden editor. When showing the editor again (by Ctrl-4 or via the menu), the editor pops up up in exactly the same state it had before closing.

In order to reduce the confusion of the users I propose to un-hide the editor (and set the focus to the related tab) when the file-has-changed message pops up.

Torsten Lilge <ttl>
Group Member
Tue 07 Feb 2017 05:21:31 PM UTC, comment #2: 

Steps to reproduce:
1. start up Octave
2. enter "edit bug50106.m"    # editor pops up
3. Save file in editor
4. Click editor pane's close button
4. Open bug150106.m in another program, e,g. notepad++
5. just enter a space somewhere
6. Save file from notepad++

==> Octave pops up a message box, see attached picture.
As you can see in the pic, it is an Octave editor message, but the editor isn't even active.
Clicking "Yes" on that message box doesn't open the editor pane BTW.

To repeat the sequence, you'll have to close the file in notepad++ otherwise Octave won't notice. Maybe that is why you can't reproduce it?



Philip Nienhuis <philipnienhuis>
Group Member
Sun 05 Feb 2017 02:52:43 PM UTC, comment #1: 

I can not reproduce this behavior on Linux, Octave 4.2.0.

Could you please post the exact steps that lead to the described effect?

Torsten Lilge <ttl>
Group Member
Fri 20 Jan 2017 08:41:03 PM UTC, original submission:  

I just noted that when a file is loaded in the GUI editor, next the editor pane is closed with its close button (pane disappears; it doesn't show up anymore with a tick in the main menu's Windows list) and then the file that was just opened is overwritten with another file with the same name, an editor pop-up appears telling the edited file was overridden and asking if you want to reload the file.
(This is on both Linux and Windows, Octave 4.2.0 and 4.3.0+ tip)

This seems incorrect behavior to me - the editor pane is closed yet it does seem to be active behind the scenes.
When closed I'd expect the editor to be completely inactive and only reload (re-read) a file and keep track of its changes when the editor pane is opened again.
In fact this means that files once edited in a now closed GUI editor are silently kept attached (not opened) to the Octave session.
That is at least unexpected behavior.

(I tried in Matlab (r2017a prerelease) but its editor doesn't seem to note at all that a file in the editor was overwritten from outside.)

I was wondering if this is related to bug #50076.

Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #39690:  bug50106.png added by philipnienhuis (224KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-02-21 philipnienhuis StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-02-19 ttl StatusNone Ready For Test
    2017-02-07 philipnienhuis Attached File- Added bug50106.png, #39690

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code