RE: PATCH: isearch-yank-until-match

[Drew Adams]

Sorry this message is long.  I've tried to make it
clear.

> 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.

    Examples:
    * text from the kill-ring
    * secondary-selection text
    * text from a register

 2. Yank consecutive text at the search point from the
    buffer.

    Examples:
    * 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.

    Examples:
    * text up to the destination of a movement
      command/key
    * text up to the position resulting from a
      recursive edit

In general, these call for, or invite, three different
behaviors:

 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
    forward.

    (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
opinion.)

 [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:

 `isearch-yank-word-or-char'
 `isearch-yank-char'
 `isearch-yank-word'
 `isearch-yank-line',
 `isearch-yank-until-char'
 `isearch-yank-until-match'

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):

  `isearch-yank-to-key-destination'
  `isearch-yank-through-move'

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
  string.

  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
  movement key.

* `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
recursive edit.)

A macro, `define-isearch-yank-movement-command', is
used to define the last two.  Their only differences
are:

* `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
  `isearch-yank-until-char').

  `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
`isearch-yank-to-key-destination'.
___

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".

isearch-2019-08-19c.patch
Description: Binary data