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

[Bakul Shah <bakul@bitblocks.com>]

On Mon, 16 Sep 2019 20:20:32 -0400 Doug McIlroy <doug@cs.dartmouth.edu> wrote:
Doug McIlroy writes:
> > 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?

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.