GNU bug report logs - #3792
23.1.50; other-window misbehaving with C-tab keybinding

Previous Next

Packages: emacs, ns;

Reported by: Ivan Andrus <IAndrus <at> omniture.com>

Date: Wed, 8 Jul 2009 19:55:05 UTC

Severity: normal

Done: Adrian Robert <adrian.b.robert <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #15 received at 3792 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Ivan Andrus <IAndrus <at> omniture.com>, 3792 <at> debbugs.gnu.org
Subject: Re: bug#3792: 23.1.50; other-window misbehaving with C-tab keybinding
Date: Sat, 11 Jul 2009 16:44:47 +0900
>>>>> On Fri, 10 Jul 2009 09:13:55 -0600, Ivan Andrus <IAndrus <at> 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 <at> math.s.chiba-u.ac.jp



This bug report was last modified 15 years and 309 days ago.

Previous Next


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