4

I'm using the homebrew-emacsmacport version of Emacs on OSX 10.10 Yosemite. I've created an OSX shortcut to do something in iTunes, but when I'm in Emacs, this is captured and displays M-s-- is undefined (It's Command-Alt--). I understand that this is the correct behavior, but is it possible to have Emacs ignore this shortcut, so it can get to iTunes? Or is there some subset of keys that Emacs ignores generally?

Screenshot of the offending behavior

  • 1
    You are describing the exact opposite -- i.e., Emacs is ignoring a system shortcut. If Emacs is actually ignoring OSX system shortcuts (e.g., defined within System Preferences, Keyboard, Keyboard Shortcuts), then this is indeed new news to me. In that case, you may wish to consider writing an applescript that will be called within Emacs. Emacs has a do-applescript and there are other means of calling an applescript within Emacs, including start-process. – lawlist Jun 4 '15 at 22:10
  • @lawlist I'm not sure I entirely follow your comment, but to clarify, I'd like the shortcut to be available globally on my system. I've defined it in Keyboard Shortcuts, but it still gets captured by Emacs when Emacs is the active program. – abroekhof Jun 4 '15 at 23:12
5

With a few exceptions (e.g., hiding the OSX menu-bar with ns-auto-hide-menu-bar), Emacs does not alter basic system settings generally controlled by OSX (e.g., keyboard shortcuts defined within System Preferences / Keyboard / Keyboard Shortcuts). The original poster has implied that Emacs is receiving the keyboard input of Command+ALT+-, which Emacs responds to by displaying a message M-s-- is undefined. If the keyboard input had been hijacked by an OSX system keyboard shortcut for controlling iTunes, then Emacs would not have registered the input -- i.e., Emacs would have done nothing.

In a situation such as this, the original poster has two general options: (1) keep trying to define an OSX system keyboard shortcut that prevents Emacs from ever receiving the keystrokes [this is not done within Emacs, but rather at the OSX system level]; or, (2) write an applescript or other mechanism to control iTunes from with Emacs. [There are at least a couple of libraries already written for Emacs to control certain iTunes functions on OSX -- available by Googling.] Here is an example for opening Safari with an applescript from within Emacs:

(defun safari-activate ()
(interactive)
  (let ((script (concat
         "tell application \"Safari\"\n"
         "activate\n"
         "end tell")))
    (start-process "safari-activate" nil "osascript" "-e" script)))

The keyboard shortcut at issue is a little tricky because ALT+COMMAND+- on OSX is actually creating an EN DASH (i.e., , aka character code 8211) instead of a HYPHEN-MINUS (i.e., -, aka character code 45). The following example can be used to demonstrate whether an OSX system keyboard shortcut is intercepting the Emacs keyboard shortcut:

(global-set-key [(meta super ?–)] (lambda () (interactive) (message "Hello-world!")))

NOTE:  In the above example, we use an EN DASH to define the keyboard shortcut -- not a HYPHEN-MINUS. If an OSX system keyboard shortcut to control iTunes had been in effect, then Emacs would be silent instead of generating the message Hello-world!.

  • Isn't binding ignore to the key an option? – wasamasa Jun 5 '15 at 10:15
  • @wasamasa -- ignore is a function defined within subr.el -- (defun ignore (&rest _ignore) "Do nothing and return nil. This function accepts any number of arguments, but ignores them." (interactive) nil). Running the function ignore with an Emacs keyboard shortcut will not cause a system-wide keyboard shortcut on OSX to effectively pass-through Emacs and go to iTunes -- i.e., in one ear and out the other so to speak :) I suspect the problem stems from using a unique keyboard shortcut with an EN DASH on OSX -- the O.P. could try using a different shortcut to narrow it down. – lawlist Jun 5 '15 at 14:08
  • I'm asking this since I get similiar "errors" for hitting <XF86MonBrightnessUp> which makes my screen brighter and therefore passes through just fine, it's just Emacs that somehow catches wind of this and displays that message. Using (global-set-key (kbd "<XF86MonBrightnessUp>") 'ignore) gets rid of this warning and doesn't inhibit the functionality of the key, so I suppose this could be a case of the questioner not interpreting the results correctly (as it could appear not to work because he made a different error somewhere else). – wasamasa Jun 5 '15 at 14:29
  • @wasamasa, just tried that, but didn't fix the problem unfortunately. – abroekhof Jun 5 '15 at 15:57
  • @lawlist I'm still wondering if there is some group of keys that is generally ignored by Emacs? What would make Emacs capture something like M-s--, but not something else? – abroekhof Jun 5 '15 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.