alert user in editor when external program modified .sas file

[AndrewZ]

When the user is editing a .SAS file in the SAS Enhanced Editor and the .sas file is modified by an external program, the SAS Enhanced Editor should alert the user with an option to reload the changes. This helps prevent unwanted surprises.

This is a common feature in Notepad++, Aginity, and other software.

Use cases:

- someone else modifies a file stored on the network

- the same user modifies the file using a different SAS editor session or different application

[paulkaefer]

I get notifications like this. Perhaps you are running an older version of EG?

[ballardw]

Am I the only one that finds an environment where my program is being modified by some else while I am working on it a tad scary?

I suspect that you are referring to the Display Manager version, not one of the server centric installations like Enterprise Guide. DMS wasn't intended for shared source code as some of the server versions might. So you may want to take additional steps in managing shared code files. It seems like SAS is not adding many enhancements to the actual DMS portion of the system.

[ChrisHemedinger]

This feature is already in SAS Enterprise Guide.  Usually it plays up when you open the SAS program in your "preferred" editor from within EG (mine is Notepad++) -- any changes you make are detected, and you can slurp in the new version when prompted.

[AndrewZ]

@paulkaefer I have not used Enterprise Guide for years. I am using SAS 9.4M5 in the SAS Enhanced Editor on Windows. This enhancement request is specifically for SAS Enhanced Editor.

@ballardw In every case I remember, I made the other changes in another editor. 🙂  For example, I use various tools, such as the SQL formatting plugin, in Notepad++ to reformat source code.

@ChrisHemedinger It sounds like I should give EG another chance. Last time I used it, it was painfully clunky and slow. 

[ballardw]

@ballardw In every case I remember, I made the other changes in another editor. 🙂  For example, I use various tools, such as the SQL formatting plugin, in Notepad++ to reformat source code.

So you say you are editing the same program file in two different programs at the same time?

Then I would say "don't do that". I sounds like the edits you may have made in the SAS editor have a chance of getting ignored by the other program.

I have used other editors for SAS code, predominately the OS/2 EPM editor because it had some very nice features (and really really wish it could be ported to another environment). But I never attempted to have the same files open in both that editor and SAS at the same time. Or course I could submit programs from EPM to run so I did not have to have the program open in SAS to run.

[AndrewZ]

@ballardw Regarding "don't do that." Well, living dangerously (if you can call this that) generally works for me, and if this enhancement were implemented, it would work even better.

Here are two concrete use cases for using multiple editors at once.

1. I am editing code in the SAS Enhanced Editor while also checking code into a Git repository. I discover that I left temporary debugging code that I do not want to keep, so in my Git client (e.g., SourceTree) I discard a hunk of changes. This modifies the .sas file on the disk, and then the SAS editor should reload the file.

2. Likewise, I am editing SAS code, and there is a chunk of pass-through SQL code with ugly formatting, so I open Notepad++ to use the Poor Man's T-SQL Formatter  to reformat the SQL code. Then, the SAS editor should reload the .sas file with the pretty SQL code.

[ballardw]

I suggest if this your typical work mode that you consider implementing a full blown code source management system.

I just see too high a chance of a few edits made in the SAS editor but not saved being 'lost' due to the external edit step.

But I'm paranoid about such things after working in an environment where I had to work with coworkers. I corrected data multiple times because a coworker would not change an script with a logic error and then would send the result to the client.

So I would fix the data, send the result. Then with the next collection cycle the coworker ran the bad script against the entire data set. Wash, rinse, spin, repeat... Luckily I could keep my scripts separate from that coworker.