That seems to be working fine on my machine.

Dmitri.
--

Dmitri, I have attached a new patch that does not cause the freeze on my system. Would you mind to test it with your built configuration before I push it?

This was for non-gui version
./run-octave --no-gui
octave:1> quit
(octave hangs)

A gui version seems to be working.

Dmitri.
--

Changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/2cee3976d88f
move the open dialog for editing files into the main window and is therefore also available when octave was built without qscintilla.

I'm updating the description and goal of this dormant bug.

The current default branch still silently does nothing if the user tries to "edit filename" from the command window in the GUI.

The GUI already has a facility for launching an external editor if the user's preferences say so. The file_editor class checks the preference and opens the file itself or launches the external program when it gets the edit_file_signal. We do want to support this, so we can't just return false from do_edit_file if we have no QScintilla.

If the GUI is built without QScintilla, there could either be some kind of warning that the built-in editor can't be used, or it could automatically fall back to forcing the external editor preference to be used by default.

I guess I wasn't making myself clear. Dan, if you look at the current state of the GUI it already has a setting to configure launching an external editor, this has already been done. Now if the built-in editor is not made because of a missing qscintilla, users may be confused that the preference that says "launch external editor" is not respected. Launching the configured external editor seems like the easiest and most straightforward approach given what the GUI does today.

I have no opinion which way is right way, I'm just throwing out an idea that seems clear and respects the GUI user's preferences.

No I was thinking in the GUI itself, no need to communicate something back to the interpreter. The GUI now has a preference to launch an external editor, separately from the way the editor is launched in CLI mode. If the GUI has no scintilla it could simply launch the external editor.

Just jumping in here, but would it make sense to have the GUI launch the external editor preference and make that be the default if the GUI was built without QScintilla?

I must have mistyped.  Here's the sample error message:

>> edit plot
error: GUI not responding
error: called from:
error:
/usr/local/src/octave/octave-editfile/build1/../octave/scripts/miscellaneous/edit.m
at line 530, column 10
error:
/usr/local/src/octave/octave-editfile/build1/../octave/scripts/miscellaneous/edit.m
at line 335, column 9
-verabtim-

Thank you!  (That behavior was annoying.)

I've attached a changeset that will return various results for the GUI open file function and pass that back to the edit.m script.  This is done using a mutex and illustrates a general approach to freezing the worker process momentarily while the GUI does some work.  Please try it out and see what you think, and give some thought about this general process because I've used this strategy in other places.  One thing I've added is to lock the mutex before going into a wait state, then on the other side try to lock the mutex as a means to verify the worker process has actually gone into a sleep state.  (The way a mutex works is that even if it is in a lock state, it gives up its lock and becomes unlocked when in the sleep state.)  I'm wondering if this may be overdoing the "hand-shaking" a bit because on other examples I've run millions of trials with and without the extra lock attempt and neither ever faltered.

Note that this patch solves the bug of do_edit_file () always returning true, but beyond that the behavior under certain conditions might not be worked out as desired.  For example, try:

edit plot

then

edit foodoo

In the case where there is no file, the GUI currently indicates no success, then edit.m responds by opening an empty file of that name using the custom editor.  If that behavior is to be altered in some way (GUI opens empty file, edit.m gives warning about file not found), then that is a different changeset.

As to your question about whether do_edit_file () should actually be run, I think probably so although I'm not of strong opinion on that.  There are two distinct philosophies to this, as I see it:

1) Use "#ifdef HAVE_QSCINTILLA" liberally to weed out all code that isn't necessary for proper operation.  This is the approach of the changeset because that seemed the way things were tending.  There is the advantage of reducing unused code hunks when the feature isn't needed.  However, there are a couple drawbacks to this.  One is that there gets to be a lot of "#ifdef HAVE_QSCINTILLA" placed about in a half dozen files or so.  Sometimes it is nice to keep that limited to just one or two files (the second philosophy).  A second is that the action this code performed in the presence of QScintilla is no longer available to do other things.

2) The second philosophy is to carry out all the same code to the very last possible point where a decision can be made as to whether to call the QScintilla code.  In that scenario in only one or two files will there be "#ifdef HAVE_QSCINTILLA", probably somewhere in file-editor.cc near:

          file_editor_tab *fileEditorTab = new file_editor_tab ();

and just pass back a code that means GUI editor support is not present.

The reason I prefer philosophy 2 in this case is that I like not having so many instances of HAVE_QSCINTILLA scattered about the code, but more than that (if I understand correctly) there is currently a way for the GUI to use a custom editor with "open" menu.  I think, but I may be wrong, with the current setup where all this supporting code is extracted when there is no HAVE_QSCINTILLA then even that custom editor can no longer be used.  The custom editor is the first option inside of file_editor::request_open_file.  That is why I think isolating things to one instance of HAVE_QSCINTILLA is good.  (If folks agree, let's do that as a separate followup patch so that we have a record of both approaches.  Shouldn't be a difficult change.)

(file #28285)

Hm that "someone" was me.
Note that I do have QScintilla & libqscintilla installed, built for my system.