17 Sep
2019
17 Sep
'19
12:20 a.m.
The "block copy in an editor" thing is
something which has intrigued
me for years. poor old ed/ex/vi just couldn't do it, and for the life
of me, I could not understand why this was "deprecated" by the people
writing that family of editors.
One might trace it to the founding tenet that a file is a stream of bytes,
reinforced by the absence of multidemensional arrays in C. But it goes
deeper than that.
Ed imposes a structure, making a (finite) file into an array, aka list,
of lines. It's easy to define block moves and copies in a list. But
what are the semantics of a block move, wherein one treats the list
as a ragged-right 2D array? What gets pushed aside? In what direction?
How does a block move into column that not all destination rows
reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?
I think everyone has rued the lack of block operations at one time
or another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?
Similarly the 'repeat this sequence of
commands' thing which emacs had.
Ed's g command does that, except the sequence can't contain another g.
Sam, barely harder than ed to learn, cures that deficiency and generalizes
in other ways, too--but has no block operations.
Doug
17 Sep
17 Sep
12:42 a.m.
At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
Ed imposes a structure, making a (finite) file into an
array, aka
list, of lines. It's easy to define block moves and copies in a list.
But what are the semantics of a block move, wherein one treats the
list as a ragged-right 2D array? What gets pushed aside? In what
direction? How does a block move into column that not all destination
rows reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?
I think everyone has rued the lack of block operations at one time or
another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?
Just in case anyone didn't know, Vim has what it calls "visual block"
highlighting and operations. CTRL-V begins one and you use the usual
movement keys to shape and size it, then an operator like (y)ank or
(d)elete.
It won't always work as one expects because of the very questions that
Doug raises above.
Vim also has characterwise blocks (begin with 'v') and linewise blocks
(begin with 'V').
The last is, more than any other single factor, what pulled me over from
traditional vi (really nvi in my case). It was a big win over
line-counting with ":.,+n" expressions. In retrospect I should have
been smarter and just typed ":.,/pattern/", using as /pattern/ some
short string that did not appear in any of the lines I wanted to operate
on.
Though the vi clone with the best name was, indisputably, elvis.
Regards,
Branden
2:02 a.m.
New subject: block operations in editors, was My EuroBSDcon talk
I also went vim, wanting nvi to be there but Keith Bostic lost impetus
or motivation. I am not in love with vim, I still feel like its got a
lot of glitter, but with the keystrokes for homekeys burned into my
brain it was the best choice. I use ed periodically to remind myself
what reductionism in editors means. I used atom and visual basic,
they're ok for what they are.
Vim also gave me syntax colouring. again, I was suprised how quickly I
came to use it, having decried it. I guess like food, in matters of
(editor) taste there is no good disputation.
Sam didn't get into my frontal lobes quickly enough. I think if 8th
and plan9 had been only TWO years earlier out the door, a lot of the
world would look different. I look at kubernetes now, I live in it
actually, and I feel like inferno was leading me there but I got there
via very twisty paths.
Really, what I think UNIX missed the most, was the plumber. GTK and
KDE and the like dance around the problem of cut-paste between
processes in ways which I am led to believe the plumber fixed long
ago. Another thing which had it been only two years earlier, might
have got us to a more cohered space.
"first, kill all the lawyers" is probably the subtitle of a UNIX book.
Counterfactuals.
-G
On Tue, Sep 17, 2019 at 10:42 AM G. Branden Robinson
<g.branden.robinson(a)gmail.com> wrote:
At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
Ed imposes a structure, making a (finite) file
into an array, aka
list, of lines. It's easy to define block moves and copies in a list.
But what are the semantics of a block move, wherein one treats the
list as a ragged-right 2D array? What gets pushed aside? In what
direction? How does a block move into column that not all destination
rows reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?
I think everyone has rued the lack of block operations at one time or
another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?
Just in case anyone didn't know, Vim has what it calls "visual block"
highlighting and operations. CTRL-V begins one and you use the usual
movement keys to shape and size it, then an operator like (y)ank or
(d)elete.
It won't always work as one expects because of the very questions that
Doug raises above.
Vim also has characterwise blocks (begin with 'v') and linewise blocks
(begin with 'V').
The last is, more than any other single factor, what pulled me over from
traditional vi (really nvi in my case). It was a big win over
line-counting with ":.,+n" expressions. In retrospect I should have
been smarter and just typed ":.,/pattern/", using as /pattern/ some
short string that did not appear in any of the lines I wanted to operate
on.
Though the vi clone with the best name was, indisputably, elvis.
Regards,
Branden 
11:01 a.m.
---------------------------------
Though the vi clone with the best name was, indisputably, elvis.
unfortunately unmaintained.
elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help
support than vim. There are no plugin, vimscript feature sas well as no python/perl
support. I'm interested in a vi with syntax coloring and help support, however I
don't need scripting features. Therefore I hope someone will take over maintenance,
as I'm too old for that.
1:25 a.m.
New subject: block operations in editors, was My EuroBSDcon talk
On Mon, 16 Sep 2019 20:20:32 -0400 Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
Doug McIlroy writes:
The Rand editor e handled all this reasonably well.
A file was treated as a virtual quarter plane, with 0,0 as
the start of the file (you could move a cursor anywhere
including a non-existant line or column. Extra blanks or
lines were added only if you actually typed something there).
In the command line (like vi's exmode) for many commands you
can specify an area of operation which can be n lines, n
paragraphs or a rectangle, starting at the cursor position. Or
you can select a rectangular area with the "mark" command. If
you move the cursor straight down, N lines would be chosen.
To pick nx1 rectangle, you move cursor right one place after
marking.
open would open up a blank area, pushing text left as
necessary. close would close up an area, pushing text right
if necessary. erase would blank out an area (erase text but
leave text outside alone). run command replaced the contents
with the output of a shell command. feed was like run except
it kept the original and inserted new data at the cursor.
Tabs were not separators but stood for specific columns. By
default every 8 columns but you could change them to whatever.
picking a rectangle handled them appropriately. IIRC. You
stored non standard tab positions in a separate file.
The
"block copy in an editor" thing is something which has intrigued
me for years. poor old ed/ex/vi just couldn't do it, and for the life
of me, I could not understand why this was "deprecated" by the people
writing that family of editors.
One might trace it to the founding tenet that a file is a stream of bytes,
reinforced by the absence of multidemensional arrays in C. But it goes
deeper than that.
Ed imposes a structure, making a (finite) file into an array, aka list,
of lines. It's easy to define block moves and copies in a list. But
what are the semantics of a block move, wherein one treats the list
as a ragged-right 2D array? What gets pushed aside? In what direction?
How does a block move into column that not all destination rows
reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?
I think everyone has rued the lack of block operations at one time
or another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?
1676
days inactive
1676
days old
4 comments
5 participants
participants (5)
-
Bakul Shah -
Doug McIlroy -
G. Branden Robinson -
George Michaelson -
Thomas Paulsen