bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Perry Wagle]

In xemacs, if I double click on a word, the word is highlighted.  If I then press control-s for search, and click the middle mouse button *without moving the mouse*, I will paste that word into the search string, and all is good.

Emacs, on the other hand, does not support this idiom.  For some reason, the middle mouse button *ABORTS* the search mode, and then pastes the word under the mouse.  Why would you want that?

This idiom alone has kept me using xemacs for over a decade.  I'd like to switch to emacs now.

Can I fix this easily with option-setting, or does it require me to hack and add the correct behavior?

---

In GNU Emacs 23.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.29)
of 2010-05-08 on black.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--host=x86_64-apple-darwin' '--build=i686-apple-darwin' '--with-ns' 'build_alias=i686-apple-darwin' 'host_alias=x86_64-apple-darwin' 'CC=gcc -mmacosx-version-min=10.5''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x r e p o SPC r t SPC e SPC SPC <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug help-mode view tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Stefan Kangas]

Perry Wagle <wagle@mac.com> writes:

> In xemacs, if I double click on a word, the word is highlighted.  If
> I then press control-s for search, and click the middle mouse button
> *without moving the mouse*, I will paste that word into the search
> string, and all is good.
>
> Emacs, on the other hand, does not support this idiom.  For some
> reason, the middle mouse button *ABORTS* the search mode, and then
> pastes the word under the mouse.  Why would you want that?
>
> This idiom alone has kept me using xemacs for over a decade.  I'd
> like to switch to emacs now.
>
> Can I fix this easily with option-setting, or does it require me to
> hack and add the correct behavior?

This was reported 9 years ago but unfortunately never got a reply at
the time.

I think you should set mouse-yank-at-point to t to get the desired
behaviour.  Could you please try that and see if that works for your
use-case?

Best regards,
Stefan Kangas

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi —

I made some change to an .el file somewhere which fixed the problem.  Do you want me to track it down?

— Perry

> On Jan 15, 2020, at 11:24 AM, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Perry Wagle <wagle@mac.com> writes:
> 
>> In xemacs, if I double click on a word, the word is highlighted.  If
>> I then press control-s for search, and click the middle mouse button
>> *without moving the mouse*, I will paste that word into the search
>> string, and all is good.
>> 
>> Emacs, on the other hand, does not support this idiom.  For some
>> reason, the middle mouse button *ABORTS* the search mode, and then
>> pastes the word under the mouse.  Why would you want that?
>> 
>> This idiom alone has kept me using xemacs for over a decade.  I'd
>> like to switch to emacs now.
>> 
>> Can I fix this easily with option-setting, or does it require me to
>> hack and add the correct behavior?
> 
> This was reported 9 years ago but unfortunately never got a reply at
> the time.
> 
> I think you should set mouse-yank-at-point to t to get the desired
> behaviour.  Could you please try that and see if that works for your
> use-case?
> 
> Best regards,
> Stefan Kangas

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Stefan Kangas]

Perry Wagle <wagle@mac.com> writes:

> Hi —

Hi,

Thanks for replying back so quickly.

> I made some change to an .el file somewhere which fixed the problem.
> Do you want me to track it down?

Could you first please try the following with a recent version of Emacs:

1. Run    "emacs -Q"
2. Type   M-: (setq mouse-yank-at-point t) RET

Then see if that solves the problem for you.  If it doesn't, I'm not
sure I understand what the problem is.

Best regards,
Stefan Kangas

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I’m using Aquamacs, which worked, apparently until I just recently upgraded it, and it blew away a lot of my customizations.

— Perry

PS no -Q

> On Jan 15, 2020, at 12:14 PM, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Perry Wagle <wagle@mac.com> writes:
> 
>> Hi —
> 
> Hi,
> 
> Thanks for replying back so quickly.
> 
>> I made some change to an .el file somewhere which fixed the problem.
>> Do you want me to track it down?
> 
> Could you first please try the following with a recent version of Emacs:
> 
> 1. Run    "emacs -Q"
> 2. Type   M-: (setq mouse-yank-at-point t) RET
> 
> Then see if that solves the problem for you.  If it doesn't, I'm not
> sure I understand what the problem is.
> 
> Best regards,
> Stefan Kangas

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>     This thread is very familiar:
>     https://lists.gnu.org/archive/html/help-gnu-emacs/2011-11/msg00116.html

There is another similar thread:
https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00003.html

> I think this code was the answer for me back then:
>
>> (defun isearch-mouse-2 (click)
>>  "..."
>>  (interactive "e")
>>  (isearch-yank-x-selection)
>>  (deactivate-mark t))

Do you propose to add this to isearch.el?

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The only objections I’ve heard are from mouse-haters wanting to offer keyboard-only solutions and insisting the mouse was evil.

— Perry

> On Jan 19, 2020, at 4:07 PM, Juri Linkov <juri@linkov.net> wrote:
> 
>>    This thread is very familiar:
>>    https://lists.gnu.org/archive/html/help-gnu-emacs/2011-11/msg00116.html
> 
> There is another similar thread:
> https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00003.html
> 
>> I think this code was the answer for me back then:
>> 
>>> (defun isearch-mouse-2 (click)
>>> "..."
>>> (interactive "e")
>>> (isearch-yank-x-selection)
>>> (deactivate-mark t))
> 
> Do you propose to add this to isearch.el?

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

> I realize now that I was trying the wrong thing, and I've been able to
> reproduce this on both Mac and GNU/Linux using GNU Emacs.

Stefan, could you please help to reproduce the issue.
What are the necessary steps?

I see that the existing implementation of isearch-mouse-2
allows yanking the selection when clicked in the echo area,
but when clicked in the buffer it goes into infinite recursion,
because isearch-mouse-2 calls itself again.

Should it yank the selection when clicked in the buffer too?

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> Stefan, could you please help to reproduce the issue.
> What are the necessary steps?

Sorry for not following up on this sooner.

  0. emacs -Q
  1. M-: (setq mouse-yank-at-point t) RET
  2. double click any word to mark it
  3. C-s
  4. mouse-2 [with cursor still over the original window, not in
     minibuffer]

> I see that the existing implementation of isearch-mouse-2
> allows yanking the selection when clicked in the echo area,
> but when clicked in the buffer it goes into infinite recursion,
> because isearch-mouse-2 calls itself again.

This is what I see as well, on current master.

Using 26.3, it yanks the text at point in the original buffer.

> Should it yank the selection when clicked in the buffer too?

That was the requested behaviour AFAIU, yes.

Best regards,
Stefan Kangas

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>   0. emacs -Q
>   1. M-: (setq mouse-yank-at-point t) RET
>   2. double click any word to mark it
>   3. C-s
>   4. mouse-2 [with cursor still over the original window, not in
>      minibuffer]
>
>> I see that the existing implementation of isearch-mouse-2
>> allows yanking the selection when clicked in the echo area,
>> but when clicked in the buffer it goes into infinite recursion,
>> because isearch-mouse-2 calls itself again.
>
> This is what I see as well, on current master.

The problem is that 'key-binding' in 'isearch-mouse-2'

  (let ((overriding-terminal-local-map nil))
    (key-binding (this-command-keys-vector) t))

still returns the keybinding from 'overriding-terminal-local-map'
that contains isearch keybindings.  Something is wrong here.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>   0. emacs -Q
>>   1. M-: (setq mouse-yank-at-point t) RET
>>   2. double click any word to mark it
>>   3. C-s
>>   4. mouse-2 [with cursor still over the original window, not in
>>      minibuffer]
>>
>>> I see that the existing implementation of isearch-mouse-2
>>> allows yanking the selection when clicked in the echo area,
>>> but when clicked in the buffer it goes into infinite recursion,
>>> because isearch-mouse-2 calls itself again.
>>
>> This is what I see as well, on current master.
>
> The problem is that 'key-binding' in 'isearch-mouse-2'
>
>   (let ((overriding-terminal-local-map nil))
>     (key-binding (this-command-keys-vector) t))
>
> still returns the keybinding from 'overriding-terminal-local-map'
> that contains isearch keybindings.  Something is wrong here.

I'm wholly unfamiliar with this code, but the following trivial patch
seems to do the trick?

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 168d71ada3..26db141781 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2629,9 +2629,10 @@ isearch-mouse-2
                        ;; Key search depends on mode (bug#47755)
                        (isearch-mode nil))
                    (key-binding (this-command-keys-vector) t))))
-    (if (and (window-minibuffer-p w)
-	     (not (minibuffer-window-active-p w))) ; in echo area
-	(isearch-yank-x-selection)
+    (if (or mouse-yank-at-point
+            (and (window-minibuffer-p w)
+	         (not (minibuffer-window-active-p w)))) ; in echo area
+        (isearch-yank-x-selection)
       (when (functionp binding)
 	(call-interactively binding)))))
 

Is this the wrong thing to do for some reason?  I mean, we don't care
about the value of binding in this case, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>> The problem is that 'key-binding' in 'isearch-mouse-2'
>>
>>   (let ((overriding-terminal-local-map nil))
>>     (key-binding (this-command-keys-vector) t))
>>
>> still returns the keybinding from 'overriding-terminal-local-map'
>> that contains isearch keybindings.  Something is wrong here.
>
> I'm wholly unfamiliar with this code, but the following trivial patch
> seems to do the trick?
>
> diff --git a/lisp/isearch.el b/lisp/isearch.el
> index 168d71ada3..26db141781 100644
> --- a/lisp/isearch.el
> +++ b/lisp/isearch.el
> @@ -2629,9 +2629,10 @@ isearch-mouse-2
>                         ;; Key search depends on mode (bug#47755)
>                         (isearch-mode nil))
>                     (key-binding (this-command-keys-vector) t))))
> -    (if (and (window-minibuffer-p w)
> -	     (not (minibuffer-window-active-p w))) ; in echo area
> -	(isearch-yank-x-selection)
> +    (if (or mouse-yank-at-point
> +            (and (window-minibuffer-p w)
> +	         (not (minibuffer-window-active-p w)))) ; in echo area
> +        (isearch-yank-x-selection)
>        (when (functionp binding)
>  	(call-interactively binding)))))
>
> Is this the wrong thing to do for some reason?  I mean, we don't care
> about the value of binding in this case, I think?

I don't understand how this fixes the problem above.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I don't understand how this fixes the problem above.

The test case is to double-click a word, `C-s' and then `mouse-2' to
insert it.  With the patch, that's what happens.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>> I don't understand how this fixes the problem above.
>
> The test case is to double-click a word, `C-s' and then `mouse-2' to
> insert it.  With the patch, that's what happens.

But only when mouse-yank-at-point is non-nil?  I still don't understand
why allowing to yank by clicking anywhere in the buffer
should depend on mouse-yank-at-point?  It allows yanking at point,
but in isearch it yanks to the search string in the echo area.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> The test case is to double-click a word, `C-s' and then `mouse-2' to
>> insert it.  With the patch, that's what happens.
>
> But only when mouse-yank-at-point is non-nil?

Yes.

> I still don't understand why allowing to yank by clicking anywhere in
> the buffer should depend on mouse-yank-at-point?  It allows yanking at
> point, but in isearch it yanks to the search string in the echo area.

When doing isearch, for the user it looks like point is down there --
that's where the input is apparently going, after all.  So giving the
yank result to isearch instead of inserting it where the mouse pointer
is is consistent and expected behaviour.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>>> The test case is to double-click a word, `C-s' and then `mouse-2' to
>>> insert it.  With the patch, that's what happens.
>>
>> But only when mouse-yank-at-point is non-nil?
>
> Yes.
>
>> I still don't understand why allowing to yank by clicking anywhere in
>> the buffer should depend on mouse-yank-at-point?  It allows yanking at
>> point, but in isearch it yanks to the search string in the echo area.
>
> When doing isearch, for the user it looks like point is down there --
> that's where the input is apparently going, after all.  So giving the
> yank result to isearch instead of inserting it where the mouse pointer
> is is consistent and expected behaviour.

I have no preference about whether clicking on the buffer should yank
to the search string.  Maybe some users expect that it should exit Isearch?
But in any case I think it should not depend on mouse-yank-at-point.
So maybe we could just remove this condition altogether to allow
isearch yanking by clicking anywhere?

-    (if (and (window-minibuffer-p w)
-             (not (minibuffer-window-active-p w))) ; in echo area
         (isearch-yank-x-selection)

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I have no preference about whether clicking on the buffer should yank
> to the search string.  Maybe some users expect that it should exit Isearch?
> But in any case I think it should not depend on mouse-yank-at-point.

But that's what mouse-yank-at-point controls in other contexts --
whether the paste is going where the mouse cursor is, or whether it's
going where you're typing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>> I have no preference about whether clicking on the buffer should yank
>> to the search string.  Maybe some users expect that it should exit Isearch?
>> But in any case I think it should not depend on mouse-yank-at-point.
>
> But that's what mouse-yank-at-point controls in other contexts --
> whether the paste is going where the mouse cursor is, or whether it's
> going where you're typing.

How this is related to deciding whether clicking anywhere in the buffer
should paste to the echo area with the search message?

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Drew Adams]

Caveat: I'm not following this thread.
___

I'll just mention that in `isearch+.el' I redefine
`isearch-mouse-2' (bound to `mouse-2' in Isearch)
so that it respects option `isearchp-mouse-2-flag':

 If `isearchp-mouse-2-flag' is non-nil, yank the X selection.
 If `isearchp-mouse-2-flag' is nil, yank it only if the
 `mouse-2' click is in the echo area.  Otherwise, invoke
 whatever `mouse-2' is bound to outside of Isearch.

I think this handles OP's use case (yanks selection to
Isearch string), but I could be wrong.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> How this is related to deciding whether clicking anywhere in the buffer
> should paste to the echo area with the search message?

Because you're "typing" down there -- at least that's what it looks like
to the user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>> How this is related to deciding whether clicking anywhere in the buffer
>> should paste to the echo area with the search message?
>
> Because you're "typing" down there -- at least that's what it looks like
> to the user.

But the cursor remains in the buffer.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Because you're "typing" down there -- at least that's what it looks like
>> to the user.
>
> But the cursor remains in the buffer.

Technically, yes, but in any way that makes any user interface difference.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Because you're "typing" down there -- at least that's what it looks like
>> to the user.
>
> But the cursor remains in the buffer.

Technically, yes, but not in any way that makes any user interface
difference.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>>> Because you're "typing" down there -- at least that's what it looks like
>>> to the user.
>>
>> But the cursor remains in the buffer.
>
> Technically, yes, but in any way that makes any user interface difference.
>
> Technically, yes, but not in any way that makes any user interface difference.

Is this a Schrödinger's answer? ;-P

Anyway, I see no reasonable way to explain why mouse-yank-at-point
would affect what currently is documented as:

  Clicking ‘mouse-2’ in the echo area appends the current X
  selection to the search string (‘isearch-yank-x-selection’).

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Technically, yes, but in any way that makes any user interface difference.
>>
>> Technically, yes, but not in any way that makes any user interface difference.
>
> Is this a Schrödinger's answer? ;-P

Tried to stop Emacs while it was sending the first version, but it
didn't work.  :-/

> Anyway, I see no reasonable way to explain why mouse-yank-at-point
> would affect what currently is documented as:
>
>   Clicking ‘mouse-2’ in the echo area appends the current X
>   selection to the search string (‘isearch-yank-x-selection’).

I don't understand why?

But since you're so dead set against this (for reasons I don't
understand), what about introducing a new user option like
`isearch-mouse-yank-append' or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Drew Adams]

> what about introducing a new user option like
> `isearch-mouse-yank-append' or something?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7787#90
_____________


 isearchp-mouse-2-flag is a variable defined in `isearch+.el'.

 Its value is t

 Documentation:

 Non-nil means clicking `mouse-2' during Isearch yanks the selection.
 In that case, you can select text with the mouse, then hit `C-s' to
 search for it.

 If the value is nil, yank only if the `mouse-2' click is in the echo
 area.  If not in the echo area, invoke whatever `mouse-2' is bound to
 outside of Isearch.

 You can customize this variable.
______________

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Juri Linkov]

>> Anyway, I see no reasonable way to explain why mouse-yank-at-point
>> would affect what currently is documented as:
>>
>>   Clicking ‘mouse-2’ in the echo area appends the current X
>>   selection to the search string (‘isearch-yank-x-selection’).
>
> I don't understand why?
>
> But since you're so dead set against this (for reasons I don't
> understand), what about introducing a new user option like
> `isearch-mouse-yank-append' or something?

I'm not against reusing an existing option, I just can't
connect the dots between the logic of mouse-yank-at-point
and yanking from anywhere in the buffer.  But if OP would confirm
that customizing mouse-yank-at-point is indeed what is expected
then maybe this would be fine to be able to close this request?
Otherwise, a new user option or even a new command would be fine.

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I'm not against reusing an existing option, I just can't
> connect the dots between the logic of mouse-yank-at-point
> and yanking from anywhere in the buffer.  But if OP would confirm
> that customizing mouse-yank-at-point is indeed what is expected
> then maybe this would be fine to be able to close this request?
> Otherwise, a new user option or even a new command would be fine.

I've now made this change in Emacs 29.  If it turns out to be too
surprising, or people want more configurability (for instance, they
don't want the mouse-yank-at-point action in general, but only in
isearch), then we can introduce a new user option.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Robert Pluim]

>>>>> On Wed, 27 Apr 2022 14:04:04 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Juri Linkov <juri@linkov.net> writes:
    >> I'm not against reusing an existing option, I just can't
    >> connect the dots between the logic of mouse-yank-at-point
    >> and yanking from anywhere in the buffer.  But if OP would confirm
    >> that customizing mouse-yank-at-point is indeed what is expected
    >> then maybe this would be fine to be able to close this request?
    >> Otherwise, a new user option or even a new command would be fine.

    Lars> I've now made this change in Emacs 29.  If it turns out to be too
    Lars> surprising, or people want more configurability (for instance, they
    Lars> don't want the mouse-yank-at-point action in general, but only in
    Lars> isearch), then we can introduce a new user option.

It makes sense to me from a theoretical and consistency standpoint,
although Iʼm not sure how often it would affect my workflow 🙂. Letʼs
see what the feedback is once people have had a chance to use it.

Robert
-- 

bug#7787: 23.2; wrong meaning for mouse-2 while in search mode

[Drew Adams]

> > I'm not against reusing an existing option, I just can't
> > connect the dots between the logic of mouse-yank-at-point
> > and yanking from anywhere in the buffer.  But if OP would confirm
> > that customizing mouse-yank-at-point is indeed what is expected
> > then maybe this would be fine to be able to close this request?
> > Otherwise, a new user option or even a new command would be fine.
> 
> I've now made this change in Emacs 29.  If it turns out to be too
> surprising, or people want more configurability (for instance, they
> don't want the mouse-yank-at-point action in general, but only in
> isearch), then we can introduce a new user option.

Too bad.  As I understand it, the point of this
feature (which dates from XEmacs, IIRC), is to
provide an (optional) Isearch-specific behavior
for mouse-2 yanking to the search string.

IIUC what Juri has been saying, I too think that
`mouse-yank-at-point' is an inappropriate way to
control (what should be) this Isearch-specific
behavior.

Nothing at all suggests, let alone implies, that
someone who wants this Isearch behavior also wants
non-nil `mouse-yank-at-point' behavior everywhere.
___

You say, "If it turns out to be too surprising".

That's unlikely, as this is opt-in, and its more
likely that few people use this optional behavior
or are even aware of it.  More likely is that
only people who already use `mouse-yank-at-point'
non-nil will discover that it yanks to the search
string.  Whether they will like that or not I
can't guess, and I don't really care.  (At least
the original behavior is still available with
isearch+.el.)