bug#3792: 23.1.50; other-window misbehaving with C-tab keybinding

bug#3792: 23.1.50; other-window misbehaving with C-tab keybinding

[Ivan Andrus]

I only see this problem in the NextStep (Cocoa actually) version (i.e. not
X-windows) that I build from CVS.
I did the following:

nextstep/Emacs.app/Contents/MacOS/Emacs -q

(global-set-key [(control tab)] 'other-window)
C-x 2 ; to create a new window
C-tab ; switches to the other window, then back when I release tab.  If I
release control first then it does not change back to the other window.  It
should not switch back to the other window.



In GNU Emacs 23.1.50.2 (i386-apple-darwin9.7.0, NS apple-appkit-949.46)
 of 2009-07-06 on ivan-andruss-macbook-pro.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

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
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1>
s-w <down-mouse-1> <mouse-1> s-x C-g C-x b <return>
<down-mouse-1> <mouse-1> d <backspace> s-( s-( ( c
l <backspace> <backspace> g l o b a l - s e t - k e
y SPC " C - T a b " SPC ' o t h e r - w i n d o w )
C-j q <up> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> C-y C-d C-d C-d C-d
C-d C-d C-d C-e C-x C-e C-x 2 <C-tab> <C-tab> <C-tab>
<C-tab> <C-tab> <C-tab> <C-tab> <C-tab> <C-tab> <C-tab>
<C-tab> <C-tab> <C-tab> <C-tab> <down-mouse-1> <mouse-1>
<help-echo> <down-mouse-1> <mouse-1> s-x r e l <backspace>
<backspace> C-/ C-/ C-/ C-/ C-/ SPC C-/ C-/ <down>
<down> <return> <return> <return> <return> <escape>
x r e p o <tab> r <tab> <return>

Recent messages:
call-interactively: Attempt to delete the sole visible or iconified frame
kill-region: The mark is not set now, so there is no region
Quit
Entering debugger...
Back to top level.
Mark set
other-window
Undo! [6 times]
Redo!
Making completion list...

bug#3792: 23.1.50; other-window misbehaving with C-tab keybinding

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 10 Jul 2009 09:13:55 -0600, Ivan Andrus <IAndrus@omniture.com> said:

> I noticed that view-lossage shows two <C-tab> for every time I press
> it.  In nsterm.m it specifically checks for control-tab and
> references
> http://osdir.com/ml/editors.vim.mac/2007-10/msg00141.html
> Which in turn references
> https://bugzilla.mozilla.org/show_bug.cgi?id=374076#c12

> Which makes me think that in Mac OS 10.4 the control-tab keyDown
> event isn't sent, but in 10.5 it is.  Or at the very least in the
> latest version of 10.5 (I'm running 10.5.7) it sends a keyDown
> event.

FWIW, the latest release of my Carbon+AppKit port (*), which also uses
Cocoa for GUI stuff, has the problem that it doesn't recognize
Control-Tab on Mac OS X 10.4 and earlier.  And I'm planning to add the
following change to the next release:

*: http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00532.html

*** ../../emacs-22.3-appkit-1.4/src/macappkit.m	2009-06-27 13:49:25.000000000 +0900
--- macappkit.m	2009-07-10 10:54:02.000000000 +0900
*************** static EventRef peek_if_next_event_activ
*** 747,753 ****
  	if (!(mac_mapped_modifiers (modifiers, [event keyCode])
  	      & ~(mac_pass_command_to_system ? cmdKey : 0)
  	      & ~(mac_pass_control_to_system ? controlKey : 0))
! 	    && ([NSApp keyWindow] || (flags & NSCommandKeyMask)))
  	  goto OTHER;
  
  	characters = [event characters];
--- 747,764 ----
  	if (!(mac_mapped_modifiers (modifiers, [event keyCode])
  	      & ~(mac_pass_command_to_system ? cmdKey : 0)
  	      & ~(mac_pass_control_to_system ? controlKey : 0))
! 	    && ([NSApp keyWindow] || (flags & NSCommandKeyMask))
! #if MAC_OS_X_VERSION_MIN_REQUIRED < 1050
! 	    /* This is a workaround for the problem that Control-Tab
! 	       is not recognized on Mac OS X 10.4 and earlier.  */
! 	    && !(floor (NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4
! 		 && [[[NSApp keyWindow] firstResponder]
! 		      isMemberOfClass:[EmacsView class]]
! 		 && [event keyCode] == 0x30 /* kVK_Tab */
! 		 && ((flags & (NSControlKeyMask | NSCommandKeyMask))
! 		     == NSControlKeyMask))
! #endif
! 	    )
  	  goto OTHER;
  
  	characters = [event characters];

On Mac OS X 10.4 and earlier, the first responder object doesn't
receive the keyDown: message for Control-Tab.  But still NSApplication
and NSWindow objects can detect such NSKeyDown events via sendEvent:.

Processing key events at the timing of keyUp: gives a strange feeling
to the user because the command bound to the key is executed much
later than expected and auto-repeat does not work.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3792: marked as done (23.1.50; other-window misbehaving with C-tab keybinding)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]


Your message dated Thu, 23 Jul 2009 07:53:57 -0400
with message-id <188AF6D9-A3C9-4C84-BC7B-4A7E8E7E3F22@gmail.com>
and subject line Re: 23.1.50; other-window misbehaving with C-tab keybinding
has caused the Emacs bug report #3792,
regarding 23.1.50; other-window misbehaving with C-tab keybinding
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3792: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3792
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4996 bytes --]

From: Ivan Andrus <IAndrus@omniture.com>
To: "emacs-pretest-bug@gnu.org" <emacs-pretest-bug@gnu.org>
Subject: 23.1.50; other-window misbehaving with C-tab keybinding
Date: Wed, 8 Jul 2009 13:29:45 -0600
Message-ID: <C67A4FC9.8E9D9%iandrus@omniture.com>


I only see this problem in the NextStep (Cocoa actually) version (i.e. not
X-windows) that I build from CVS.
I did the following:

nextstep/Emacs.app/Contents/MacOS/Emacs -q

(global-set-key [(control tab)] 'other-window)
C-x 2 ; to create a new window
C-tab ; switches to the other window, then back when I release tab.  If I
release control first then it does not change back to the other window.  It
should not switch back to the other window.



In GNU Emacs 23.1.50.2 (i386-apple-darwin9.7.0, NS apple-appkit-949.46)
 of 2009-07-06 on ivan-andruss-macbook-pro.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

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
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1>
s-w <down-mouse-1> <mouse-1> s-x C-g C-x b <return>
<down-mouse-1> <mouse-1> d <backspace> s-( s-( ( c
l <backspace> <backspace> g l o b a l - s e t - k e
y SPC " C - T a b " SPC ' o t h e r - w i n d o w )
C-j q <up> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> C-y C-d C-d C-d C-d
C-d C-d C-d C-e C-x C-e C-x 2 <C-tab> <C-tab> <C-tab>
<C-tab> <C-tab> <C-tab> <C-tab> <C-tab> <C-tab> <C-tab>
<C-tab> <C-tab> <C-tab> <C-tab> <down-mouse-1> <mouse-1>
<help-echo> <down-mouse-1> <mouse-1> s-x r e l <backspace>
<backspace> C-/ C-/ C-/ C-/ C-/ SPC C-/ C-/ <down>
<down> <return> <return> <return> <return> <escape>
x r e p o <tab> r <tab> <return>

Recent messages:
call-interactively: Attempt to delete the sole visible or iconified frame
kill-region: The mark is not set now, so there is no region
Quit
Entering debugger...
Back to top level.
Mark set
other-window
Undo! [6 times]
Redo!
Making completion list...




[-- Attachment #3: Type: message/rfc822, Size: 2657 bytes --]

From: Adrian Robert <adrian.b.robert@gmail.com>
To: 3792-done@emacsbugs.donarmstrong.com
Cc: Ivan Andrus <IAndrus@omniture.com>
Subject: Re: 23.1.50; other-window misbehaving with C-tab keybinding
Date: Thu, 23 Jul 2009 07:53:57 -0400
Message-ID: <188AF6D9-A3C9-4C84-BC7B-4A7E8E7E3F22@gmail.com>

I checked in a fix to trunk and branch to simply not do the keyUp- 
detection on Leopard and above.  Tested on Tiger and Leopard.