1

In the Editor window of Octave GUI, if I right click on a function (say, f1) in an expression where it is called, and "Edit f1", function file f1.m opens.

But if my function (now plot_color_marker_ranges) is defined in a script file instead of a function file, when I right-click in an expression where it is called (1) and "Edit" (2) I get the following message

(1) enter image description here

(2) enter image description here

Can I get hyperlinking and navigation when a function is defined in a script file instead of a function file?

Steps to reproduce

  1. Create script file myscript.m containing a function f1. This script file has as its first command 1;.
  2. Create script file mymain.m, and add an expression that calls f1. Add also source('myscript.m') above the first call to f1. This script is in the same directory as myscript.m. At this point, both files were saved on disk.
  3. Run mymain.m from the Editor window of Octave GUI to make sure f1 is correctly used from mymain.
  4. Navigate in the Editor window of Octave GUI to the expression that uses f1.
  5. Right click on any part of the text "f1".
  6. Click on "Edit f1".

EDIT:

Notes:

  1. This helps a lot with editing and debugging.
  2. As of now, whenever I need to debug I set an M-file for the functions. Then I may transfer the function to a script file.
  3. Using Octave 5.1.0 configured for mingw32 under Win 10.
  • Yes, this works with scripts too. – Tasos Papastylianou Aug 10 '20 at 09:50
  • @TasosPapastylianou - This is not what I get, please see edited OP. – sancho.s ReinstateMonicaCellio Aug 10 '20 at 11:47
  • To Octave, the function is defined in memory only. The script file doesn’t define the function, the function is defined by running the script. It is a dynamically-generated function. My guess is that this would be impossible. You could possibly have many different script files that all define a function with the same name, but until you run one of them, the function doesn’t exist at all. You should be using M-file functions. – Cris Luengo Aug 10 '20 at 13:41
  • @CrisLuengo - This is my exact reasoning, and I do not have much hope about this. But I wouldn't like to presume it is impossible from the outset. Perhaps there is some special way (of course, going beyond the basic and intended functioning, and for debugging purposes) of tying the definition in memory with the sourced file that originated it. See edited OP. – sancho.s ReinstateMonicaCellio Aug 10 '20 at 15:55
  • It is not at all clear to me what you're describing. Treat this as a bug and write "steps to reproduce" so that I can follow your logic. As it stands, I cannot reproduce the behaviour. – Tasos Papastylianou Aug 10 '20 at 16:04
  • You haven't really added any information ... are you right clicking in the editor? Or in the terminal? Does your script name end in a .m? Has it been saved? Has it been run once? Is the function meant to be defined only as a command-line function? Are you asking if it is possible to transfer the definition of a command-line function to a file by right clicking its name? – Tasos Papastylianou Aug 10 '20 at 16:16
  • Yes, thank you. I had a copy of v5.1.0 and tried this. It gives me the message you point out. In v5.2.0 the behaviour is different, though not better. If you look at `help edit`, the behaviour used to be that if you tried to edit a command-line function by name, a .m file with the definition from memory would be copied to that file, and created in your home folder. It appears this behaviour has changed at least from v5.1.0 onwards, though it's not clear if this is intentional or a regression bug. If you can't find any reference to it on the octave bug tracker, I'd encourage you to file a bug. – Tasos Papastylianou Aug 10 '20 at 16:29
  • @TasosPapastylianou - I edited the OP, commented on your answer, and hopefully addressed all your questions (I did not imagine some of them were of any relevance). I am in doubt only about "Is the function meant to be defined only as a command-line function?" I would say no, but I am not sure, and I wouldn't know how to do this. I guess whether you see the same as me is a different issue (although quite strange!). – sancho.s ReinstateMonicaCellio Aug 10 '20 at 16:31
  • Having said all that, I would not recommend the kind of workflow which relies on command-line functions. A similar question was asked a couple of days ago, see my answer here: https://stackoverflow.com/a/63263782/4183191 – Tasos Papastylianou Aug 10 '20 at 16:31
  • @sancho.sReinstateMonicaCellio see my comment just before the one you just posted :) – Tasos Papastylianou Aug 10 '20 at 16:31
  • @TasosPapastylianou - The link provided relates to my objective. At any rate, I see pros and cons of both the one-file-per-function (#1) and the packed-functions (#2) approaches. I guess It is not obvious that one should be preferred over the other, but it depends on the case. What I am posting here would be in the pros list for approach #1. – sancho.s ReinstateMonicaCellio Aug 10 '20 at 16:40
  • Have a look at this bug which may relate to your question: https://savannah.gnu.org/bugs/?func=detailitem&item_id=50347 (I didn't even remember this was mine! :p ). Does this help you? In other words, if instead of right-clicking, you actually type `edit plot_color_marker_ranges.m` in the terminal, an .m file with the definition will be generated for you for debugging purposes. – Tasos Papastylianou Aug 10 '20 at 16:44
  • @CrisLuengo also, just to address your comment earlier, see the comment just above. :) – Tasos Papastylianou Aug 10 '20 at 16:44
  • Having said all that, the graphical behaviour does seem broken in v5.2.0. I'll be filing a bug in the octave bug tracker. Thank you for this question (please do not delete it so that I can refer to it in the bug tracker). – Tasos Papastylianou Aug 10 '20 at 16:47
  • Bug submitted as [bug #58931](https://savannah.gnu.org/bugs/?58931). – Tasos Papastylianou Aug 10 '20 at 17:05

0 Answers0