In GNU screen, I want to change the default command binding to Alt-s (by tweaking .screenrc) instead of the default C-a, the reason is I use emacs hence GNU screen binds the C-a key, sending "C-a" to the emacs becomes tedious (as #Nils said, to send "C-a" I should type "C-a a"), as well as "C-a" in bash shell, and I could change the escape to C- but some of them are already mapped in emacs and other combinations are not as easy as ALT-s . If anyone has already done a ALT key mapping, please do let me know.
It is possible to work around :escape command limitations using registers and :bindkey command. Just put this in .screenrc:
# reset escape key to the default
escape ^Aa
# auxiliary register
register S ^A
# Alt + x produces ^A and acts as an escape key
bindkey "^[x" process S
## Alt + space produces ^A and acts as an escape key
# bindkey "^[ " process S
See http://adb.cba.pl/gnu-screen-tips-page-my.html#howto-alt-key-as-escape
From my reading of man screen it seems like the only meta character that screen can use for the command binding is CTRL:
escape xy
Set the command character to x and the character generating a literal
command character (by triggering the "meta" command) to y (similar to
the -e option). Each argument is either a single character, a two-character
sequence of the form "^x" (meaning "C-x"), a backslash followed by an octal
number (specifying the ASCII code of the character), or a backslash followed
by a second character, such as "\^" or "\\". The default is "^Aa".
If there is some mapping that you don't use in emacs, even if it's inconvenient, like C-|, then you could use your terminal input manager to remap ALT-X to that, letting you use the ALT binding instead. That would be a little hackish though.
I'm an Emacs and screen user as well. Although I rarely use Emacs in a terminal -- and as such in a screen session -- I didn't want to give up C-a for the shell either (which uses Emacs key bindings). My solution was to use C-j as the prefix key for screen, which I was willing to sacrifice. In Emacs programming modes it is bound to (newline-and-indent) which I bound to RET as well, so I really don't miss it.
By the way: I know this is an advise rather than an answer, but I felt this would be valuable enough to post nevertheless.
To make Alt+X the default prefix for commands and free C-a, add the following lines to .screenrc:
escape ^||
bindkey "^[x" command
As a side effect C-| will be command prefix too. If you need this keys to be free too, then fix "escape ^||" accordingly.
Screen doesn't have any shorthand syntax for alt bindings, but you can give it the octal code directly. For instance on my machine, Alt-x has the hex code F8, or 370 octal, so putting
escape \370x
in my screenrc changed the escape code to alt-X
Tested and works with screen 4.00.03 on Linux.
You may have to change the escape, since I think this may depend on things like your language and codeset, etc: how I found out what my escape code was was to type
$ echo -n ^QM-x | perl -ne 'printf "%lo\n", ord($_)'
^Q is the quoted-insert command for readline (it inserts what you type directly without trying to interpret it) and M-x was a literal Alt-X.
Fellow emacs user here.
The best solution I've found is a ~/.screenrc file with the following:
# C-a :source .screenrc
escape ^gg
Live updated here: https://gist.github.com/1058111
See also: http://ubuntuforums.org/showthread.php?t=498675
Something I have had for years in my .screenrc:
escape ^Zz
which is now hardwired in muscle memory for me.
Somehow I ended up having to share a screen with someone else's config, and now I keep stopping processes all the time (bash ^Z)... Not funny...
Related
I've installed vimgrep plugin, inside vim, under normal mode I can type:
:vimgrep mywords %
to search "mywords" for the documents under current directory.
But I wish that in normal mode, when I highlight a word using gd, or in visual mode use 'viw' to select a word, I use a hot key to vimgrep. So I add in my .vimrc and restart vim:
vnoremap <F8> :vimgrep expand('<cword>') %<CR>
Well it didn't work for me, when I put focus on one word and select it, I press F8, no response in vim. How to achieve it?
Thanks!
Vimscript is evaluated exactly like the Ex commands typed in the : command-line. There were no variables in ex, so there's no way to specify them. When typing a command interactively, you'd probably use <C-R>= to insert variable contents:
:vimgrep <C-R>=expand('<cword>')<CR> '%'<CR>
... but in a script, :execute must be used. All the literal parts of the Ex command must be quoted (single or double quotes), and then concatenated with the variables:
execute 'vimgrep' expand('<cword>') '%'
Actually, there's a built-in command for inserting the current word into the command-line: :help c_CTRL-R_CTRL-W:
:vimgrep <C-R><C-W>
Your mapping
You could use all three approaches; let's use the last:
vnoremap <F8> :<C-u>vimgrep <C-r><C-w> %<CR>
The <C-u> clears the '<,'> range that is automatically inserted.
What you probably wanted
Using the current word from visual mode is strange. You probably wanted to search for the current selection. There's no expand() for that. Easiest is to yank, as outlined by #ryuichiro's answer:
vnoremap <F8> y:vimgrep /<C-r>"/ %<CR>
Still missing is escaping of the literal text (:vimgrep searches for a regular expression pattern), and of the / delimiter:
vnoremap <F8> y:execute 'vimgrep /\V' . escape(##, '/\') . '/ %'<CR>
Robust plugin solution
Now, if you also want to avoid the clobbering of the default register, it gets really complicated. Have a look at my GrepHere plugin; it provides a {Visual}<A-M> mapping for exactly that.
Try
vnoremap <F8> y:vimgrep "<c-r>"" %<CR>
:h y
:h <C-r>
Recommended reading: Mapping keys in Vim - Tutorial (Part 1)
I am slightly confused by the difference between keys and key-bindings in emacs after reading the first chapter of "Writing GNU Emacs Extensions" (O'Reilly book).
The chapter starts by noting that in some emacs version the keys backspace and DEL, invoke the help menu instead of deleting. In other words, they invoke what is invoked by C-h.
The chapter then goes on to show how to change this behaviour using Lisp code. This is done by binding the keystroke C-h to the delete command.
This is a bit confusing to me. In my mind DEL, Backspace and C-h are three different keystrokes (the first two consisting of a single key).
Why does remapping C-h effect what DEL and Backspace does?
I would have thought to change what backspace does for example, you would remap backspace to another command, not the keystroke C-h.
Unless remapped by a low-level keybord driver, the effect of the Backspace key is to send the character with numeric code 8, which, in certain operating systems, is exactly the same code generated by pressing Control-h. You can verify this fact by simply writing anything on a unix (or linux) shell and then pressing Backspace and Control-h: both of them have the effect of erasing the previous character, since the character with numeric code 8 is interpreted by the operating system as the control character BS, backspace, used either to erase the last character printed or to overprint it (see wikipedia). Analogously, Control-J is equivalent to the RETURN key, etc.
The same Wikipedia page describe DEL as “originally intended to be an ignored character, but now used in some systems to erase a character”.
So, when you assign a command to a keystroke you are actually assigning a command to a character code, and if two or more keys generate the same code, by pressing them you are invoking the same command.
#Renzo answered your question about how these keys are related and how binding one can seem to affect another. Here is some more information about what's going on in this particular case.
See the Emacs manual, node DEL Does Not Delete.
There you will see this, following an explanation of the problem/confusion:
To fix the problem in every Emacs session, put one of the following
lines into your initialization file (*note Init File::). For the first
case above, where BACKSPACE deletes forwards instead of backwards, use
this line to make BACKSPACE act as DEL:
(normal-erase-is-backspace-mode 0)
For the other two cases, use this line:
(normal-erase-is-backspace-mode 1)
Another way to fix the problem for every Emacs session is to
customize the variable normal-erase-is-backspace: the value t
specifies the mode where BS or BACKSPACE is DEL, and nil
specifies the other mode. *Note Easy Customization::.
See also the GNU Emacs FAQ question about Backspace invoking help. There you will see, in addition to information similar to that above, information about how to remap DEL on UNIX - use this:
stty erase '^?'
Wrt C-j and RET (not mentioned in the question, but mentioned in #Renzo's answer): The default behavior of Emacs changed in most programming modes, in Emacs 24.4.
Starting with that release, electric--indent-mode is turned on by default, which means that RET inserts a newline character and indents, whereas C-j just inserts a newline character. Prior to that release, these keys had the opposite behaviors. If you prefer the old behavior then do this, to turn off electric-indent-mode:
(when (fboundp 'electric-indent-mode)
(electric-indent-mode -1)) ; Use classic `C-j' and `RET'.
This is odd. I have defined the following prompt in zsh:
local user_host='%{$terminfo[bold]$fg[green]%}%n # %m%{$reset_color%}'
local current_dir='%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}'
local git_branch='$(git_prompt_info)%{$reset_color%}'
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"
It works great on gnome-terminal as well as in an ansi-term terminal in Emacs (M-x ansi-term) - see the example below:
However, it does not work well under multi-term in Emacs as you can see below:
I thought multi-term would be capable of interpreting the same set of escape characters that a terminal like gnome-terminal or ansi-term does. Why is it not interpreting the escape characters returned by git-prompt_info and others correctly?
I have also tried:
M-x set-terminal-coding-system and setting it to utf-8-unix
TERM=eterm-color within the multi-term terminal, or before calling Emacs, etc.
TERM= within the multi-term terminal, or before calling Emacs, etc.
Removing any export TERM from my .zshrc
Update (January 29, 2014):
The best solution so far seems to be to do the following:
TERM=xterm-256color
but causes another problem that I have reported here: Passing escape sequences to shells within ansi-term in Emacs.
Why is it not interpreting the escape characters returned by
git-prompt_info and others correctly?
The answer is most likely that multi-term just isn't prepared to accept those escape sequences, in that format, for whatever reason. This may be a configuration issue, bug, or intentional. Setting the mode to accept colors, i.e. TERM=xterm-256color, improves the situation because it then accepts color escape sequences similar to the standard format used among terminal emulators, e.g.:
RED='\033[0;31m'
NC='\033[0m' # No Color
echo "I ${RED}love${NC} Stack Overflow\n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} Stack Overflow\n" # this output IS interpreting them
code borrowed from here
the salient part is the [0;31m for color, which is referenced in the linked thread in "Update 2" of your other question, asking why lines are printed out that begin with 4m which is part of this color escape sequence.
Here is more info, with a relevant excerpt:
Thus it is your terminal emulator that understands colors. Your
terminal emulator understands that \033[0;36m is cyan, but another
terminal emulator might use an entirely different set of characters
for cyan (though no sane terminal emulator would flaunt the standard
and do this). This is the reason for tput. When you run tput setaf
6, tput is going to look up your terminal's escape codes for the
color 6 (cyan), and output that escape code.
I suspect, in your other question, the reason that alt+b and alt+f aren't working in your other question is due to the terminal width count being off because of improper interpretation of these escape sequences which are supposed to be non-printing or zero-width. I haven't messed with multi-term a lot but the solution may involve using tput or similar to allow it to properly understand the escape sequences.
Possible relevant troubleshooting info
How can I write a "," (comma) character in the SLIME emacs window? The , key brings up the SLIME command prompt automatically.
Thanks, a Lisp beginner
, only triggers REPL shortcut selection when input at the beginning of a line. In all other cases, you can input a comma by typing ,.
In the case of Common Lisp, since as long as you don't modify the reader, , can only occur within a quasi-quoted expression, this should not be a significant restriction.
If it really is a problem, refer to Deokhwan Kim's answer.
You can insert , by C-q, (Control-q and then comma). C-q is bound to quoted-insert, which can be generally used whenever you want Emacs to read a next input character and insert it instead of invoking a command bound to the input character.
I'm using emacs 23 on ubuntu 10.04. I would like to remap the "C-[" binding. Currently, when I press it, it gives me "ESC". Is there a way to remap it?
This is not an Emacs binding, but has global effect in X and it's used as handier substitute for ESC for people practicing touch typing. I guess you'll have to modify the X keymap if you want to use it in another fashion, but I wouldn't advice that.
C-[ is the ASCII ESCAPE character, which Emacs usually writes as ESC.
There is no key involved here (it's a character), and there is no key binding involved here. Or rather, your keyboard's Escape key sends the control character ESCAPE (also written C-[ and ESC).