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

From: Perry Wagle <[email-masked]>
Date: Thu, 16 Jan 2020 21:40:21 -0800

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

> On Jan 16, 2020, at 9:19 PM, Stefan Kangas <[email-masked]> wrote:
> 
> found 7787 26.3
> found 7787 28.0.50
> thanks
> 
> Perry Wagle <[email-masked]> writes:
> 
>> I have a Mac, so I use Aquamacs.  I have no idea how closely it tracks gnu emacs.
>> 
>> I upgraded Aquamacs a few weeks ago, and I don’t see a number of customizations I’ve made over the years.
>> 
>> Way back when, I made a customization to an .el file in the libraries that fixed the problem.  Since then, I am pretty sure I moved that customization to one of the zillions .emacs like files, but don’t see it anywhere.
>> 
>> The problem was that I wanted to double click on a word (variable name etc), start a search, and middle mouse to paste that word into the search-for buffer.  Instead, it overrides the search and just pastes at the cursor.
>> 
>> I tried to do what you asked in aquamacs, but it didn’t appear to do anything.
> 
> Thank you, that makes things clearer.
> 
> 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.
> 
> This problem seems to be specific to isearch, due to the way isearch
> works.  isearch leaves point in the current buffer while searching,
> which makes the yanked text go there instead of the input area even
> when mouse-yank-at-point is t.
> 
> Incidentally, there is currently a discussion about changing how
> isearch works in this regard.  I would assume, but don't know for
> certain, that such changes would also resolve this issue.
> 
> https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00388.html
> 
> Meanwhile, please send the changes you had to make to get this to
> work, should you happen to find them.  Maybe they will be necessary
> still, depending on the outcome of the above discussion.
> 
> Best regards,
> Stefan Kangas