bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

John Mastro
By default, the "command" key in MacOS is bound to "super". If I type
s-$, Emacs seems to wait for input that it never receives. Anything I
type afterward appears to be ignored, except `ESC ESC ESC', which gets
Emacs out of this state. However, even hitting `C-g' repeatedly does
not.

The issue seems to be related to the command key rather than to "super"
or to the command bound to the key. In my configuration, I map command
to meta, and the same problem happens when I use M-$ to `ispell-word'.

Using `M-$' with command as meta worked until relatively recently. It
would be great if it could be brought back or made to fail more
explicitly.

Please let me know if I can provide any additional information.

Thanks,

John

In GNU Emacs 27.0.50 (build 7, x86_64-apple-darwin17.5.0, NS
appkit-1561.40 Version 10.13.4 (Build 17E202))
 of 2018-05-10 built on nebula.local
Repository revision: eabb6f6c3ee75dac1a7510e80bdd3c2fcfbbbcb5
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.4

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
M-g C-g is undefined
Type C-x 1 to delete the help window, C-M-v to scroll help.


Configured using:
 'configure --with-xml2 --with-zlib --with-gnutls --with-imagemagick
 --without-pop --without-compress-install --with-ns 'LDFLAGS=-L
 /usr/local/opt/libxml2/lib' 'CFLAGS=-pipe -march=nocona -O2 -g3 -I
 /usr/local/opt/libxml2/include'
 PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig'

Configured features:
RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS THREADS

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
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 cl-extra ispell help-fns radix-tree
help-mode easymenu cl-loaddefs cl-lib time-date elec-pair 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 207650 11053)
 (symbols 48 20141 1)
 (miscs 40 46 233)
 (strings 32 30424 1816)
 (string-bytes 1 807306)
 (vectors 16 35684)
 (vector-slots 8 720328 18424)
 (floats 8 49 67)
 (intervals 56 260 0)
 (buffers 992 12))



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

Alan Third
On Thu, May 10, 2018 at 06:30:33PM -0700, John Mastro wrote:

> By default, the "command" key in MacOS is bound to "super". If I type
> s-$, Emacs seems to wait for input that it never receives. Anything I
> type afterward appears to be ignored, except `ESC ESC ESC', which gets
> Emacs out of this state. However, even hitting `C-g' repeatedly does
> not.
>
> The issue seems to be related to the command key rather than to "super"
> or to the command bound to the key. In my configuration, I map command
> to meta, and the same problem happens when I use M-$ to `ispell-word'.
>
> Using `M-$' with command as meta worked until relatively recently. It
> would be great if it could be brought back or made to fail more
> explicitly.

Hmm, what’s happening is that macOS is going into a screenshot mode.
You can see the shortcuts in system preferences ‐> keyboard ‐>
shortcuts. I don’t know why you’ve not seen this before as I think
it’s been the default in macOS for quite a while now.

I don’t know if we can over‐ride this, and I don’t know that we’d want
to.
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

Eli Zaretskii
> Date: Sun, 13 May 2018 11:28:10 +0100
> From: Alan Third <[hidden email]>
> Cc: [hidden email]
>
> On Thu, May 10, 2018 at 06:30:33PM -0700, John Mastro wrote:
> > By default, the "command" key in MacOS is bound to "super". If I type
> > s-$, Emacs seems to wait for input that it never receives. Anything I
> > type afterward appears to be ignored, except `ESC ESC ESC', which gets
> > Emacs out of this state. However, even hitting `C-g' repeatedly does
> > not.
> >
> > The issue seems to be related to the command key rather than to "super"
> > or to the command bound to the key. In my configuration, I map command
> > to meta, and the same problem happens when I use M-$ to `ispell-word'.
> >
> > Using `M-$' with command as meta worked until relatively recently. It
> > would be great if it could be brought back or made to fail more
> > explicitly.
>
> Hmm, what’s happening is that macOS is going into a screenshot mode.
> You can see the shortcuts in system preferences ‐> keyboard ‐>
> shortcuts. I don’t know why you’ve not seen this before as I think
> it’s been the default in macOS for quite a while now.
>
> I don’t know if we can over‐ride this, and I don’t know that we’d want
> to.

If this cannot (or shouldn't) be fixed, how about mentioning it in the
manual?



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

John Mastro
In reply to this post by Alan Third
Alan Third <[hidden email]> wrote:

>> By default, the "command" key in MacOS is bound to "super". If I type
>> s-$, Emacs seems to wait for input that it never receives. Anything I
>> type afterward appears to be ignored, except `ESC ESC ESC', which gets
>> Emacs out of this state. However, even hitting `C-g' repeatedly does
>> not.
>>
>> The issue seems to be related to the command key rather than to "super"
>> or to the command bound to the key. In my configuration, I map command
>> to meta, and the same problem happens when I use M-$ to `ispell-word'.
>>
>> Using `M-$' with command as meta worked until relatively recently. It
>> would be great if it could be brought back or made to fail more
>> explicitly.
>
> Hmm, what’s happening is that macOS is going into a screenshot mode.
> You can see the shortcuts in system preferences ‐> keyboard ‐>
> shortcuts. I don’t know why you’ve not seen this before as I think
> it’s been the default in macOS for quite a while now.
>
> I don’t know if we can over‐ride this, and I don’t know that we’d want
> to.

Wow, indeed, you're right.

I say "wow" because I was extremely sure I'd been using Command-$ (as
M-$) semi-regularly on MacOS for years. However, this morning I tried
this at several commits a ways back, and it's clear I was
mis-remembering or hallucinating or something :)

Thanks, and sorry for the noise

        John



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

Alan Third
In reply to this post by Eli Zaretskii
On Sun, May 13, 2018 at 06:08:07PM +0300, Eli Zaretskii wrote:

> > Date: Sun, 13 May 2018 11:28:10 +0100
> > From: Alan Third <[hidden email]>
> > Cc: [hidden email]
> >
> > Hmm, what’s happening is that macOS is going into a screenshot mode.
> > You can see the shortcuts in system preferences ‐> keyboard ‐>
> > shortcuts. I don’t know why you’ve not seen this before as I think
> > it’s been the default in macOS for quite a while now.
> >
> > I don’t know if we can over‐ride this, and I don’t know that we’d want
> > to.
>
> If this cannot (or shouldn't) be fixed, how about mentioning it in the
> manual?

There are a lot of default shortcuts, and they’re almost all
customisable. It might be worth adding some text about how changing
the behaviour of the modifier keys in Emacs doesn’t change their
effect in macOS.

But I think that bit of the manual, modifier keys (macOS), could do
with being rewritten. It’s slightly misleading and doesn’t mention the
ns-command-modifier variables at all.
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

Eli Zaretskii
> Date: Tue, 15 May 2018 19:52:21 +0100
> From: Alan Third <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> There are a lot of default shortcuts, and they’re almost all
> customisable. It might be worth adding some text about how changing
> the behaviour of the modifier keys in Emacs doesn’t change their
> effect in macOS.
>
> But I think that bit of the manual, modifier keys (macOS), could do
> with being rewritten. It’s slightly misleading and doesn’t mention the
> ns-command-modifier variables at all.

Patches welcome, thanks.



Reply | Threaded
Open this post in threaded view
|

bug#31415: 27.0.50; Strange behavior on Command-$ in MacOS

Alan Third
Eli Zaretskii <[hidden email]> writes:

>> But I think that bit of the manual, modifier keys (macOS), could do
>> with being rewritten. It’s slightly misleading and doesn’t mention the
>> ns-command-modifier variables at all.
>
> Patches welcome, thanks.

Mattias Engdegård updated this section of the manual as part of
bug#38296, so I'm closing this bug report.
--
Alan Third