7 Jul
2018
7 Jul
'18
1:04 a.m.
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