bug#19829: 25.0.50; Design of commands operating on rectangular regions

[Juri Linkov <juri@linkov.net>]

> I think the first thing is to figure out what is the ideal API, ignoring
> backward compatibility.  In this ideal case, I think we'd just want
> a single arg which takes a "region descriptor" (along the lines of what
> you described earlier, tho its format would be opaque) with methods like
> `region-contiguous-p', `region-beginning', `region-end',
> `region-chunks', `region-extract', ...
>
> Then we can try and figure how to adapt it to the real world and how to
> get from here to there.  But I think it mostly means we'll want to go
> from two args (START/END) to just a single arg.  So adding an argument
> doesn't seem to be the obvious best choice.

To achieve the ideal API we need to remove at least one arg END anyway.
But when we'll find a backward-compatible way to remove one arg,
then it would be equally easy to remove two args START and END,
leaving the new arg REGION completely with the new meaning.

OTOH, it would be more difficult to achieve the ideal API while going
thru an intermediate START-OR-REGION arg with the combined meaning
because before changing the meaning of START-OR-REGION to just REGION
requires adapting of function bodies to the new meaning of this arg,
i.e. the choice is between "removing two args START and END" vs.
"removing END and adapting START-OR-REGION".