GNU bug report logs - #8421
23.3; Strange handling of mouse events in Nextstep/Cocoa port of Emacs23

Previous Next

Packages: ns, emacs;

Reported by: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>

Date: Mon, 4 Apr 2011 15:48:02 UTC

Severity: normal

Found in version 23.3

Done: Jan Djärv <jan.h.d <at> swipnet.se>

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 8421 in the body.
You can then email your comments to 8421 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8421; Package emacs. (Mon, 04 Apr 2011 15:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konrad Podczeck <konrad.podczeck <at> univie.ac.at>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 04 Apr 2011 15:48:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: bug-gnu-emacs <at> gnu.org
Cc: Reitter David <david.reitter <at> gmail.com>
Subject: 23.3;
	Strange handling of mouse events in Nextstep/Cocoa port of Emacs23
Date: Mon, 4 Apr 2011 16:46:20 +0200
I observe the following.

Start Emacs and then open two files one after the other, which makes them to appear in two separate frames, say A and B. Position the two frames so that they overlap, say so that the respective active frame covers half of the other frame. Let frame A be the active one and position the cursor so that on its line there is text to the left as well as to the right. Let me call this cursor position x. Now click into frame B to make it active, and the click again into frame A first at a place whose column is to the left of that of  x, and then a second time to a place whose column is to the the right of that of x. This yields an unintended selection in frame A.

This behaviour is annoying if one works with several frames at the same time. 



In GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
of 2011-03-10 on black.porkrind.org
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
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

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

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 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 owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8421; Package emacs,ns. (Sun, 14 Aug 2011 09:15:02 GMT) Full text and rfc822 format available.

Message #8 received at 8421 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
Cc: 8421 <at> debbugs.gnu.org
Subject: Re: bug#8421: 23.3; Strange handling of mouse events in Nextstep/Cocoa
	port of Emacs23
Date: Sun, 14 Aug 2011 11:13:02 +0200
Hello.

I can not reproduce this in Emacs 23.3 or the trunk.  Can you test the trunk? 
 Can you reproduce this when starting Emacs with -Q?

	Jan D.


Konrad Podczeck skrev 2011-04-04 16:46:
> I observe the following.
>
> Start Emacs and then open two files one after the other, which makes them to appear in two separate frames, say A and B. Position the two frames so that they overlap, say so that the respective active frame covers half of the other frame. Let frame A be the active one and position the cursor so that on its line there is text to the left as well as to the right. Let me call this cursor position x. Now click into frame B to make it active, and the click again into frame A first at a place whose column is to the left of that of  x, and then a second time to a place whose column is to the the right of that of x. This yields an unintended selection in frame A.
>
> This behaviour is annoying if one works with several frames at the same time.
>
>
>
> In GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
> of 2011-03-10 on black.porkrind.org
> 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
>    blink-cursor-mode: t
>    auto-encryption-mode: t
>    auto-compression-mode: t
>    line-number-mode: t
>    transient-mark-mode: t
>
> Recent input:
> <help-echo>  <help-echo>  <menu-bar>  <help-menu>  <se
> nd-emacs-bug-report>
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
>
> 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 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#8421; Package emacs,ns. (Tue, 18 Oct 2011 20:25:02 GMT) Full text and rfc822 format available.

Message #11 received at 8421 <at> debbugs.gnu.org (full text, mbox):

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 8421 <at> debbugs.gnu.org
Subject: Re: bug#8421: 23.3;
	Strange handling of mouse events in Nextstep/Cocoa port of Emacs23
Date: Tue, 18 Oct 2011 22:23:01 +0200
Hello Jan,

first, thanks for your response, and excuse my answer being late.

I still can reproduce the phenomena with the latest nightly build of Emacs24, downloaded from http://emacsformacosx.com/builds on October 18.

Here the steps in more detail.

(1) Open Emacs from the finder.

(2) Via Apple-O, open some file, say A, and have the cursor in row 1 and column 1.
 
(3) Via Apple-O, open another file, say B, and have the cursor in row 1 and column 1.

(4) Position the frame of B so that it has the same vertical coordinates on the screen as B, and horizontally overlaps the right half of the frame of A. The frame with B thus remains the active one, with the cursor position as given on (3).

(5) With mouse1, click on the frame of A at the cursor position there, so that the frame with A becomes active, then click somewhere on the visible part of the frame with B, but at vertical coordinate below row 1, so that, in particular, the frame with B becomes active again, and finally click somewhere in the frame with B, but at a vertical coordinate below that of the previous click and horizontal coordinate in the middle between column 1 and the horizontal coordinate of the previous click.

This gives me an unintended selection in the frame of B.

Starting Emacs from the command line with -Q, but otherwise proceeding the same way, gives the same.

With Emacs23, making a build by myself, I found something to make the phenomena to disappear:


I the file keyboard.c of the source code of Emacs23, lines 1495 to 1499 are:

 FOR_EACH_FRAME (tail, frame)
   {
     if (XFRAME (frame)->mouse_moved)
      	return XFRAME (frame); 
  }

I have inserted a new line of code before the closing brace so as to have:

 FOR_EACH_FRAME (tail, frame)
   {
     if (XFRAME (frame)->mouse_moved)
      	return XFRAME (frame); 
  return 0;
  }


Could this make any sense? I found it just by trial and error, and have no theoretical explanation. In any case, I worked with a Emacs23 build with this hack for several mounts now and didn't encounter any problem,

Thanks,

Konrad




Am 14.08.2011 um 11:13 schrieb Jan Djärv:

> Hello.
> 
> I can not reproduce this in Emacs 23.3 or the trunk.  Can you test the trunk?  Can you reproduce this when starting Emacs with -Q?
> 
> 	Jan D.
> 
> 
> Konrad Podczeck skrev 2011-04-04 16:46:
>> I observe the following.
>> 
>> Start Emacs and then open two files one after the other, which makes them to appear in two separate frames, say A and B. Position the two frames so that they overlap, say so that the respective active frame covers half of the other frame. Let frame A be the active one and position the cursor so that on its line there is text to the left as well as to the right. Let me call this cursor position x. Now click into frame B to make it active, and the click again into frame A first at a place whose column is to the left of that of  x, and then a second time to a place whose column is to the the right of that of x. This yields an unintended selection in frame A.
>> 
>> This behaviour is annoying if one works with several frames at the same time.
>> 
>> 
>> 
>> In GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
>> of 2011-03-10 on black.porkrind.org
>> 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
>>   blink-cursor-mode: t
>>   auto-encryption-mode: t
>>   auto-compression-mode: t
>>   line-number-mode: t
>>   transient-mark-mode: t
>> 
>> Recent input:
>> <help-echo>  <help-echo>  <menu-bar>  <help-menu>  <se
>> nd-emacs-bug-report>
>> 
>> Recent messages:
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> 
>> 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 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#8421; Package emacs,ns. (Sat, 22 Oct 2011 08:36:01 GMT) Full text and rfc822 format available.

Message #14 received at 8421 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
Cc: 8421 <at> debbugs.gnu.org
Subject: Re: bug#8421: 23.3;
	Strange handling of mouse events in Nextstep/Cocoa port of Emacs23
Date: Sat, 22 Oct 2011 10:33:50 +0200
Hello.

18 okt 2011 kl. 22:23 skrev Konrad Podczeck:

> Here the steps in more detail.
> 
> (1) Open Emacs from the finder.
> 
> (2) Via Apple-O, open some file, say A, and have the cursor in row 1 and column 1.
> 
> (3) Via Apple-O, open another file, say B, and have the cursor in row 1 and column 1.
> 
> (4) Position the frame of B so that it has the same vertical coordinates on the screen as B, and horizontally overlaps the right half of the frame of A. The frame with B thus remains the active one, with the cursor position as given on (3).
> 
> (5) With mouse1, click on the frame of A at the cursor position there, so that the frame with A becomes active, then click somewhere on the visible part of the frame with B, but at vertical coordinate below row 1, so that, in particular, the frame with B becomes active again, and finally click somewhere in the frame with B, but at a vertical coordinate below that of the previous click and horizontal coordinate in the middle between column 1 and the horizontal coordinate of the previous click.
> 
> This gives me an unintended selection in the frame of B.

Using this steps, I can now reproduce it, even in the trunk.

> 
> I the file keyboard.c of the source code of Emacs23, lines 1495 to 1499 are:
> 
> FOR_EACH_FRAME (tail, frame)
>   {
>     if (XFRAME (frame)->mouse_moved)
>      	return XFRAME (frame); 
>  }
> 
> I have inserted a new line of code before the closing brace so as to have:
> 
> FOR_EACH_FRAME (tail, frame)
>   {
>     if (XFRAME (frame)->mouse_moved)
>      	return XFRAME (frame); 
>  return 0;
>  }
> 
> 
> Could this make any sense? I found it just by trial and error, and have no theoretical explanation. In any case, I worked with a Emacs23 build with this hack for several mounts now and didn't encounter any problem,

As keyboard.c contains generic code and the problem does not show up on X11 for example, I do not think this is the right fix. The problem must be in the NS-specific code.

	Jan D.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#8421; Package emacs,ns. (Tue, 31 Dec 2013 18:33:02 GMT) Full text and rfc822 format available.

Message #17 received at 8421 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: "8421 <at> debbugs.gnu.org" <8421 <at> debbugs.gnu.org>
Subject: Unarchive
Date: Tue, 31 Dec 2013 19:31:58 +0100
unarchive 8421
quit





Reply sent to Jan Djärv <jan.h.d <at> swipnet.se>:
You have taken responsibility. (Tue, 31 Dec 2013 18:38:01 GMT) Full text and rfc822 format available.

Notification sent to Konrad Podczeck <konrad.podczeck <at> univie.ac.at>:
bug acknowledged by developer. (Tue, 31 Dec 2013 18:38:02 GMT) Full text and rfc822 format available.

Message #22 received at 8421-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
Cc: "8421-done <at> debbugs.gnu.org" <8421-done <at> debbugs.gnu.org>
Subject: Re: bug#8421: 23.3;
 Strange handling of mouse events in Nextstep/Cocoa port of Emacs23
Date: Tue, 31 Dec 2013 19:37:00 +0100
Hello.

This has been fixed in the trunk.

	Jan D.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 29 Jan 2014 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 10 years and 111 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.