Re: Structural regular expressions

[Davis Herring]

> Indeed, we could probably go a long way by simply extending our notion
> of region so as to allow it to be non-contiguous.
>
> Patches welcome,

This is no patch, but I had an idea for the interface for this:

Definition: simple region
The interval (possibly empty) between point and mark, exactly as it is now.

Variable: region-list
A set of non-empty, disjoint intervals, always local to each buffer.  Each
is a cons of two markers.  Typically each is highlighted in a subtle
fashion, even outside Transient Mark Mode.

Function: multi-region
Returns the union of the region list and the simple region (using
`point-marker' and/or `mark-marker' as needed).  (If the simple region is
empty and the region list is not, the simple region is ignored and the
return value equals `region-list'.)  This is the user-visible
possibly-disconnected upgrade to the region concept.

User option: multi-region-separator (default: "\n")
String to insert between separate intervals of the multi-region when
concatenated.

(defun multi-region-string (&optional sep)
  "Return the contents of the multi-region.
Separate intervals with SEP (or `multi-region-separator' if omitted)."
  (mapconcat (lambda (c) (buffer-substring (car c) (cdr c)))
             (multi-region) (or sep multi-region-separator)))

Rule: (interactive "r") maps over the multi-region.
Perhaps with some way to disable it (prefix command, or just a quick way
to suppress/restore the region list while leaving the simple region
alone), `call-interactively' would handle an interactive spec once
(including any prompting), then repeatedly call the function with the
start and end set to the start and end of each interval in the
multi-region in turn, in buffer order.

Rationale: This is a very intrusive change!  But it's often the right
thing (delete-region, upcase-region, ispell-region, translate-region,
underline-region, indent-region, count-lines-region,
expand-region-abbrevs, and probably eval-region) and is one of very few
ways of letting existing code apply in any sense to multi-regions.  (If
doing it by default is too much, a prefix "mutlify" command could be
provided instead, and all of this could be optional.)

Another spec ("R"?) could be added for commands like `narrow-to-region'
that should either operate only on the simple region (or fail if the
region isn't simple?).  Yet another spec might pass all of the
multi-region at once so that commands like `kill-region' and
`write-region' could use `multi-region-string' or otherwise act on them
coherently.

Command: keep-region
Unions the current simple region into the region list (may coalesce
existing intervals).  Immediately afterwards, the simple region is
entirely redundant and has no effect (until point or mark moves).

Command: drop-region
Removes the current simple region from the region list (may split existing
intervals).  Immediately afterwards, the multi-region is no different!

Command: drop-this-region
Remove the interval that contains point from the region list.

Command: drop-multi-region
Clears the region list (causing the multi-region to equal the simple region).

These low-level commands would be too tedious to be the principal user
mechanism for manipulating the multi-region.  So we add:

Command: mark-regexp
Add to the region list all matches for a regexp (following point, for
consistency with `how-many' and `keep-lines').  Framing the regexp with
^.*....*$ allows this command to mark lines (or a separate command could
do that for you).  Even when lines are marked in that fashion, the
newlines between them are not, so each line is a separate interval.

Command: unmark-regexp
Delete from the region list all regions within which a match for a regexp
exists.

These are analogous to the "highlight all" feature in Firefox, for
instance.  Then we can navigate among them:

Command: next-region
Move point to the closest following beginning of a region list interval. 
This could be used in macros.

Command: count-regions
Display in the echo area how many intervals are in the region list and the
multi-region (which may be one more or many fewer).

Since region lists are complicated things, the user might want to save
them and reuse them later, so letting registers hold them would be good. 
(Should they store the region list or the multi-region?)

WDOT?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.