BookmarkSubscribeRSS Feed

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).

8 Comments
ChrisHemedinger
Community Manager

@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
Rhodochrosite | Level 12

@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
Community Manager

@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
Rhodochrosite | Level 12

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
Community Manager

@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.

 

replace.png

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
Super User

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
Lapis Lazuli | Level 10

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
Community Manager
Status changed to: Suggestion Implemented

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