I'm trying to set a command for C-M-s, however the M-s bit is screwing up. When I try to search for an existing command for the C-M-s keybinding using the describe-key function (C-h k) nothing is registered. When I search for just M-s the buffer registers Esc-s. This only happens with the s key, for example, searching for M-d and C-M-d both work as expected.
Related
For some reason, I'm loosing the up-arrow and DEL keys after launching GHCi from within an ansi-term window in Emacs.
(These keys work as expected from within the ansi-term window, before launching GHCi.)
And RET doesn't produce a line feed, just a carriage return.
I don't observe any of these oddities when launching GHCi from my normal Terminal application under MacOS X.
Using Emac's view-lossage feature I find:
<menu-bar> <Terminal> <Character mode> [term-char-mode]
<up> [term-send-up]
<return> [term-send-raw]
<backspace> [term-send-backspace]
<menu-bar> <Terminal> <Line mode> [term-line-mode]
<up> [previous-line]
<return> [term-send-input]
<backspace> [delete-backward-char]
C-h l [view-lossage]
(Note: The above was taken after launching GHCi from within the ansi-term window of Emacs.)
And it looks like I may want to switch to Line mode while running GHCi.
(I normally run the ansi-term window in Character mode, because it gives me an experience more similar to working in the Terminal application.)
It looks like M-p will recover past commands.
So, if I can figure out how to get the up-arrow remapped to M-p while in GHCi, then I should be pretty close to my usual GHCi-in-Terminal experience.
However, there's one remaining problem: I'm still not getting a line feed when hitting RET.
And this is really screwing things up, both asthetically and functionally.
It's strange, because the RET key typed at either the ansi-term prompt, or the GHCi (launched from within ansi-term) prompt (with the ansi-term window set to Line mode) both send the same command: term-send-input.
And the ansi-term does the right thing in response to this command.
So, why doesn't GHCi do the right thing?
Perhaps, I need to remap RET to: CR/LF; term-send-input while in GHCi?
Is this even possible (i.e. - doing application-specific key remapping withing the ansi-term window)?
I want to remap Control-v for it to use my custom function, but it looks like I can't do that. I'm running emacs in terminal.
(global-unset-key "\C-v")
(global-set-key "\C-v" 'my-cut-or-paste)
If I try to unset first, C-h k just not showing any binding for this shortcut, and C-v just do nothing. If not unsetting shortcut, its not get remapped... The strange thing is how C-h k showing different keys for such shortcuts. For example - one time it can show
r runs the command self-insert-command, which is an interactive
other time (after emacs reload)
i runs the command self-insert-command, which is an interactive
If I try to set my function to such keys (i or r), C-v gets remapped, but those keys (i or r) are mapped to my function too, so I cant type.
Is this kind of 'terminal-related' key sequences? Is it able to do at all? thx.
My guess would be that your terminal is intercepting C-v as a paste-from-clipboard command.
If your clipboard has something that starts with i, you see:
i runs the command self-insert-command, which is an interactive
Similar for "r" or other letters. Emacs is blind to the fact that the "letters" come from a external paste, not from your keyboard. You should check the configuration options of your terminal, to see if you can unset that key.
I have this in my .emacsrc
(define-key global-map "\C-h" 'backward-delete-char) ;;previously help
however, when I do an I-search and hit C-h to delete a char, emacs uses the default binding and tries to open the help, when I cancel the search with C-g, it then executes the backward-delete-char in the document I started the I-search from.
EDIT: This makes me wonder why C-h is again mapped to help inside the minibuffer. What is overriding my global-map definition and why?
You can use this:
(keyboard-translate ?\C-h ?\C-?)
This will translate C-h to backspace everywhere.
When you do isearch or ido-find-file, they
override some keys in the minibuffer. You could re-override
these keys for each mode, but you'd have to really do it for each
new mode that you use. That's why I've suggested the code above:
modes will not typically rebind backspace to something that doesn't behave
like a backspace. The point is that the logical C-h is still
bound for help inside minibuffer, but with keyboard-translate you don't
have C-h anymore - you just have another backspace. And if you
want to bind some command to it, you can't bind to C-h -
you have to bind to ?\C-?.
My guess is that you don't really want to delete a char when you hit "control and h", but instead that for some reason Emacs receives C-h when you press the backspace key, right?
If so, the best solution is to figure out how to change your terminal emulator so that it doesn't send C-h to Emacs when you press backspace (e.g. it could send C-? as do most other terminal emulators nowadays).
I have the following code in .emacs: (global-set-key (kbd "M-x g") 'gnus) to start Gnus with the keybinding M-x g. I obtain: error: Key sequence M-x g starts with non-prefix key M-x. How can I define keybindings starting with M-x? Is this a bad thing to do and should be avoided? I find it more intuitive since the "long version" is M-x gnus. Defining it as C-c g for example is no problem but then you start Gnus with C-c g and, for example, R via M-x R which is not very intuitive (in contrast to starting both via M-x + 1 letter
The key M-x is already bound to the command execute-extended-command, which then asks you to provide the name of a command to execute (in you case: gnus).
Since R is a command only one-character long, it looks like M-x R is a key sequence, but it's not: it's M-x followed by entering R in the minibuffer and you have to hit RET to validate your input.
In short:
you can not set key sequences beginning with M-x since this key is already bound to a command and is thus not a prefix (unlike C-c, which does nothing but wait for you to type another key, but should be reserved for bindings specific to the current modes).
the standard way to do things would be to continue starting gnus using M-x gnus or to rebind it to an entirely different key if you need to be very quick (you could for example use one of the F1-F12 keys)
if you really want to have a M-x + letter binding, you can define a one-letter alias to the command gnus, like this:
(defalias 'g 'gnus)
I'm trying to use C-h c in emacs to figure out what a key combination is bound to. The combination is C-u C-c C-q, which realigns tags in org-mode. However, Emacs just tries to look up C-u C-c and then fails. What am I doing wrong? I realize I could easily look at the orgmode source or something to figure this out, but for future reference what would I do to figure out what function something like this is bound to?
Edit: OK, so it's actually C-u followed by C-c C-q, and according to emacs this is what that combination is bound to:
(org-set-tags-command &optional arg just-align)
Call the set-tags command for the current entry.
So what exactly does it mean to give this command the argument 4?
Oh, just to give an explanation: I'm trying to start learning emacs-lisp and customization and one of the things I wanted to do was to have this command added to the before-save-hook so that when I save an org file, the tags get automatically aligned.
Final edit: I figured out why this command behaves as it does; given the prefix argument it changes its behavior. How can I set the prefix argument when calling the function in elisp?
It's not a general problem with combinations that are three keys long: For example, C-h c ESC ESC ESC (keyboard-escape-quit) or C-h c C-x r t (string-rectangle) both work fine.
When I try C-h c C-u C-c C-q in org-mode, the command interrupts after C-u and shows:
C-u runs the command universal-argument
in the minibuffer, which is correct. So, in fact, "C-u C-c C-q" is not a command, it's the command "C-c C-q" (org-table-wrap-region) started with an additional argument (4 -- see C-h k C-u for an explanation).