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...?
Related
I was just wondering if anyone knows the emoji support that the Terminal.app has in MacOS?
I'm using zsh, and I end up with this when I type it out, I get the following (note I didn't add a space after the flag on the first one, but added a space on the second one but in both cases you can see there's an overlap on the flag, also note the duplication on the spaces and f on the end of the input)
And when using vim I also get
Just wondering how people resolve these?
Thanks in advance!
I am sorry because this is not really a programmer question (well it becomes one when my bash script needs to change the prompt color), but this inconvenience has been bugging me ever since I started testing my code on Cygwin. When I type a very long command line with a lot of arguments, it breaks to the next line after 61 characters, not at the end of the line (80 in my case), as you would expect it to. When you use backspace, home, end, or left/right arrow keys, the cursor doesn't move as it should. Also, if one of your previous commands in your command history is long (longer that 61 characters), pressing up arrow key after reaching that command will produce a scrambled line. I first though this was a bug in Cygwin and tried to ignore it. After some (very long) research, I found out that the problem was in my profile file, and further research showed that the problem is caused by my prompt coloring.
Apparently, this is the cause of all the trouble:
PS1="\e[0;32m\w> \e[1;32m"
But this works quite fine (except it's the wrong color):
PS1="\w> "
Any ideas what might be the problem? Am I doing something wrong here?
I figured this out a while ago so I can't exactly explain it, but it needs to be like this:
PS1='\[\e[0;32m\]\w> \[\e[1;32m\]'
Basically you need to surround the escape sequences with \[ and \].
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.
Open up irb and
type gets. It should work fine.
Then try system("choice /c YN") It should work as expected.
Now try gets again, it behaves oddly.
Can someone tell me why this is?
EDIT: For some clarification on the "odd" behavior, it allows me to type for gets, but doesn't show me the characters and I have to press the enter key twice.
Terminal input-output handling is dark and mysterious art. Anyone trying to make colorized output of bash work in windows PowerShell via ssh knows that. (And various shortcutting habits like Ctrl+Backspace only make things worse.)
One of the possible reasons for your problem is special characters handling. Every terminal out there can type characters in number of different modes, and it parses its own output in search for certain character sequences in order to toggle states.
F.e. here one can find ANSI escape code sequences, one of possible supported standards among different kind of terminals.
See there Esc[5;45m? That will make all the following output to blink on magenta background. And there is significantly more stuff like that out there.
So, the answer to your question taken literally is — your choice command messes something with output modes using special escape sequences, and ruby's gets breaks in that quirk special mode of terminal operation.
But more useful will be the link to HighLine gem documentation. Why one might want to implement platform-specific and obtrusive behavior when it is possible to implement the same with about 12 LOC? All the respect for the Gist goes to botimer, I've only stumbled into his code using search.
I've sort of got Fsi.exe working as expected on a Mac OS X (Snow Leopard) with Mono. I just noticed a little bit of odd behavior with cut and paste and I was wondering if anyone had seen this.
I've defined the following alias for fsi:
alias fsi='ledit mono ~/FSharp-1.9.7.8_2/bin/fsi.exe --gui-'
ledit is an Ocaml utility that seems to make the keyboard input work correctly--without it, fsi just never seems to read the input. To see what I mean, try Fsi.exe without ledit and enter
let square x = x * x;;
without ledit, it just never seems to parse the input. I mean it never comes back to the ">" prompt after you enter the string. With ledit, the ">" prompt comes back immediately.
Of course the --gui- keeps fsi from displaying all the messages about the lack of System.Drawing etc.
So this all seems to work. The oddity is when I copy and paste code into the FSI, certain characters seem to repeat over and over again. It seems to be conditioned by the size of the buffer I'm pasting in. When I paste small snippets there seems to be no problem. But if I paste in larger chunks, there's this oddity.
If I do the following:
open System.IO;;
then paste this code snippet in FSI:
let buildFileList basepath filespec =
seq {
yield! Directory.GetFiles(basepath, filespec, System.IO.SearchOption.AllDirectories)
}
That works fine. But if I copy and paste in a bigger chunk of code ending with that, it repeats the portion up to the yield! over and over again. It seems to be somehow related to fsi attempting to parse the code as it's being pasted in because the same code pasted in will cause parsing errors (like FS0010) when it's pasted at the end of a long chunk but won't cause an error when it's isolated.
If I #load the entire file, it parses correctly as well so I think my code is ok.
This oddity in copy/paste seems to happen both with and without ledit on the command line. I don't mind researching this issue myself but I'm kind of stumped about where I should proceed with this. I'm copying from GVim if that makes a difference but anyone have any idea where I might proceed in trying to isolate the cause of this odd behavior? I suppose I could take the extra step of copying into TextEdit first and then trying to copy into fsi but any ideas beyond that?
To bottom line this: has anyone else seen this odd behavior? If not, any suggestions about how I might proceed in trying to isolate the cause of this odd behavior?
When I encountered this behavior on my Mac, I went a different route. Instead of using ledit, I employed fsi's --readline option, seen below (where ${FSHARP} is my install path).
mono ${FSHARP}/fsi.exe --readline+ --gui-
You may also want to check your terminal settings. My terminal (for example) is declared as xterm-color, and I have unchecked delete sends CTRL-H. I think those are the only relevant settings, but don't hold me to it.