Somehow the emacs I'm using doesn't treat Alt as Meta. It only uses ESC for it. If I press Alt+x it will tell me "A-X" undefined. I tried to figure out how to map it to meta but got no luck on the web because in most of results from my search people take Alt as Meta by default. I guess something like this should work:
global-set-key Alt(?) 'meta
but I'm not sure how to represent Alt in lisp.. any help? Thanks!
Most solutions will tell you to change keymap at the X11 level. The wiki suffers from the problem of too much information. If you just want a solution that works only at the emacs level (quite useful for VNC/remote desktop), then add the below line to your emacs init file
;; Map Alt key to Meta
(setq x-alt-keysym 'meta)
I had the same problem and by putting this in ~/.emacs helped me.
(set-keyboard-coding-system nil)
Refer to this, if you need more help
http://www.emacswiki.org/emacs/MetaKeyProblems#toc15
Entering this command in a shell (even M-x shell) works for me.
xmodmap -e "clear mod4"
This works when the problem is that the output of xmodmap includes a line showing that Meta_L is set to mod4:
mod4 Meta_L (0x73)
Emacs thinks your keyboard has a Meta key, so it's not interpreting Alt as Meta. The above command tells X that you don't have a Meta key, so Emacs will interpret Alt the way that we're used to.
I learned this from https://www.emacswiki.org/emacs/MetaKeyProblems.
Related
In org-mode, pressing M-S-RET (meta-shift-return) will create a new TODO on a new line. This key sequence sends M-RET to emacs through my terminal. I've checked this with C-h c ESC-S-RET, which returns M-RET is undefined in the mini-buffer.
I'm using Snow Leopard with Emacs 23.2.1 running in Terminal.app. There is no option to define a RET sequence in the terminal keyboard preferences.
Any idea what's causing the missing SHIFT? Workarounds?
You can get Emacs to pretend that it got S-RET with C-x # S RET (note uppercase S).
This also works for adding control, meta, alt, hyper or super modifiers; type C-x # C-h for the list of bindings. The Modifier Keys section in the Emacs manual mentions this as well.
In general, lots of keystrokes are simply impossible to send via a terminal, since terminals emulate an old protocol that only allowed 256 separate keys (or maybe only 128).
Chances are, when you press S-RET, Terminal.app does exactly the same thing as if you'd pressed RET. Thus Emacs has no way to distinguish those two cases.
Cross-linking to other Q&As:
If you are using an xterm, then the modifyOtherKeys option may facilitate that binding. See the following for details:
Send "C-(" to Emacs in VT100/xterm terminal (Mac OS X's Terminal)?
I suspect Emacs recognises those codes by default, but if not then also see input-decode-map as described here: Binding M-<up> / M-<down> in Emacs 23.1.1
See explanation and alternative shortcuts for TTY here.
Some of these have worked for me in a terminal in Ubuntu Linux (both locally and over SSH), but not all of them seem to work. For example, the alternative provided for S-RET (which I expected to run org-table-copy-down) instead seems to run org-clone-subtree-with-time-shift for some reason. However, I have found the list of alternatives useful, particularly those with the M- prefix. For example ESC UP for M-UP to move text around in tables.
My problem is that I want to bind Control + Backspace combination to backward-delete-word function. However, it doesn't seem possible because emacs doesn't detect the Control key in combination with backspace.
I detected that by looking at the "logger" (C-h l). So if I press Backspace, it shows DEL. If I press Control + Backspace, it still shows DEL.
Is there any way to achieve that?
I have read and tried other questions, but couldn't fix it.
As #phils pointed out, if you are using Emacs in a terminal (e.g. emacs -nw) instead of as a GUI (no -nw command-line option), and if you are not on MS Windows, then by default certain key sequences are not available to you.
However, it might still be possible for you to configure the terminal (e.g., xterm) so that it in fact supports some such key sequences for Emacs. See this comment by the Emacs maintainer in the discussion of Emacs bug #10387.
(That said, you might find it simpler to just use a different key sequence. Or switch to the GUI version of Emacs.)
I'm trying to learn emacs and would like to use the super key on my keyboard for any meta commands in emacs, because I use dwm as my window manager and it uses the meta key extensively. I have read this page, using it to try
(setq x-meta-keysym 'super)
(setq x-super-keysym 'meta)
with no luck. Ideally I'd like to simply flip them, but only in emacs. when I inspect the variables x-meta-keysym and x-super-keysym with C-h v the commands do seem to be evaluated correctly. When I check the super key with the linux utility xev it confirms that the key I'm pressing is mapped to Super_L.
I agree with #Tyler
In my case I use dwm as window manager, so meta (ALT) key is used to control almost all its features. When using emacs, meta key conflicts with some key bindings, eg: when I'm moving around words M-f or Mb (that's why I came to this thread ;)), so I found three choices to get rid with this issue:
1) change emacs key binding and use super key as meta key
(setq x-meta-keysym 'super
x-super-keysym 'meta)
Both symbols (variables) are required, because if you just use only x-super-keysym 'meta, it enables both keys as meta key. If you just use only x-meta-keysym 'super, it disables both and de command buffer will return s-x is undefined.
2) change dwm key binding for meta to super key in config.h file. take a look in http://dwm.suckless.org/customisation/windows_key
/* key definitions */
-#define MODKEY Mod1Mask /* meta (ALT) key */
+#define MODKEY Mod4Mask /* super (windows or cmd) key */
3) override xmodmap keymap bindings swapping mod1 to super and mod4 to meta (be sure to check what xmodmap returns at first glance, and not affect keybindings of other programs)
Finally, I recommend not to change default emacs meta key because is less comfortable to your fingers and may cause you to respond slowly to keystrokes. Try options 2 or 3 depending your environment.
So, it turns out that the above commands work when emacs is not used in terminal mode. I had been trying it in the terminal exclusively which is why it wasn't working. I'm not sure how to fix it in the terminal, but it's good enough I suppose.
edit: it was the terminal emulator that was gobbling the keypresses before they got to emacs, so the original commands do work, so long as the keypress actually makes it to emacs.
Hello this isn't a coding question but...
I ssh through my mac using X11, and I am using emacs. I am trying to use the "ALT" key for combination but it seems to not be working. I have tried using the "option" key, and "FN + option" both seems to not work.
I had the same problem before. The hint on http://hints.macworld.com/article.php?story=20040425231058862 helps me.
To summarize, you should use xmodmap to remap alt / option in X11.
Put the following in your ~/.Xmodmap file:
clear Mod1
keycode 66 = Meta_L
add Mod1 = Meta_L
If the emacs instance is somewhere else, which is how I read your question, then it maybe that emacs isn't receiving the correct key when you press alt.
There are a variety of fixes on http://www.emacswiki.org/emacs/EmacsForMacOS#toc20.
However, I'd say that you're probably approaching the problem from the wrong direction. Have you considered running emacs locally, and using TRAMP mode edit the remote files on the local machine?
try putting this in ~/.emacs
(set-keyboard-coding-system nil)
I've checked my elisp files to make sure that I do not have any bindings that contain Shift+R (and I have not found any). I expect SHIFT+R to print an uppercase character, but instead I get R R undefined inside of the Emacs command line. This is only in C/C++ major modes.
Any suggestions?
Update: Describing the key shows that it is undefined. How would I define it for the normal, expected use (capitalizing the letter R)?
I assume by the 'expected use' you mean to insert the 'R' character. For this, you'd need to bind the key to 'self-insert-command':
M-x global-set-key R self-insert-command
Or, in your .emacs or .emacs.d/init.el file:
(global-set-key "R" 'self-insert-command)
Of course, this should be the default....
I'm getting a little deja-vu here and if memory serves the behavior I encountered some years ago was that (on Windows) certain accessibility settings unset or changed the keycode for the right shift key. Sorry I cannot be more specific but maybe this will stimulate someone else to come up with the real answer. A test you can make: does the behavior work with both shift keys or just one? If the answer is just one shows the bad behavior, is that bad behavior shown with all keys?
Try C-h k (describe-key), then press Shift-R. describe-key will then tell you what is bound to that key. At least that will give you a hint as to whether or not there is an active binding. If there's a binding, perhaps it will give you a hint of something else to search for in your startup files.
You sound like you're having the same problem I had. Typing Re... in any html buffer would try to execute an R- command, when every single R-* command was undefined. Turned out that I had a typo in my .emacs file. I had a global-key-map set to (kbd "REF") instead of (kbd "RET"), and fixing it made the problem immediately vanish. So I'd recommend checking for anything similar in your .emacs file.