I have a function that I'd like to map to Alt+o in gVim on Windows (7.3.46 32 bit Bram#KIBAALE Big version on Win7-x64) and it's... not working.
My .vimrc has a line that reads:
nnoremap <A-o> :call SplitRelatedFile()<CR>
Then I fire up gVim, load up a file, hit Alt+o and get a beep. I tried with a capital O in the mapping, I tried with and without shift in gVim, and it's just not working, I just get beeps. (I've also tried <M-o>.)
If I load up Vim in the terminal, it works as expected. If I manually execute the above line in a new instance of gVim, it also works as expected. It's only not working when it appears in the .vimrc. Actually, it appears in another file but my _vimrc just has one line that reads source x:/path/to/my.vimrc.
When I look at the output of :map I don't get alt keys listed as alt keys anyway, presumably due to the 8th bit interpretation crossing something up. However what I do see is...
n <ef> * :call SplitRelatedFile()<CR>
and after I manually run the :nnoremap in gVim I see this (the first line shows i-umlaut as the key if there are any character translation issues with this post):
n ï * :call SplitRelatedFile()<CR>
n <ef> * :call SplitRelatedFile()<CR>
So it seems that the 8th bit is getting interpreted differently at different points in Vim's (GUI) startup? For what it's worth, when I run :map in console Vim I get the i-umlaut as well and not the <ef> line (o is 0x6F in ASCII so would be 0xEF if the high bit is set, so this makes perfect sense; i-umlaut seems to be 0x8B).
I've tried a few different Alt key combinations and none of them have survived into gVim so I'm curious if anyone's got any tips. Maybe I can stuff these somehow into a "delayed load" module of some sort, like a local plugin or something?
I could move away from Alt keys but I'm out of function keys and don't want to stomp on the obvious Ctrl keys for this functionality... I just discovered that I could replace the <A-o> with the result of Ctrl+v,Alt+o and that does work (as I get the i-umlaut in my vimrc) but that's not very nice! Any thoughts on this madness? (Oh and this doesn't work for console Vim, I need to keep the Alt versions for when has("gui") returns false.)
I've now noticed that both gVim and console Vim report the i-umlaut as 0xEF so ... I don't know what I need to do to make this less kludgey. Help me please!
Thanks for any advice.
Mappings (especially combinations with Alt that have the 8th bit set) are susceptible to changes of 'encoding', and may break when you later modify it.
As a general rule, if you want to :set encoding=..., it should be one of the first things in your .vimrc file.
Related
When I'm in insert mode in vim and I use the arrow keys, it sends what seems like a letter and a carriage return. For example, pressing ↑ it sends:
A
It looks like A\n but I'm not sure exactly what characters/codes it's sending. Why does this occur, and is there a way to disable this?
The usual sequence sent by a terminal for the Up arrow is <Esc>OA or ^[OA (the ^[ sequence represents the <Esc> key, also equivalent to Ctrl+[.)
If your Vim fails to recognize this sequence as the Up arrow, it will end up executing this sequence: <Esc> which will leave Insert mode and go to Normal mode, then O to insert a new line above the current one and go to Insert mode, then insert a literal A since you'd be in Insert mode again.
You can confirm that this is indeed the sequence your terminal is sending Vim by typing Ctrl+V followed by the Up arrow in Insert mode. (Ctrl+V in Insert mode inserts the next character literally.) I'd expect you'd see the ^[OA sequence inserted.
Then you can check what your Vim thinks the sequence for the Up arrow is with the :set <Up> command. I'd expect you'd see something like:
t_ku <Up> ^[OA
(t_ku is the internal name for the setting corresponding to this Up arrow key. You can also use :set termcap to see all Vim settings related to the terminal, including the special key codes.)
If either of these don't match the expectations, that would explain why your Vim is not recognizing the Up arrow key. (One alternative explanation is that 'ttimeoutlen' is set too short, but I'd say that's highly unlikely.)
These settings are usually managed by the 'term' setting. By default, it's set based on whatever you have for $TERM on your shell outside of Vim.
You can start by looking at what Vim thinks 'term' is, and where it's set from:
:verbose set term?
term=screen-256color
Last set from ~/.vimrc line 100
The :verbose part asks Vim to tell you where it's set from, so you'll see if your vimrc or one of your plug-ins is overwriting it. If Vim shows none of that, it means it's coming from the $TERM variable in your shell.
So look at what $TERM is set to outside of Vim and see if that seems to be correct or not. Are you setting that explicitly somewhere? Be it one of the shell's initialization files or perhaps from your terminal emulator itself?
Also possibly relevant whether you're using tmux or screen, in which case you should double check that $TERM is also set correctly both inside tmux or screen, but also outside it.
Hopefully all these hints should lead you in the right direction fixing this. If you can't figure out, post your findings as comments on this answer and I'll update it with more specific fixes you can try.
You're probably in vi compatibility mode. try :set nocompatible
If that makes it function as you would like, put set nocompatible at the top of your vimrc file to get it to default to this behavior.
I read for a few hours on different threads for this issue without any results. Every time I was doing searches for something like
"lwindow" meta
I was always getting into EmacsWin32 code which appears to be code developed in 2006.
So, here I am to ask the question:
Is it possible to remap the Meta key, for Emacs, in Windows to something else than Alt?
I would prefer to remap it to the Windows key, but I don't think it is possible. Then the Fn (function) key would be a good alternative.
I need my Alt key operational in Emacs since it is used for all kind of things on a French keyboard.
I know nothing about Windows, but w32-pass-alt-to-system, w32-alt-is-meta, w32-lwindow-modifier, and w32-rwindow-modifier seem like good candidates (maybe combined with w32-pass-lwindow-to-system and friends).
Finally the only thing that worked for me is to use the
(require 'iso-transl)
That is making sure that the mapping of my (Canadian) French keyboard is working properly.
Then I started to use the right Alt instead of the left one. That way, I can do everything that I was doing with Ctrl+Alt.
In vim, to find a character you can use 'f' to find the next matching character in the line that your cursor is on, and 'F' to find the previous matching character in the line that your cursor is on.
Is there a way to move around like that on the bash command line?
I know that you can set bash to be in vim mode, by saying set -o vim, and this works great for my local machine, but I administer a lot of machines where I can't change that setting.
Ignoring for a moment the security issues associated with everybody in your office sharing the same user, you could add a key binding to the readline command character-search:
# ~/.inputrc
C-]: character-search
To use the search, type Ctrl-] followed by the character you want to search for. You can bind the command to any key sequence, not just Ctrl-], but for obvious reasons you probably don't want to emulate vi mode by binding it to the letter f.
This would be less invasive than turning on vi mode so most users would probably not even notice the change. However, somebody could easily stumble upon your key sequence by accident and become very confused. You would also have to use three keystrokes instead of the two you're accustomed to with vi.
Lots of times I'll use Ctrl-R for reverse search and mistype some letter. Bash jumps up hundreds of lines and I'm in the middle of commands I was using a week ago.
Is there a shortcut for jumping back down to the lastest commands I had typed?
Edit: after testing it out on a CentOS server and Mac OS X, it looks like this only happening on OS X.
I've struggled with this same issue.
You can solve this by aborting with ctrl-c. Whether you're in the middle of a reverse search or scrolling through history with the arrows, aborting returns you to a prompt with the history scroll just after the last command.
UPDATE
Here's a nice trick I just learned. Bash and many other programs use Readline under the hood for command-line interpretation. Key bindings for Readline can be configured in a .inputrc file or with the bind command. The bindings can make use of a few functions provided by Readline. For example, I use Bash in vi mode but I still like to use Emacs-style ctrl-A so I have this line in my .bashrc file:
bind '\C-a:beginning-of-line'
To list all the available Readline functions:
bind -l
Among the functions is end-of-history. The function does like its name suggests. The difference between this approach and just using the abort command is that this keeps you on the same prompt.
If using libreadline, Alt-> (or Meta->). More info on Readline shortcuts or search for Commands for Manipulating the History in the man page.
On Mac, try command + .
It works for me.
I was trying alt+. and alt+shift+. , neither works for me. And then found command + . actually works
Maybe not exactly what you want, but you can fix your mistyped character(s) by using backspace when you're in the CTRL-r (reverse-i-search) mode.
You may wan to try "suggest box"-like history HSTR. It reads the bash history and allows quick navigation and filtering - you can see the context of similar history entries. Once you select a history entry it can be edited on the command line.
In Zsh with emacs binding set the actual default key sequence is ^[> binded to end-of-buffer-or-history command rather than command-. suggested above (or end-of-history depending on effect you want to achieve)
Cmd-. produces in Apple Terminal the similar or the same key sequence as Ctrl-C, which can be confirmed by running something useless and long, e.g. find . >/dev/null 2>&1 and pressing one and then other keys on keyboard.
Ctrl-C forces input to be ended and reset. and history scroll is just a side effect for it.
For some reason, I cannot jump forward with <C-I>; gives me the error beep. <C-O> works just fine.
I don't see any remapping going on either. Any ideas what might be the problem?
I'm using vim 7.3 on win7
EDIT: I just found out <C-I> does the same as %! I still can't figure out how to fix it though.
Why does having <TAB> mapped affect <C-I>? The short answer is, "historical reasons", dating from even before the original 'vi'.
The ASCII code for <TAB> is 9, same as <CTRL-I>. Since terminals receive their input encoded in ASCII, they can't tell whether that "TAB" signal came from the actual <TAB> key, or from the user holding CTRL and pressing I. Since Vim was originally written to run on terminals, it can't tell the difference either.
A couple of other pairs of indistinguishable keys are <C-M> with <Return>, and <C-[> with <Esc>.
It's possible there's some arcane way to tell the difference between the two (more likely if you're using GVim), but if there is, I don't know it. As a workaround, you could use nnoremap <SomeOtherKey> <C-I> to give <C-I>'s original function to some other key.
I found a fix for the problem, but I don't know why it works..
I had <TAB> mapped to %. By removing this, <C-I> works as normal.
Any idea why this works...?