Editing in scripts and workspaces

[ray]

I do a lot of "static analysis" of my code, that is to say "Read the functions" in their calling sequence via the editor.

One of the reasons I really dislike working with functions in scripts (rather than classic workspaces) is the inability to "trace" into a sub-function and then "cut-back" to the original function.

In a classic work-space with function Foo calling function Goo, while reading Foo, I can click on Goo to open a new edit window on Goo. (I like to think of this as an "edit stack" with Foo and Goo in it.) On exiting Goo, I am still editing Foo, and the focus is automatically returns to Foo.

When editing the same function Foo in a namespace script which also contains Goo, when I double click on Goo in Foo, the editor simply jumps to Goo. On exiting from Goo, as there is no "edit stack" or "edit history", rather than returning focus to Foo, the editor simply exits the script.

Is there any way to emulate an "edit stack"(preserves an edit history) when editing a script, so I can "cut back" just as I can with classic workspaces?

(I may well have missed a vital piece of information when scripts were introduced such as a keystroke combination that "un-does" the last "new edit")

I am seriously considering writing a pair of User Commands, one to export the functions from a script into a workspace, and the other to import the functions back into the script. (Or has someone already written them, and would like to make them available to me?)

[Phil Last]

Fortunately Ray this has caught me at an inopportune moment when I don't have much time otherwise I should be ranting about it all night.

There happen to be two mitigators to your problems. Well partly.

Shift+Ctrl+Backspace has been co-opted to fulfil another role in addition to the control of the undo-redo stack. If you don't change anything then it will take you back to the previous function in the script where you last pressed Ctrl+Enter. If you make any changes it will throw away the Ctrl+Enter stack and undo your last change. Unfortunately as the script is a single entity there is only one undo-redo stack as opposed to the one-per-function when editing normal functions in a normal namespace.

The other thing is that there is an option on SALT.Load to disperse the contents. But to my very limited experience it seems that everything is dropped into the root or specified target ignoring any embedding of namespaces within the script.

You'd probably be better off to write your own (that's what I did) but then far better would be not to have them in a script in the first place unless they got there under someone else's control in which case once dispersed don't put them back!

Just a little rant. My favourite hatred of scripts is that I can't see a random selection of five or six of the functions on the screen at the same time which is the way I normally work when a properly modular set of code shares low level subfunctions.

Oh yes and ⎕NS doesn't work exactly the same and also I really can't st....

[Phil Last]

My apologies. Things might have changed but probably I was mistaken. There is only a single stack in the editor that incorporates both functions visited and changes made.

It means that if I go from f00 to f01 and change f01 I can't get back to f00 unless I first undo the change. Not ideal but better than my previous description.

[ray]

Phil,

Thanks for your feedback, and especially the note about "undo" cutting back the edit stack. I had not realised that when editing scripts it could "cut back". Within classic workspace mode, the UNDO is grayed out in an unchanged function.

I also agree with your point about not being able to have multiple functions open in the the Script Editor.

Had I not been use to the added power of the workspace editor since moving from APL on IBM Mainframes to Dyalog, I would be very happy using the script editor. But I find the loss of functionality that scripts introduced is simply too much of a retrograde step for me.

For my own code, whenever possible, I will avoid scripts, and as a result Classes.
Occasionally, however I am forced to us classes (EG for use with MiServer). So I think I will go down the User Command root and write a set commands to convert between Class Scripts and workspace.