all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
@ 2011-01-05  6:05 Perry Wagle
  2020-01-15 19:24 ` Stefan Kangas
  0 siblings, 1 reply; 30+ messages in thread
From: Perry Wagle @ 2011-01-05  6:05 UTC (permalink / raw)
  To: 7787

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)





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2011-01-05  6:05 bug#7787: 23.2; wrong meaning for mouse-2 while in search mode Perry Wagle
@ 2020-01-15 19:24 ` Stefan Kangas
  2020-01-15 20:03   ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Kangas @ 2020-01-15 19:24 UTC (permalink / raw)
  To: Perry Wagle; +Cc: 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-01-15 19:24 ` Stefan Kangas
@ 2020-01-15 20:03   ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2020-01-15 20:14     ` Stefan Kangas
  0 siblings, 1 reply; 30+ messages in thread
From: Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-01-15 20:03 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 7787

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






^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-01-15 20:03   ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2020-01-15 20:14     ` Stefan Kangas
  2020-01-15 21:06       ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Kangas @ 2020-01-15 20:14 UTC (permalink / raw)
  To: Perry Wagle; +Cc: 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-01-15 20:14     ` Stefan Kangas
@ 2020-01-15 21:06       ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
       [not found]         ` <871rry3g2g.fsf@marxist.se>
  0 siblings, 1 reply; 30+ messages in thread
From: Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-01-15 21:06 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 7787

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






^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
       [not found]                 ` <20FA9FFB-A13D-4814-BB47-75F1CF1B9519@mac.com>
@ 2020-01-20  0:07                   ` Juri Linkov
  2020-01-20  3:26                     ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2020-01-20  0:07 UTC (permalink / raw)
  To: 7787; +Cc: wagle, stefan

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-01-20  0:07                   ` Juri Linkov
@ 2020-01-20  3:26                     ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 30+ messages in thread
From: Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2020-01-20  3:26 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 7787, stefan

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?






^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
       [not found]             ` <87v9pa1wyr.fsf@marxist.se>
       [not found]               ` <9FEB6215-55A1-443E-A5E8-330937AA4000@mac.com>
@ 2020-01-29  0:05               ` Juri Linkov
  2020-08-12 21:50                 ` Stefan Kangas
  1 sibling, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2020-01-29  0:05 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-01-29  0:05               ` Juri Linkov
@ 2020-08-12 21:50                 ` Stefan Kangas
  2020-08-12 23:53                   ` Juri Linkov
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Kangas @ 2020-08-12 21:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-08-12 21:50                 ` Stefan Kangas
@ 2020-08-12 23:53                   ` Juri Linkov
  2022-04-17 12:37                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2020-08-12 23:53 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2020-08-12 23:53                   ` Juri Linkov
@ 2022-04-17 12:37                     ` Lars Ingebrigtsen
  2022-04-18 19:12                       ` Juri Linkov
  0 siblings, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-17 12:37 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Perry Wagle, 7787, Stefan Kangas

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





^ permalink raw reply related	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-17 12:37                     ` Lars Ingebrigtsen
@ 2022-04-18 19:12                       ` Juri Linkov
  2022-04-18 19:20                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2022-04-18 19:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Perry Wagle, 7787, Stefan Kangas

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-18 19:12                       ` Juri Linkov
@ 2022-04-18 19:20                         ` Lars Ingebrigtsen
  2022-04-20  7:39                           ` Juri Linkov
  0 siblings, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-18 19:20 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Perry Wagle, 7787, Stefan Kangas

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-18 19:20                         ` Lars Ingebrigtsen
@ 2022-04-20  7:39                           ` Juri Linkov
  2022-04-20 10:55                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2022-04-20  7:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-20  7:39                           ` Juri Linkov
@ 2022-04-20 10:55                             ` Lars Ingebrigtsen
  2022-04-20 17:16                               ` Juri Linkov
  0 siblings, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-20 10:55 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-20 10:55                             ` Lars Ingebrigtsen
@ 2022-04-20 17:16                               ` Juri Linkov
  2022-04-21 11:35                                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2022-04-20 17:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-20 17:16                               ` Juri Linkov
@ 2022-04-21 11:35                                 ` Lars Ingebrigtsen
  2022-04-21 16:01                                   ` Juri Linkov
  0 siblings, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-21 11:35 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-21 11:35                                 ` Lars Ingebrigtsen
@ 2022-04-21 16:01                                   ` Juri Linkov
  2022-04-21 18:14                                     ` Drew Adams
  2022-04-22 11:36                                     ` Lars Ingebrigtsen
  0 siblings, 2 replies; 30+ messages in thread
From: Juri Linkov @ 2022-04-21 16:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-21 16:01                                   ` Juri Linkov
@ 2022-04-21 18:14                                     ` Drew Adams
  2022-04-22 11:36                                     ` Lars Ingebrigtsen
  1 sibling, 0 replies; 30+ messages in thread
From: Drew Adams @ 2022-04-21 18:14 UTC (permalink / raw)
  To: Juri Linkov, Lars Ingebrigtsen
  Cc: Perry Wagle, 7787@debbugs.gnu.org, Stefan Kangas

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.






^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-21 16:01                                   ` Juri Linkov
  2022-04-21 18:14                                     ` Drew Adams
@ 2022-04-22 11:36                                     ` Lars Ingebrigtsen
  2022-04-24 15:49                                       ` Juri Linkov
  1 sibling, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-22 11:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-22 11:36                                     ` Lars Ingebrigtsen
@ 2022-04-24 15:49                                       ` Juri Linkov
  2022-04-24 15:59                                         ` Lars Ingebrigtsen
  2022-04-24 15:59                                         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 30+ messages in thread
From: Juri Linkov @ 2022-04-24 15:49 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-24 15:49                                       ` Juri Linkov
@ 2022-04-24 15:59                                         ` Lars Ingebrigtsen
  2022-04-24 15:59                                         ` Lars Ingebrigtsen
  1 sibling, 0 replies; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-24 15:59 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-24 15:49                                       ` Juri Linkov
  2022-04-24 15:59                                         ` Lars Ingebrigtsen
@ 2022-04-24 15:59                                         ` Lars Ingebrigtsen
  2022-04-25 15:38                                           ` Juri Linkov
  1 sibling, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-24 15:59 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-24 15:59                                         ` Lars Ingebrigtsen
@ 2022-04-25 15:38                                           ` Juri Linkov
  2022-04-26  9:46                                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2022-04-25 15:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-25 15:38                                           ` Juri Linkov
@ 2022-04-26  9:46                                             ` Lars Ingebrigtsen
  2022-04-26 15:29                                               ` Drew Adams
  2022-04-26 15:32                                               ` Juri Linkov
  0 siblings, 2 replies; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-26  9:46 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-26  9:46                                             ` Lars Ingebrigtsen
@ 2022-04-26 15:29                                               ` Drew Adams
  2022-04-26 15:32                                               ` Juri Linkov
  1 sibling, 0 replies; 30+ messages in thread
From: Drew Adams @ 2022-04-26 15:29 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Juri Linkov
  Cc: Perry Wagle, 7787@debbugs.gnu.org, Stefan Kangas

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-26  9:46                                             ` Lars Ingebrigtsen
  2022-04-26 15:29                                               ` Drew Adams
@ 2022-04-26 15:32                                               ` Juri Linkov
  2022-04-27 12:04                                                 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 30+ messages in thread
From: Juri Linkov @ 2022-04-26 15:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-26 15:32                                               ` Juri Linkov
@ 2022-04-27 12:04                                                 ` Lars Ingebrigtsen
  2022-04-27 12:21                                                   ` Robert Pluim
  2022-04-27 14:44                                                   ` Drew Adams
  0 siblings, 2 replies; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-27 12:04 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Kangas, Perry Wagle, 7787

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-27 12:04                                                 ` Lars Ingebrigtsen
@ 2022-04-27 12:21                                                   ` Robert Pluim
  2022-04-27 14:44                                                   ` Drew Adams
  1 sibling, 0 replies; 30+ messages in thread
From: Robert Pluim @ 2022-04-27 12:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Perry Wagle, 7787, Stefan Kangas, Juri Linkov

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





^ permalink raw reply	[flat|nested] 30+ messages in thread

* bug#7787: 23.2; wrong meaning for mouse-2 while in search mode
  2022-04-27 12:04                                                 ` Lars Ingebrigtsen
  2022-04-27 12:21                                                   ` Robert Pluim
@ 2022-04-27 14:44                                                   ` Drew Adams
  1 sibling, 0 replies; 30+ messages in thread
From: Drew Adams @ 2022-04-27 14:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Juri Linkov
  Cc: Perry Wagle, 7787@debbugs.gnu.org, Stefan Kangas

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






^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2022-04-27 14:44 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-05  6:05 bug#7787: 23.2; wrong meaning for mouse-2 while in search mode Perry Wagle
2020-01-15 19:24 ` Stefan Kangas
2020-01-15 20:03   ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-01-15 20:14     ` Stefan Kangas
2020-01-15 21:06       ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]         ` <871rry3g2g.fsf@marxist.se>
     [not found]           ` <64FCE389-3139-4011-B06A-F8C220CCDBC9@mac.com>
     [not found]             ` <87v9pa1wyr.fsf@marxist.se>
     [not found]               ` <9FEB6215-55A1-443E-A5E8-330937AA4000@mac.com>
     [not found]                 ` <20FA9FFB-A13D-4814-BB47-75F1CF1B9519@mac.com>
2020-01-20  0:07                   ` Juri Linkov
2020-01-20  3:26                     ` Perry Wagle via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-01-29  0:05               ` Juri Linkov
2020-08-12 21:50                 ` Stefan Kangas
2020-08-12 23:53                   ` Juri Linkov
2022-04-17 12:37                     ` Lars Ingebrigtsen
2022-04-18 19:12                       ` Juri Linkov
2022-04-18 19:20                         ` Lars Ingebrigtsen
2022-04-20  7:39                           ` Juri Linkov
2022-04-20 10:55                             ` Lars Ingebrigtsen
2022-04-20 17:16                               ` Juri Linkov
2022-04-21 11:35                                 ` Lars Ingebrigtsen
2022-04-21 16:01                                   ` Juri Linkov
2022-04-21 18:14                                     ` Drew Adams
2022-04-22 11:36                                     ` Lars Ingebrigtsen
2022-04-24 15:49                                       ` Juri Linkov
2022-04-24 15:59                                         ` Lars Ingebrigtsen
2022-04-24 15:59                                         ` Lars Ingebrigtsen
2022-04-25 15:38                                           ` Juri Linkov
2022-04-26  9:46                                             ` Lars Ingebrigtsen
2022-04-26 15:29                                               ` Drew Adams
2022-04-26 15:32                                               ` Juri Linkov
2022-04-27 12:04                                                 ` Lars Ingebrigtsen
2022-04-27 12:21                                                   ` Robert Pluim
2022-04-27 14:44                                                   ` Drew Adams

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.