[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19829: 25.0.50; Design of commands operating on rectangular regions
From: |
Stefan Monnier |
Subject: |
bug#19829: 25.0.50; Design of commands operating on rectangular regions |
Date: |
Wed, 01 Jul 2015 23:02:51 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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