[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8421: 23.3; Strange handling of mouse events in Nextstep/Cocoa port
From: |
Konrad Podczeck |
Subject: |
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)
>>
>>
>
- bug#8421: 23.3; Strange handling of mouse events in Nextstep/Cocoa port of Emacs23,
Konrad Podczeck <=