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

Doug McIlroy doug at cs.dartmouth.edu
Tue Sep 17 10:20:32 AEST 2019

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


More information about the TUHS mailing list