GNU bug report logs -
#7787
23.2; wrong meaning for mouse-2 while in search mode
Previous Next
Reported by: Perry Wagle <wagle <at> mac.com>
Date: Wed, 5 Jan 2011 06:54:01 UTC
Severity: minor
Tags: confirmed, moreinfo
Found in versions 26.3, 23.2, 28.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7787 in the body.
You can then email your comments to 7787 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 05 Jan 2011 06:54:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Perry Wagle <wagle <at> mac.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 05 Jan 2011 06:54:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 15 Jan 2020 19:25:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Perry Wagle <wagle <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 15 Jan 2020 20:05:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 7787 <at> debbugs.gnu.org (full text, mbox):
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 <at> marxist.se> wrote:
>
> Perry Wagle <wagle <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 15 Jan 2020 20:15:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Perry Wagle <wagle <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 15 Jan 2020 21:07:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 7787 <at> debbugs.gnu.org (full text, mbox):
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 <at> marxist.se> wrote:
>
> Perry Wagle <wagle <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 17 Jan 2020 03:42:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Perry Wagle <wagle <at> mac.com> writes:
> I’m using Aquamacs, which worked, apparently until I just recently
> upgraded it, and it blew away a lot of my customizations.
Could you please elaborate? I'm a bit confused as to what you mean:
Does that mean that this is no longer an issue? Or that the issue was
resolved but has now resurfaced?
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 17 Jan 2020 04:02:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 7787 <at> debbugs.gnu.org (full text, mbox):
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.
— Perry
> On Jan 16, 2020, at 7:41 PM, Stefan Kangas <stefan <at> marxist.se> wrote:
>
> Perry Wagle <wagle <at> mac.com> writes:
>
>> I’m using Aquamacs, which worked, apparently until I just recently
>> upgraded it, and it blew away a lot of my customizations.
>
> Could you please elaborate? I'm a bit confused as to what you mean:
> Does that mean that this is no longer an issue? Or that the issue was
> resolved but has now resurfaced?
>
> Best regards,
> Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 17 Jan 2020 05:20:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 7787 <at> debbugs.gnu.org (full text, mbox):
found 7787 26.3
found 7787 28.0.50
thanks
Perry Wagle <wagle <at> mac.com> 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
bug Marked as found in versions 26.3.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Jan 2020 05:20:02 GMT)
Full text and
rfc822 format available.
bug Marked as found in versions 28.0.50.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Jan 2020 05:20:02 GMT)
Full text and
rfc822 format available.
Severity set to 'minor' from 'wishlist'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Jan 2020 05:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 17 Jan 2020 05:41:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 7787 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <stefan <at> marxist.se> wrote:
>
> found 7787 26.3
> found 7787 28.0.50
> thanks
>
> Perry Wagle <wagle <at> mac.com> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 17 Jan 2020 05:47:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 7787 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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))
> On Jan 16, 2020, at 9:40 PM, Perry Wagle <wagle <at> mac.com> wrote:
>
> 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 <stefan <at> marxist.se <mailto:stefan <at> marxist.se>> wrote:
>>
>> found 7787 26.3
>> found 7787 28.0.50
>> thanks
>>
>> Perry Wagle <wagle <at> mac.com <mailto:wagle <at> mac.com>> 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 <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
>
[Message part 2 (text/html, inline)]
Added tag(s) confirmed.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Sat, 18 Jan 2020 00:10:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 20 Jan 2020 00:43:01 GMT)
Full text and
rfc822 format available.
Message #43 received at submit <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 20 Jan 2020 00:43:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 20 Jan 2020 03:27:02 GMT)
Full text and
rfc822 format available.
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 20 Jan 2020 03:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 29 Jan 2020 00:28:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 7787 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 12 Aug 2020 21:51:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Thu, 13 Aug 2020 01:09:04 GMT)
Full text and
rfc822 format available.
Message #61 received at 7787 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Sun, 17 Apr 2022 12:38:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 17 Apr 2022 12:38:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 18 Apr 2022 19:14:03 GMT)
Full text and
rfc822 format available.
Message #69 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 18 Apr 2022 19:21:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 20 Apr 2022 08:15:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 20 Apr 2022 10:56:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 20 Apr 2022 17:23:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>>> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Thu, 21 Apr 2022 11:36:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Thu, 21 Apr 2022 16:06:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Thu, 21 Apr 2022 18:16:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 7787 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Fri, 22 Apr 2022 11:37:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Sun, 24 Apr 2022 15:51:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Sun, 24 Apr 2022 16:00:04 GMT)
Full text and
rfc822 format available.
Message #99 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Sun, 24 Apr 2022 16:00:04 GMT)
Full text and
rfc822 format available.
Message #102 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Mon, 25 Apr 2022 15:46:03 GMT)
Full text and
rfc822 format available.
Message #105 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>>> 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’).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Tue, 26 Apr 2022 09:47:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Tue, 26 Apr 2022 15:30:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 7787 <at> debbugs.gnu.org (full text, mbox):
> 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.
______________
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Tue, 26 Apr 2022 15:54:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 27 Apr 2022 12:05:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 7787 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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 marked as fixed in version 29.1, send any further explanations to
7787 <at> debbugs.gnu.org and Perry Wagle <wagle <at> mac.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 27 Apr 2022 12:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 27 Apr 2022 12:22:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 7787 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 27 Apr 2022 14:04:04 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:
Lars> Juri Linkov <juri <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#7787
; Package
emacs
.
(Wed, 27 Apr 2022 14:45:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 7787 <at> debbugs.gnu.org (full text, mbox):
> > 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.)
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 26 May 2022 11:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 38 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.