[Octave-bug-tracker] [bug #54231] GUI attempts to open file for function declared at top-level

[Dan Sebald]

Follow-up Comment #10, bug #54231 (project octave):

I'm testing the changes here.

Original Post) The error message no longer appears and Step-Into proceeds with
the program, printing out


>> yourtest
a =  1
x =  3


However, there is no yellow program line arrow indicating the current line
inside the ggg() inline function.  If I'm understanding correctly, the yellow
arrow should go from the line containging ggg(8), (click Step icon) to inside
the ggg(t) inline routine, (click Step icon) to just after the ggg(8) routine
(after printing "x = 3").  In other words, right now it's as if the current
executing line disappears when it should still be visible within this file.

Comment #4) The crash is gone, the unusual message for empty file has gone. 
Those issues have been fixed, thanks.  However, I still see one small detail
that isn't quite right.  There may be two nuances of the same issue: the
breakpoint attempted at the empty line is remembered when later a new
breakpoint is set after some valid code has been entered and the file saved
(this is difficult to repeat precisely) and one can set the breakpoint at the
blank line in an empty file.  To illustrate:

1) Open a new "unnamed" file.
2) Save the file as "testing123.m"
3) Click on blank line "1".

At that point a breakpoint icon appears.  Also, there is a registered
breakpoint:


>> dbstatus
breakpoint in testing123 at line 1


Furthermore, the registered breakpoint behaves like the conventional
breakpoint.  That is, if one runs "testing123" at the command line, the
program will break at line 1 of the file and the editor highlights said line.

Now, whether that breakpoint should be allowed is one question, but I suppose
the argument can be made that testing123.m is like a function with an empty
first line--don't know.

However, Torsten I think that we'll have to make the clicking on a blank line
in a fresh file be consistent with the unsaved file warning message, i.e.,
"Cannot add breakpoint to modified file.
Save and add breakpoint, or cancel?" simply because having a breakpoint in an
empty file is currently valid.  I believe this is how the "remembered"
breakpoint comes about too--create a new unnamed file, attempt a breakpoint on
the empty line and internally a breakpoint is actually set but the editor
isn't showing that because of the logic in the recent changeset...until later
when the user creates some valid text and adds another breakpoint.  Then the
editor believes it can set breakpoints, so refreshes and the two breakpoints
appear where there was none prior to the action.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/