Re: Design of commands operating on rectangular regions

[Juri Linkov <juri@linkov.net>]

> Can you tell me more about the meaning of `region-noncontiguous-p' here?
> How does the caller know when this option is required?

To be able to process a non-contiguous region differently than the ordinary
region, a command needs to know either whether it's operating on the special
region (so the command itself can acquire all additional information about
the region and its shape), or receive all this information through its arg.

I provided the patches for both variants in bug#19829, and it seems that you
prefer the latter, if I'm not mistaken.  Please confirm do you think that
it would be better to add a 'region' arg such that when used programmatically
it's required to be in this form, or when used interactively it takes a form
with fine-grained boundaries:

  (region
   (shape . rectangle)
   (positions . (1 . 2) (3 . 4) (5 . 6) ...)
   ...

to accompany coarse-grained boundaries in START and END args.

> My takeaway is that this patch conflates user-level indications (selected
> regions) too closely with the programmatically provided entities (the region
> specified by START END). Perhaps it points to the need for an `interactive'
> specifier to request "the current region, though if multiple sub-regions
> exist, the set of spans indicated by those sub-regions". A function like
> `shell-command-on-region' should be determined by its arguments. This patch
> introduces a much tighter coupling with its context of use than what we had
> previously.
>
> To make that last statement clearer: Right now, `shell-command-on-region' acts
> on a buffer, and a region of text within that buffer. This region is provided
> to the command through its arguments by (interactive "r"). The only thing that
> `shell-command-on-region' needs to do beyond that is to query the current
> buffer, in order to feed text to the executed process. So, our "context" is
> the current buffer, while everything else is provided by its arguments.
>
> Your patch introduces a more hybridized behavior: (interactive "r") provides
> the total extent of the region, but now there's an additional parameter,
> `region-noncontiguous-p', that alters the behavior of shell-command-on-region
> so that it pays attention not only to the current buffer, but also to
> user-specified regions when drawing text from the buffer. And these regions
> are only somewhat related to the region provided by "interactive 'r'".
>
> I feel that the semantic "level" of these three arguments -- START, END and
> REGION-NONCONTIGUOUS-P -- are now different, which I find confusing.
> `region-noncontiguous-p' doesn't relate to the `interactive' form at all, but
> rather solely to this new behavior, internal to shell-command-on-region.