bug#28215: 26.0.50; Option-Clover-H

bug#28215: 26.0.50; Option-Clover-H

[Devon Sean McCullough]

lisp/term/ns-win.el.gz
(define-key global-map [?\s-H] 'ns-do-hide-others) ; wrong

The Emacs menu correctly shows
	Hide Emacs	⌘H
	Hide Others	⌥⌘H
same as all MacOSX apps.  M-s-h is correct and mandatory
however typing M-s-h gets the message M-s-˙ is undefined
where that funny character is unicode 02D9 DOT ABOVE.

Workaround:
(define-key global-map [?\M-\s-h] 'ns-do-hide-others)
(define-key key-translation-map [?\M-\s-\u02D9] [?\M-\s-h])

		Peace
			--Devon

In GNU Emacs 26.0.50 (build 1, x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
 of 2017-06-07 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1404
Recent messages:
Warning: arch-dependent data dir ’/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/MacOS/libexec/’: No such file or directory

For information about GNU Emacs and the GNU system, type C-h C-a.
M-s-˙ is undefined
ns-do-hide-others is on s-H
s-h runs the command ns-do-hide-emacs
Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils thingatpt time-date
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 203813 9442)
 (symbols 48 19846 1)
 (miscs 40 70 162)
 (strings 32 18138 5143)
 (string-bytes 1 584978)
 (vectors 16 34889)
 (vector-slots 8 694800 5922)
 (floats 8 48 172)
 (intervals 56 205 0)
 (buffers 976 12))

bug#28215: 26.0.50; Option-Clover-H

[Alan Third]

On Thu, Aug 24, 2017 at 06:35:55PM +0800, Devon Sean McCullough wrote:
> lisp/term/ns-win.el.gz
> (define-key global-map [?\s-H] 'ns-do-hide-others) ; wrong
> 
> The Emacs menu correctly shows
> 	Hide Emacs	⌘H
> 	Hide Others	⌥⌘H
> same as all MacOSX apps.  M-s-h is correct and mandatory
> however typing M-s-h gets the message M-s-˙ is undefined
> where that funny character is unicode 02D9 DOT ABOVE.

I can confirm this occurs for me too.

It looks like the problem is at nsterm.m:6122. I don’t understand what
the point of that code is. It looks like it’s trying to work around
some problem with different keyboard layouts.
-- 
Alan Third

bug#28215: 26.0.50; Option-Clover-H

[Alan Third]

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

On Thu, Aug 24, 2017 at 08:34:47PM +0100, Alan Third wrote:
> It looks like the problem is at nsterm.m:6122. I don’t understand what
> the point of that code is. It looks like it’s trying to work around
> some problem with different keyboard layouts.

Attached is a patch that adds the M-s-h shortcut, and removes the code
that treats the super key as special.

If anyone can tell me why that code was there that would be great, but
it seems to work fine without it. It’s been there since the NS port
was merged into GNU Emacs, so I wonder if it’s required on some old
*step implementation.
-- 
Alan Third

[-- Attachment #2: 0001-Correct-hide-others-shortcut-on-macOS-bug-28215.patch --]
[-- Type: text/plain, Size: 3218 bytes --]

From 8fbe6096fcb4ca37185120bc629a55741c8e15f5 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Thu, 24 Aug 2017 21:08:16 +0100
Subject: [PATCH] Correct "hide others" shortcut on macOS (bug#28215)

* src/nsterm.m (EmacsView::keyDown): Remove code that forces system
keymap when pressing cmd (super) key.
* lisp/term/ns-win.el: Add new shortcut for ns-do-hide-others.
---
 lisp/term/ns-win.el |  1 +
 src/nsterm.m        | 36 +-----------------------------------
 2 files changed, 2 insertions(+), 35 deletions(-)

diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
index 8848360655..776add98af 100644
--- a/lisp/term/ns-win.el
+++ b/lisp/term/ns-win.el
@@ -124,6 +124,7 @@ global-map
 (define-key global-map [?\s-g] 'isearch-repeat-forward)
 (define-key global-map [?\s-h] 'ns-do-hide-emacs)
 (define-key global-map [?\s-H] 'ns-do-hide-others)
+(define-key global-map [?\M-\s-h] 'ns-do-hide-others)
 (define-key global-map [?\s-j] 'exchange-point-and-mark)
 (define-key global-map [?\s-k] 'kill-current-buffer)
 (define-key global-map [?\s-l] 'goto-line)
diff --git a/src/nsterm.m b/src/nsterm.m
index 22f8efd6b9..ccf7fd5238 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6106,41 +6106,7 @@ flag set (this is probably a bug in the OS).
            : ns_right_command_modifier);
 
       if (is_left_key)
-        {
-          emacs_event->modifiers |= parse_solitary_modifier
-            (ns_command_modifier);
-
-          /* if super (default), take input manager's word so things like
-             dvorak / qwerty layout work */
-          if (EQ (ns_command_modifier, Qsuper)
-              && !fnKeysym
-              && [[theEvent characters] length] != 0)
-            {
-              /* XXX: the code we get will be unshifted, so if we have
-                 a shift modifier, must convert ourselves */
-              if (!(flags & NSEventModifierFlagShift))
-                code = [[theEvent characters] characterAtIndex: 0];
-#if 0
-              /* this is ugly and also requires linking w/Carbon framework
-                 (for LMGetKbdType) so for now leave this rare (?) case
-                 undealt with.. in future look into CGEvent methods */
-              else
-                {
-                  long smv = GetScriptManagerVariable (smKeyScript);
-                  Handle uchrHandle = GetResource
-                    ('uchr', GetScriptVariable (smv, smScriptKeys));
-                  UInt32 dummy = 0;
-                  UCKeyTranslate ((UCKeyboardLayout *) *uchrHandle,
-                                 [[theEvent characters] characterAtIndex: 0],
-                                 kUCKeyActionDisplay,
-                                 (flags & ~NSEventModifierFlagCommand) >> 8,
-                                 LMGetKbdType (), kUCKeyTranslateNoDeadKeysMask,
-                                 &dummy, 1, &dummy, &code);
-                  code &= 0xFF;
-                }
-#endif
-            }
-        }
+        emacs_event->modifiers |= parse_solitary_modifier (ns_command_modifier);
 
       is_right_key = (flags & NSRightControlKeyMask) == NSRightControlKeyMask;
       is_left_key = (flags & NSLeftControlKeyMask) == NSLeftControlKeyMask
-- 
2.12.0

bug#28215: 26.0.50; Option-Clover-H

[Devon Sean McCullough]

> On Aug 25, 2017, at 4:24 AM, Alan Third <alan@idiocy.org> wrote:
> 
> On Thu, Aug 24, 2017 at 08:34:47PM +0100, Alan Third wrote:
>> It looks like the problem is at nsterm.m:6122. I don’t understand what
>> the point of that code is. It looks like it’s trying to work around
>> some problem with different keyboard layouts.
> 
> Attached is a patch that adds the M-s-h shortcut, and removes the code
> that treats the super key as special.
> 
> If anyone can tell me why that code was there that would be great, but
> it seems to work fine without it. It’s been there since the NS port
> was merged into GNU Emacs, so I wonder if it’s required on some old
> *step implementation.

Could it be trying to support
Apple > System Preferences... > Keyboard > Input Sources > + > English > DQ Dvorak - Qwerty ⌘
which IIRC is a Dvorak layout but with Qwerty Command-keychords
already ingrained in Mac users' muscle memory?

	Peace
		—Devon

P.S. DV Dvorak layout vs. DQ Dvorak - Qwerty ⌘ layout
     Apple key labels -> Emacs 26.0.50 events

	Dvorak	Qwerty	DV	DQ
	H	J	h	h
	D	H	d	d
	⌘H	⌘J	s-h	s-j
	⇧⌘H	⇧⌘J	s-H	s-H
	⌥⌘H	⌥⌘J	M-s-˙	M-s-∆
	⌘D	⌘H	s-d	s-h
	⇧⌘D	⇧⌘H	s-D	s-D
	⌥⌘D	⌥⌘H	M-s-∂	M-s-˙

    Special characters in all layouts per Keyboard Viewer or (setq ns-option-modifier 'none)
	Key Chord	Character	Unicode Name
	Option-D	∂       	PARTIAL DIFFERENTIAL
	Option-H	˙       	DOT ABOVE 
	Option-J	∆       	INCREMENT

P.P.S. /System/Library/Input Methods/KeyboardViewer.app shows keyboard layout, tracking input source & bucky bit state
in real time.  Turns out there are eight different Option layouts, one for each Control/Shift/Command combination.
Perhaps C-q quoted-insert should access these MacOSX alternate layouts by binding ns-option-modifier to none for NS,
similarly current-input-mode/set-input-mode for tty input and finally insert the next input key sans bucky bits.

bug#28215: 26.0.50; Option-Clover-H

[Alan Third]

On Fri, Aug 25, 2017 at 04:52:57PM +0800, Devon Sean McCullough wrote:
> Could it be trying to support
> Apple > System Preferences... > Keyboard > Input Sources > + > English > DQ Dvorak - Qwerty ⌘
> which IIRC is a Dvorak layout but with Qwerty Command-keychords
> already ingrained in Mac users' muscle memory?

This makes sense. It’s also possible that Emacs users will be relying
on the (IMO) slightly strange current behaviour, so changing it could
be a problem.

I’ll add in your changes as they are. Have you contributed anything to
Emacs before?
-- 
Alan Third