[TUHS] block operations in editors, was My EuroBSDcon talk

[George Michaelson]

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 at 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