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

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

[Ivan Andrus]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

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.

I have implemented what I think is a very simple fix (though it is probably not ideal).  It sets a flag if it recieves a C-tag keyDown, and if so does not send the corresponging keyUp.  I like this because then it works on keyDown like everything else if possible, but if not it should work on keyUp.  I don't have the facilities to test the latter assumption.

Also the patch almost certainly is less efficient than it could be.  For example it sets flags and code twice (I believe) to the same thing, but I'm not really familiar enough with the code to want to risk changing that (and it's only for the Cocoa port as well).  I believe it should be correct at least.

-Ivan Andrus

[-- Attachment #1.2: Type: text/html, Size: 1689 bytes --]

[-- Attachment #2: emacs.patch --]
[-- Type: application/octet-stream, Size: 1541 bytes --]

--- nsterm.m	06 Jul 2009 21:46:57 -0600	1.76
+++ nsterm.m	10 Jul 2009 09:11:20 -0600
@@ -218,6 +218,15
    Mode 0 is normal anti-aliasing, mode 1 is no anti-aliasing, and mode 2 is
    4-bit pixel-aligned anti-aliasing (the old QuickDraw standard). */
 extern void CGContextSetFontRenderingMode (CGContextRef cg, int v);
+
+/* This will tell us whether this particular version of OS X sends
+   keyDown events for control-tab.  Apparently some versions do and
+   some don't.  If they don't, then we have to emulate it by using
+   keyUp events instead, but if they do then we don't want to send
+   both.
+*/
+static BOOL ns_sends_control_tab_keydown = NO;
+
 #endif


@@ -4456,6 +4456,16 @@
   static NSMutableArray *nsEvArray;
   static BOOL firstTime = YES;

+#ifdef NS_IMPL_COCOA
+  /* I think these will get set again later, but we need them now
+     before ns_fake_keydown is changed. */
+  flags = [theEvent modifierFlags];
+  code = [theEvent keyCode];
+  if (!ns_fake_keydown && code == 0x30 && (flags & NSControlKeyMask) && !(flags & NSCommandKeyMask)) {
+    ns_sends_control_tab_keydown = YES;
+  }
+#endif
+
   NSTRACE (keyDown);

   /* Rhapsody and OS X give up and down events for the arrow keys */
@@ -4628,6 +4628,8 @@
    If it matches one of these, send it on to keyDown. */
 -(void)keyUp: (NSEvent *)theEvent
 {
+  if ( ns_sends_control_tab_keydown )  return;
+
   int flags = [theEvent modifierFlags];
   int code = [theEvent keyCode];
   if (code == 0x30 && (flags & NSControlKeyMask) && !(flags & NSCommandKeyMask))

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: #3792 - 23.1.50; other-window misbehaving with C-tab keybinding - Emacs bug report logs

[Harald Maier]

Ivan Andrus <IAndrus@omniture.com> writes:

> 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.
>
> I have implemented what I think is a very simple fix (though it is
> probably not ideal).  It sets a flag if it recieves a C-tag keyDown,
> and if so does not send the corresponging keyUp.  I like this because
> then it works on keyDown like everything else if possible, but if not
> it should work on keyUp.  I don't have the facilities to test the
> latter assumption.
>
> Also the patch almost certainly is less efficient than it could be.
> For example it sets flags and code twice (I believe) to the same
> thing, but I'm not really familiar enough with the code to want to
> risk changing that (and it's only for the Cocoa port as well).  I
> believe it should be correct at least.
>
> -Ivan Andrus

Works fine for me. Thanks!

Maybe you should resend the Patch. In line 3 at the end the two final
'@@' characters are missing.

IMHO, that workaround should be added to 23.1. In 2009-02-20 I too
reported the bug as #2402.

Harald

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...