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

[Dan Sebald]

Follow-up Comment #5, bug #50106 (project octave):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50106>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/