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

[Stefan Monnier]

> The goal is to design the interface as general as possible
> to be able to define potential future non-rectangular regions.
> For instance, a circular region could be defined in the future as:
>
>   (region
>    (shape . circle)
>    (radius . 42)
>    (center . ...)
>    ...
>
> Then to distinguish a rectangular region we could add (shape . rectangle)
> to the current information:
>
>   (region
>    (shape . rectangle)
>    (positions . ...)
>    ...

Hmm... no I don't see it: this info doesn't need to be exposed anywhere,
it can stay internal to the implementation of a circular region.

IOW, either your REGION arg uses a standard format (e.g. a list of
(START . END) boundaries), or it should be just a constant saying "use
things like region-extract-function ".

> Stuffing the region information into one of its boundary args would be
> too ugly.  I guess this is why you designed a cleaner interface by
> adding a REGION argument to several commands:

No, it's definitely not cleaner: I dislike this approach I used.
I think it's hideous when one (optional) arg says "ignore those two
(mandatory) args".

I agree that hijacking one of the two existing args is ugly, but that's
only because it's asymmetric.  If the region had always been passed as
a single arg (e.g., a pair (START . END)), then it would be very natural
to extend it with more cases.

[ Tangentially related side-note: "r" is the only option in `interactive'
  which provides 2 arguments.  IMO this special case should never have
  existed, but of course we now have to live with it.  ]


        Stefan