[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20070: 24.3; have commands such as downcase-region act on a rectangl

From: Stefan Monnier
Subject: bug#20070: 24.3; have commands such as downcase-region act on a rectangle region
Date: Sat, 14 Mar 2015 12:31:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> Currently, `downcase-region' is defined with the interactive spec 'r'
> that calls the function with point and mark as 2 args.

Indeed, same problem as kill-region, to which I had to add a `region'
argument (which basically says "we're called interactively so use
whatever is the region rather than BEG and END").

> For backward-compatibility reasons this can't be changed.  So maybe
> a new interactive spec e.g. 'R' should call the function with 2 lists
> where the first list will contain a list of beginnings of all intervals
> in the rectangular region, and the second list of endings of intervals?

Obviously, there will be many more commands that need to be adjusted to
the extended notion of "region" which can now be composed of various extents.
I'm not sure we need/want a new "R", because I think all cases of "r"
are currently broken when the region is non contiguous (i.e. they all
need to use "the new system").

One way to handle it generically, is to change call-interactively such
that when the argument is "r", the command is called once for each
"extent".  Obviously, this won't work correctly for all cases, tho.

Another option is to make "r" behave along the lines of your "R" (tho
I much prefer a list of pairs than a pair of lists, so one of the two
args would end up "useless").

> Then a command using it will need to add another outermost loop to pop
> interval boundaries from both list arguments `begs' and `ends' to process
> intervals using the same logic like it processes a single region now.

Indeed.  Maybe such a loop would be common enough that it'd be
worthwhile adding some ad-hoc handling (e.g. make call-interactively do
the looping as suggested above, tho maybe only after checking some
special property of the command).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]