* bug#6372: 24.0.50; C-mouse-1 activates region @ 2010-06-07 17:19 Drew Adams 2012-07-08 13:41 ` Chong Yidong ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Drew Adams @ 2010-06-07 17:19 UTC (permalink / raw) To: 6372 emacs -Q 1. Click C-mouse-1. The Buffer Menu opens. 2. Click mouse-1 outside the menu. The menu disappears, which is correct. But the region is activated, which is incorrect. Clicking mouse-1 here should simply set point, without activating the region. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-05-23 on G41R2F1 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include' ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2010-06-07 17:19 bug#6372: 24.0.50; C-mouse-1 activates region Drew Adams @ 2012-07-08 13:41 ` Chong Yidong 2012-07-08 17:18 ` Drew Adams 2012-07-08 15:00 ` Dmitry Gutov 2020-08-18 11:10 ` Stefan Kangas 2 siblings, 1 reply; 13+ messages in thread From: Chong Yidong @ 2012-07-08 13:41 UTC (permalink / raw) To: Drew Adams; +Cc: 6372 "Drew Adams" <drew.adams@oracle.com> writes: > 1. Click C-mouse-1. The Buffer Menu opens. > > 2. Click mouse-1 outside the menu. The menu disappears, which is > correct. > > But the region is activated, which is incorrect. Clicking mouse-1 here > should simply set point, without activating the region. FWIW, this is not reproducible on GNU/Linux. Maybe a Windows-only issue; can someone with access to Windows check if this still happens? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-07-08 13:41 ` Chong Yidong @ 2012-07-08 17:18 ` Drew Adams 2012-07-08 18:09 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-07-08 17:18 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 6372 > "Drew Adams" <drew.adams@oracle.com> writes: > > > 1. Click C-mouse-1. The Buffer Menu opens. > > > > 2. Click mouse-1 outside the menu. The menu disappears, which is > > correct. > > > > But the region is activated, which is incorrect. Clicking > > mouse-1 here should simply set point, without activating the region. > > FWIW, this is not reproducible on GNU/Linux. Maybe a Windows-only > issue; can someone with access to Windows check if this still happens? Yes, the bug is still there. I just checked in this build: In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600) of 2012-07-01 on MARVIN Bzr revision: 108826 yamaoka@jpl.org-20120702004841-kzatmydft6dct0ry Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2' emacs -Q `C-mouse-1' Move mouse outside the popped up menu, and so that some text is between the first click and the next. `mouse-1' The text between the first and second clicks is selected (active region). Thx. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-07-08 17:18 ` Drew Adams @ 2012-07-08 18:09 ` Eli Zaretskii 2012-07-09 4:37 ` Chong Yidong 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-07-08 18:09 UTC (permalink / raw) To: Drew Adams; +Cc: 6372, cyd > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sun, 8 Jul 2012 10:18:40 -0700 > Cc: 6372@debbugs.gnu.org > > > "Drew Adams" <drew.adams@oracle.com> writes: > > > > > 1. Click C-mouse-1. The Buffer Menu opens. > > > > > > 2. Click mouse-1 outside the menu. The menu disappears, which is > > > correct. > > > > > > But the region is activated, which is incorrect. Clicking > > > mouse-1 here should simply set point, without activating the region. > > > > FWIW, this is not reproducible on GNU/Linux. Maybe a Windows-only > > issue; can someone with access to Windows check if this still happens? > > Yes, the bug is still there. Indeed. After the recipe, "C-h l" shows this: <C-down-mouse-1> <drag-mouse-1> C-h l What do you see on GNU/Linux? Which toolkit(s) did you try it with? FWIW, in the MSDOS build the problem doesn't happen, and view-lossage shows just this: <C-down-mouse-1> C-h l Any clue where could drag-mouse-1 come from? I guess we don't discard some events that we should. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-07-08 18:09 ` Eli Zaretskii @ 2012-07-09 4:37 ` Chong Yidong 2012-07-21 11:42 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Chong Yidong @ 2012-07-09 4:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 6372 Eli Zaretskii <eliz@gnu.org> writes: > Indeed. After the recipe, "C-h l" shows this: > > <C-down-mouse-1> <drag-mouse-1> C-h l > > What do you see on GNU/Linux? Which toolkit(s) did you try it with? > > FWIW, in the MSDOS build the problem doesn't happen, and view-lossage > shows just this: > > <C-down-mouse-1> C-h l > > Any clue where could drag-mouse-1 come from? I guess we don't discard > some events that we should. On GNU/Linux (both GTK build and Lucid build) I see <C-down-mouse-1> C-h l ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-07-09 4:37 ` Chong Yidong @ 2012-07-21 11:42 ` Eli Zaretskii 2012-08-08 18:39 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-07-21 11:42 UTC (permalink / raw) To: Chong Yidong; +Cc: 6372 > From: Chong Yidong <cyd@gnu.org> > Cc: Drew Adams <drew.adams@oracle.com>, 6372@debbugs.gnu.org > Date: Mon, 09 Jul 2012 12:37:05 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Indeed. After the recipe, "C-h l" shows this: > > > > <C-down-mouse-1> <drag-mouse-1> C-h l > > > > What do you see on GNU/Linux? Which toolkit(s) did you try it with? > > > > FWIW, in the MSDOS build the problem doesn't happen, and view-lossage > > shows just this: > > > > <C-down-mouse-1> C-h l > > > > Any clue where could drag-mouse-1 come from? I guess we don't discard > > some events that we should. > > On GNU/Linux (both GTK build and Lucid build) I see > > <C-down-mouse-1> C-h l Thanks. I'm sorry, but it will take someone who knows more than I do about MS-Windows messages and their processing to fix this one. I describe my findings below in the hope that someone will pick up where I left off. We track mouse events during pop-up menu by sending the WM_EMACS_TRACKPOPUPMENU message to the Emacs message pump. This message is handled by w32_wnd_proc around line 3770 of w32fns.c. There, we call TrackPopupMenu, a Windows API that displays the menu and returns the user selection of menu items. After TrackPopupMenu returns, we remove any mouse events still in the message queue, by calling PeekMessage with appropriate arguments, and return the user selection to our caller, which is w32_menu_show. The user selection returned is zero when the user closes the menu without selecting any item, by clicking outside the menu. w32_menu_show then removes any mouse events in the Emacs event queue by calling discard_mouse_events. What happens in this case, and is the reason for the bug, is that somehow the mouse click event that pops down the menu is not delivered to Emacs until _after_ w32_menu_show returns. That click is not removed by PeekMessage mentioned above, and is not discarded by discard_mouse_events. It is read by w32_wnd_proc only after all of the above processing is complete, and any memory of the menu that was popped down is gone. So Emacs processes that mouse click as a normal event, oblivious to the fact that it actually happened as part of the menu. What I don't understand here is why that mouse click is not delivered when we call PeekMessage, so that it could be discarded. It's as if Windows withholds that message from being put into the Emacs message queue. Why is that, and what can we do to be able to peek at that click message as part of menu processing and discard it, is beyond me. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-07-21 11:42 ` Eli Zaretskii @ 2012-08-08 18:39 ` Drew Adams 2012-09-16 23:34 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-08-08 18:39 UTC (permalink / raw) To: 'Eli Zaretskii', 'Chong Yidong'; +Cc: 6372 ping. > From: Eli Zaretskii Sent: Saturday, July 21, 2012 4:42 AM > I'm sorry, but it will take someone who knows more than I do about > MS-Windows messages and their processing to fix this one. I describe > my findings below in the hope that someone will pick up where I left > off. > > We track mouse events during pop-up menu by sending the > WM_EMACS_TRACKPOPUPMENU message to the Emacs message pump. This > message is handled by w32_wnd_proc around line 3770 of w32fns.c. > There, we call TrackPopupMenu, a Windows API that displays the menu > and returns the user selection of menu items. After TrackPopupMenu > returns, we remove any mouse events still in the message queue, by > calling PeekMessage with appropriate arguments, and return the user > selection to our caller, which is w32_menu_show. The user selection > returned is zero when the user closes the menu without selecting any > item, by clicking outside the menu. w32_menu_show then removes any > mouse events in the Emacs event queue by calling discard_mouse_events. > > What happens in this case, and is the reason for the bug, is that > somehow the mouse click event that pops down the menu is not delivered > to Emacs until _after_ w32_menu_show returns. That click is not > removed by PeekMessage mentioned above, and is not discarded by > discard_mouse_events. It is read by w32_wnd_proc only after all of > the above processing is complete, and any memory of the menu that was > popped down is gone. So Emacs processes that mouse click as a normal > event, oblivious to the fact that it actually happened as part of the > menu. > > What I don't understand here is why that mouse click is not delivered > when we call PeekMessage, so that it could be discarded. It's as if > Windows withholds that message from being put into the Emacs message > queue. Why is that, and what can we do to be able to peek at that > click message as part of menu processing and discard it, is beyond me. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-08-08 18:39 ` Drew Adams @ 2012-09-16 23:34 ` Drew Adams 2012-10-19 15:02 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-09-16 23:34 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 6372 ping ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2012-09-16 23:34 ` Drew Adams @ 2012-10-19 15:02 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-10-19 15:02 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 6372 ping ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2010-06-07 17:19 bug#6372: 24.0.50; C-mouse-1 activates region Drew Adams 2012-07-08 13:41 ` Chong Yidong @ 2012-07-08 15:00 ` Dmitry Gutov 2020-08-18 11:10 ` Stefan Kangas 2 siblings, 0 replies; 13+ messages in thread From: Dmitry Gutov @ 2012-07-08 15:00 UTC (permalink / raw) To: cyd; +Cc: 6372 Chong Yidong <cyd@gnu.org> writes: > "Drew Adams" <drew.adams@oracle.com> writes: > >> 1. Click C-mouse-1. The Buffer Menu opens. >> >> 2. Click mouse-1 outside the menu. The menu disappears, which is >> correct. >> >> But the region is activated, which is incorrect. Clicking mouse-1 here >> should simply set point, without activating the region. > > FWIW, this is not reproducible on GNU/Linux. Maybe a Windows-only > issue; can someone with access to Windows check if this still happens? It does happen. And if I ctrl-click mouse-1 when the menu if open, minibuffer says "<C-drag-mouse-1> is undefined", so looks like doing mouse-1 click when the menu is open is registered as drag-mouse-1 event. (I tried it in Ubuntu on an older Emacs 24 build, and that didn't happen either). In GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601) of 2012-07-06. --Dmitry ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2010-06-07 17:19 bug#6372: 24.0.50; C-mouse-1 activates region Drew Adams 2012-07-08 13:41 ` Chong Yidong 2012-07-08 15:00 ` Dmitry Gutov @ 2020-08-18 11:10 ` Stefan Kangas 2020-08-18 12:11 ` Eli Zaretskii 2 siblings, 1 reply; 13+ messages in thread From: Stefan Kangas @ 2020-08-18 11:10 UTC (permalink / raw) To: Drew Adams; +Cc: 6372 "Drew Adams" <drew.adams@oracle.com> writes: > emacs -Q > > 1. Click C-mouse-1. The Buffer Menu opens. > > 2. Click mouse-1 outside the menu. The menu disappears, which is > correct. > > But the region is activated, which is incorrect. Clicking mouse-1 here > should simply set point, without activating the region. > > > In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) > of 2010-05-23 on G41R2F1 > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include' That was more than 10 years ago. I can't reproduce this on GNU/Linux, but from the discussion this looked like a Windows-specific bug. Since this was such a long time ago, I just wanted to ask if you (or anyone else) can still reproduce this? Thanks. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6372: 24.0.50; C-mouse-1 activates region 2020-08-18 11:10 ` Stefan Kangas @ 2020-08-18 12:11 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2020-08-18 12:11 UTC (permalink / raw) To: Stefan Kangas; +Cc: 6372 > From: Stefan Kangas <stefan@marxist.se> > Date: Tue, 18 Aug 2020 11:10:33 +0000 > Cc: 6372@debbugs.gnu.org > > > emacs -Q > > > > 1. Click C-mouse-1. The Buffer Menu opens. > > > > 2. Click mouse-1 outside the menu. The menu disappears, which is > > correct. > > > > But the region is activated, which is incorrect. Clicking mouse-1 here > > should simply set point, without activating the region. > > > > > > In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) > > of 2010-05-23 on G41R2F1 > > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > > configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include' > > That was more than 10 years ago. > > I can't reproduce this on GNU/Linux, but from the discussion this looked > like a Windows-specific bug. > > Since this was such a long time ago, I just wanted to ask if you (or > anyone else) can still reproduce this? Thanks. I still see it, yes. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <<B10C013621504F2293AC68C8CA31CA37@us.oracle.com>]
[parent not found: <<CADwFkmkK6JtAXf6aOf_ZNMiw0gKDuGJrV1p7qehk+0qe4V7U=Q@mail.gmail.com>]
[parent not found: <<83k0xwf92g.fsf@gnu.org>]
* bug#6372: 24.0.50; C-mouse-1 activates region [not found] ` <<83k0xwf92g.fsf@gnu.org> @ 2020-08-18 16:37 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2020-08-18 16:37 UTC (permalink / raw) To: Eli Zaretskii, Stefan Kangas; +Cc: 6372 > I still see it, yes. I do too. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-08-18 16:37 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-07 17:19 bug#6372: 24.0.50; C-mouse-1 activates region Drew Adams 2012-07-08 13:41 ` Chong Yidong 2012-07-08 17:18 ` Drew Adams 2012-07-08 18:09 ` Eli Zaretskii 2012-07-09 4:37 ` Chong Yidong 2012-07-21 11:42 ` Eli Zaretskii 2012-08-08 18:39 ` Drew Adams 2012-09-16 23:34 ` Drew Adams 2012-10-19 15:02 ` Drew Adams 2012-07-08 15:00 ` Dmitry Gutov 2020-08-18 11:10 ` Stefan Kangas 2020-08-18 12:11 ` Eli Zaretskii [not found] <<B10C013621504F2293AC68C8CA31CA37@us.oracle.com> [not found] ` <<CADwFkmkK6JtAXf6aOf_ZNMiw0gKDuGJrV1p7qehk+0qe4V7U=Q@mail.gmail.com> [not found] ` <<83k0xwf92g.fsf@gnu.org> 2020-08-18 16:37 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).