From mboxrd@z Thu Jan 1 00:00:00 1970 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 6 Jul 2018 13:04:28 -0600 Subject: [COFF] Editor Scripts In-Reply-To: <9dadecbf12b9f0d8debe8fd7c8984401766fbb0a@webmail.yaccman.com> References: <9dadecbf12b9f0d8debe8fd7c8984401766fbb0a@webmail.yaccman.com> Message-ID: <274a9a62-6c27-376a-a74d-6dd2e3268ae9@spamtrap.tnetconsulting.net> On 07/06/2018 12:27 PM, Steve Johnson wrote: > What I used editor scripts for before utilities like sed came along was > primarily in what would now be called refactoring. Okay. I think you just touched on at least one thing that predates my unix experience. sed has always existed for me. (I've only been doing unix things for about 20 years.) I would think that what I do in sed could (still) fairly easily be done by scripting ed. As I type this, I realize that it might be possible (period, not just easier) to do something with ed scripts than with sed. (See the "Pass variable into sed program" thread from early May this year in the alt.comp.lang.shell.unix.bourne-bash newsgroup.) > A common pattern for me was fo have a function foo that  took two > arguments and I wanted to add another argument. Okay. > Recall in those days that the arguments to a function had no type > information   foo( x, y ) would be followed by int x in the body of the > function. I'm ignorant of most of that, both from timing and the fact that I do exceptionally little programming. > Also, htere were no function prototypes.   So a very common error (and a > major motivation for writing Lint) was finding functions that were > called inconsistently across the program. Okay. I can see how that would be problematic and give rise for tools to help avoid said problem. > If I wanted to add an argument to foo, the first thing I would do is run > an editor script, something like > >     1,$s/foo/old_foo/g >      w >      q > > and apply it to all my source and header files. I would think that the exact commands could be run via command mode (thus bufdo) or as a script redirected into ex. I would also seriously consider sed (which you say didn't exist at the time) across the proper files (with shell globing for selection). > Then I'd verify that the resulting files compiled and ran. Fair. That makes perfect sense. I've done similar myself. (All be it rarely.) > Then I would take the definition of foo (now called old_foo), and change > it to its new form, with the extra arguments, and rename it to foo. I assume you'd use a similar editor script with a different regular expression and / or set of actions. As I type this I can't think of the exact actions I'd use. I'd probably search for the declaration and substitute the old declaration with the new declaration, go down the known number of lines, add the next int z line. Then I'd probably substitute the old invocation with the new invocation across all lines (1,$ or % in vi). I think I'd need a corpus of data to test against / refine. > Then I would grep my source files for old_foo and change the calls > as needed. Compiling would find any that I missed, so I could fix them. *nod* > Sounds like a lot of work, but if you did it nearly every day it went > smoothly. I don't think it is a lot of work. I think it sounds like a codification of the process that I would go through mentally. I've done similar with a lot of other things (primarily config files), sometimes across multiple systems via remote ssh commands. I think such methodology works quite well. It does take a mindset to do it. But that's part of the learning curve. > ed lent itself to scripts.  It was all ascii and line oriented. Fair. > With glass teletypes came editors like vi. Suddenly, a major fraction > of the letters typed were involved in moving a cursor alone. Hum. I hadn't thought about that. I personally haven't done much in ed, so I never had the comparison. But it does make sense. I do have to ask, why does the evolution of vi / vim / emacs / etc preclude you from continuing to use ed the way that you historically used it? I follow a number of people on Twitter that still prefer ed. I suspect for some of the reasons that you are mentioning. > Also, vi wasn't as good at doing regular expressions as ed, especially > when lines were being joined (this was later fixed). That's all new news to me. I've been using vim my entire unix career. I was never exposed to the issues that you mention. > So editor scripts went from daily usage to something that felt > increasingly alien. I guess they don't seem alien to me because I use commands in vim's command mode weekly (if not daily) that seem to be the exact same thing. (Adjusting for vim's syntax vs other similar utilities.) So putting the commands in a file vs typing them on the ex command line makes little difference to me. I'm just doing them interactively. I also feel confident that I could move the commands to their own file that is sourced if I wanted to. Thus I feel like they are still here with us. > The fact that you ccould see the code being changed was good, but find > the lines to change across a couple of dozen files was much more time > consuming... Ya. I can see a real advantage of just having the operation happen without re-displaying (printing) could be beneficial. Aside: I'm reminded of a time when I edited a big (for the time) file (< 1MB) with edit on a 386. I had it do a search for a shorter string and replace it with a longer string. I could literally watch as it brought the line onto (usually the top of) the screen, (re)drawing the rest of the screen, do the substitution, which caused bumping subsequent text, which meant redrawing the remainder of the screen, then finding the next occurrence on screen, and repeating. I ended up walking away as that operation couldn't be canceled and took about 20 minutes to run. Oy vey. > PS:  There are IDEs that make quickly finding the definitions of a > function from its uses, or vice versa, much easier now. I think that it's highly contextually sensitive and really a sub-set of what scripts can do. > But I think it falls short of being an abstraction mechanism the way > editor scripts were... Agreed. Once you know the process that's being done, you can alter it to work for any other thing that you want to do. > In particular, you can't put such mouse clicks into a file and run them > on a bunch of tiles... Oh ... I'm fairly certain that there are ways to script mouse clicks. But that's an entirely different level of annoyance. One of which usually requires things to retain focus or at least not be covered by other windows. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: