Add a full featured editor for editing the SAS code for a stored process in EG

[ScottBass]

If I edit a program entry in EG, I have find, replace, and line/column numbers (and perhaps other features).

If I edit the SAS code for a stored process in EG, I get a crippled editor with none of these features.

I have a stored process that's 1000+ lines long.  If I get an error in the log, it would be handy to be able to search the code for the offending line.  If I'm trying to get the indentation right on a block of code that doesn't fit in the editor, having the column number would help.

In short, have *consistent* editor functionality in both scenarios (as well as any other place in EG where you can edit code).

[ChrisHemedinger]

@ScottBass - Good News! The Find window is in EG 7.13.  And line numbers are there if you turn on the Show line numbers option in Program->Editor Options.

[ScottBass]

@ChrisHemedinger 

Hi Chris, is it the full functionality as the "usual" program editor in EG?  For example, does it have "Line ###, Col ###" in the lower right corner?  I use the col ### when I'm trying to line up the indentation level for, say, lines 5 and 500.

[ChrisHemedinger]

@ScottBass - alas, no.  It shows line numbers in the margin, if you have Line Numbers on for your Editor Options.  It does support Zoom with Ctl+ and Ctl-, so you can check the layout of your program "from afar".  

For deeper manipulation and formatting, the workaround is to copy the code, paste into another EG session in a program window, make your changes, and paste it back.

[ScottBass]

Is it really that hard to make the editor functionality consistent within EG, whether you're editing a program entry or stored process code?  I'm of course not familiar with the coding involved, but I'm struggling to see why this would be hard.

[ChrisHemedinger]

@ScottBass - I don't think it's a matter of difficulty, just priority.  I think we expect programmers to do most of the hardcore coding in the full program editor (where they can run segments of code, debug, use version control, etc) and use the Stored Process editor for smaller tweaks.  

You can use the full editor in your SAS Enterprise Guide project to work on code, then use the Replace with code from option to pull that code into your STP.

Since there is already a way of working that allows you to leverage the full editor, it's more difficult to justify bringing the Stored Process experience to full parity (adds more complexity, testing, etc.).  But the spirit of this ballot is to allow others to weigh in, and if the current experience isn't "good enough", then I know the developers will want to hear about it.

[Quentin]

Personally, I avoid using the stored process editor to edit code by keeping my stored process code to a minimum (even just a single %include statement or a macro call), and leaving my real code in .sas files.  That way I can edit the .sas files in EG program editor, or any other editor.  Generally any stored process I have is going to involve multiple macro calls anyway, so as long as I'm relying on .sas files stored somewhere on the OS, it seems reasonable to put all of my code there, rather than buried in the stored process definition.

This is not an argument against the proposed enhancement, as I have seen many people struggling to edit extensive programs in the stored process editor.

[paulkaefer]

To add to @Quentin's comment, editing SAS code directly instead of .egp files is better for version control. As .egp files are binary, versioning doesn't work so well. The code also works across versions (e.g., EG 6.1 can't open EG 7.1+ .egp project files), is more portable, and can be kicked off via shell scripts, etc.

[ChrisHemedinger]

We're marking this Delivered -- as much as it's going to be.  The main cases are covered -- no additional work is planned.