[COFF] Editor Scripts

[Grant Taylor]

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: <http://minnie.tuhs.org/pipermail/coff/attachments/20180706/0de8648e/attachment-0001.bin>