[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PATCH: isearch-yank-until-match
RE: PATCH: isearch-yank-until-match
Tue, 20 Aug 2019 15:37:13 -0700 (PDT)
Sorry this message is long. I've tried to make it
> C-s C-w C-r C-w messes up the search string. But I
> believe this could be fixed.
Thx. The attached patch takes care of this, I think.
> > Which part(s) do you think should be only optional?
> Changing the behavior of yanking in backward search.
> C-r C-w is still useful to yank forward like it does now.
> I don't remember when needed to yank backward.
> Do you use backward yanking often?
This message tries to make things clearer. See the
attached patch for fixes and related new features.
[As for whether I "use backward yanking often", the
answer is no, because it isn't available! ;-) But when
searching backward it makes sense to be able to yank
buffer text to the left of the search point, prepending
(not appending) it to the search string.]
I see 3 kinds of "yanking" to the search string (there
may be more):
1. Yank an arbitrary string.
* text from the kill-ring
* secondary-selection text
* text from a register
2. Yank consecutive text at the search point from the
* successive chars
* successive words
* successive lines
* successive chars up to a particular char
3. Yank buffer text from the search point up to
an arbitrary buffer position.
* text up to the destination of a movement
* text up to the position resulting from a
In general, these call for, or invite, three different
1. An arbitrary string should always be pulled onto
the end of the search string, regardless of the
current search direction.
2. Consecutive text at point should be pulled onto the
front of the search string, where "front" is in the
search direction. This means prepend the text when
searching backward and append it when searching
(If you want to grab both text that precedes the
search hit and text that succeeds it then you need
to change search directions between the two grabs.)
3. When buffer text from the search point to an
arbitrary position is involved we should let that
position adjust the search string, to either expand
or reduce it.
That is, we should not limit such adjustment to
extension; we should let the arbitrary position
determine whether to extend or retract, as follows:
* If the position is outside the search hit then
extend the search string to add the buffer text
from the hit to the position.
* If the position is inside the search hit then
reduce the search string to remove the buffer
text from the hit to the position.
Search direction remains the same, in any case.
(That means that, unlike case #2, you don't need to
change search direction to grab text both left and
right of the search hit.)
For case #2, you've asked that respecting search
direction be made optional. OK, the attached patch
does that (option `isearch-directional-yank').
I don't think there's a good reason not to respect
search direction by default, however, so the option
value respects direction by default. (Just one
[FWIW, I think that unless search-direction is
respected (prepend/append), yanking text that is
consecutive in the forward direction when searching
backward is just, well, broken/wrong.
That it has always been broken (so no one uses it) is
not a good reason to keep the old, wrong behavior by
default. The real right thing is to not bother with
the option and just always respect search direction
for this case #2. But I've respected your request.]
The attached patch does those things. Following case
#2, it makes these commands respect search direction,
provided option `isearch-directional-yank' is non-nil:
And following case #3, it defines these commands that
adjust the search string according to an arbitrary
buffer position (inside or outside, cursor movement
left or right from the search point):
The new commands are these:
* `isearch-yank-until-char': A version of Karl's
command that respects `isearch-directional-yank'.
* `isearch-yank-until-match' (mentioned previously):
Yank text up through a match for another pattern.
* `isearch-yank-to-key-destination': A version of the
imagined command we discussed that lets you use a
movement key (e.g. `M-f', `C-b') to adjust the search
But it works whether the key moves point left or
right, and whether the destination is inside or
outside the search hit.
In addition, you can use a prefix arg with the
command. The prefix arg is transferred to the
* `isearch-yank-through-move': Enters a recursive edit,
where you can move the cursor any way you like, any
number of times, and then exit the recursive edit.
The command adjusts the search string according to
the resulting cursor position.
The last two allow other action, besides just cursor
movement. I think this is generally a plus, but I can
imagine that someone might disagree.
(In that case, `isearch-yank-to-key-destination' could
bind `buffer-read-only', to prevent buffer changes.
But there's no way to control what a user might do in a
recursive edit, AFAIK. E.g., there doesn't seem to be
any hook that's used when entering or exiting a
A macro, `define-isearch-yank-movement-command', is
used to define the last two. Their only differences
* `isearch-yank-to-key-destination' reads a key,
inhibits field-text motion, disables bindings of the
Isearch keymap, and invokes the key's command.
* `isearch-yank-through-move' calls `recursive-edit'.
As for key bindings, here are my thoughts:
* `C-M-.' for `isearch-yank-until-char'.
* `C-M-m' (aka `M-RET') for `isearch-yank-until-match'.
* `C-M-c' for `isearch-yank-through-move' (_not_ for
`C-M-c' is bound globally to `exit-recursive-edit'.
It's how you tell `isearch-yank-through-move' that
you're done moving the cursor. It helps to use the
same key to start and end the command.
And because of that global binding, no (other)
Isearch command should be bound to `C-M-c'. (I
hadn't considered this before, when I said I was OK
with `C-M-c' for `isearch-yank-until-char'.)
The only binding I feel strongly about is `C-M-c'. I
don't have a suggestion yet about a binding for
P.S. The patch also renames the parameter to
`isearch-yank-internal' from JUMPFORM to JUMPFUN,
because it's a function, not a form. And it fixes
the doc string accordingly: "function", not
necessarily "lambda expression".
Description: Binary data