I've just added vim to my current Cygwin installation, and it doesn't work properly.
The problem is: when I type vim <Enter> it opens Vim with the help splash screen (in color) - OK.
I then try to exit with :q , and it sleeps a couple of seconds, then it exits but when I type a character at the command line it pre-pends a spurious string (6c6c). Other similar issues when I try to edit a file in vi instead of exiting right away.
I suppose it is a color/TERM issue, but I don't have much experience in that kind of stuff.
Thanks for any help.
What terminal are you launching vim from? I'd suggest using rxvt. This solves many issues with ncurses type programs.
Sometimes people change their TERM variable. Generally, you shouldn't do this, so long as your environment has the correct termcap installed, this isn't needed. If your use rvxt your TERM variable will default to 'rxvt-cygwin-native'.
Related
I've just started using ZSH with Cygwin/rxvt today (along with a default install of oh-my-zsh), and I'm noticing the reverse history search has a little quirk which is bothering me quite a bit. The search functionality works fine, but entering the search indents the cursor a bit:
This on it's own isn't really problematic, but if I execute the command, it will remain indented there. In addition, if I cancel out of the search, the cursor remains indented afterward:
I can live with this if I must, but I wonder if anyone knows what could be causing this? Given the number of variables involved (Cygwin, rxvt, zsh, oh-my-zsh, etc.), and how new I am to zsh in general, I'm not sure where to start.
It looks very much like the issue here or here: you added colors to your prompt but forgot to tell zsh that these sequences have no width.
I'm having a problem with Vim (I've had it many times before, and now I finally must post it). I don't believe its just a vim thing, but maybe a combination with running it on ssh. Here is a video showing my problem:
http://screencast.com/t/gGoOuJ7wcLA5
I didn't know a way to explain it, so I took the video. If you can't tell, in the video all I do is move my cursor up and down with the j and k keys for vim. For some reason, vim adds on other { signs when my cursor is over the { sign. Vim garbles a lot of other code that I write too, but I'm hoping this example is good enough. Btw, vim does not actually change this. If I quit vim and reopen the text, the characters written are not there. Could it have anything ot do with my $TERM? I have xterm-256color. I've tried xterm originally too.
I'm running this in iTerm on Mac OSX Lion 10.7 accessing a machine over ssh with a Debian OS.
The problem was that the $TERM in in the Debian OS I was accessing was different than the $TERM for iTerm. Once I made them the same (xterm-256color in my case), the weird problem I had went away.
In case anyone doesn't know how to change that, I ran the following command in my Debian/Ubuntu machine:
export TERM=xterm-256color
and for iTerm on Mac, I went to Preferences -> Profiles -> Terminal -> Report Terminal Type -> Choose xterm-256color or xterm.
Since the check for TERM is done at the beginning of logging onto ubuntu, you may want to include the export command into your bashrc (or equivalent file for another terminal shell).
Does :redraw! remove the rubbish characters?
If so, I would try to solve your problem by trying to download the source of the matchparen.vim plugin (easy to find on google), add redraw! to it, just after the critical bit, where it says "setup match highlighting" and try to load it and use it instead of the original one.
When I open the command-line window for editing a complex command-line in vim, I expect to be able to go back and forth in and out of insert / normal mode to edit as I would in any other buffer. (That's the point of the command-line window, right? So that I can do that?) But instead, when I hit ESC to go back to normal mode, I get this:
Error detected while processing function <SNR>15_CloseStackPop:
line 3:
E11: Invalid in command-line window; <CR> executes, CTRL-C quits: pclose
I'm game to try to figure this out, but I don't have a lot to go on. vim --noplugin doesn't seem to have this problem, so it's clearly one of the plugins I have loaded, but which one? I have quite a few. "line 3" of what file? What does "E11" mean?
It turns out that this was a bug in the 'autoclose' plugin. I removed the reference to pclose from the <SID>CloseStackPop function, and now Escape in command-line mode works fine.
In case anyone else has this problem: functions in plugins can be defined with <SID>, which (in the source code) just looks like <SID>Foo, but to Vim look like <SNR>4321_Foo. I was looking for 15_CloseStackPop, assuming that the <SNR> was something special, but when I just did a grep CloseStackPop -r ~/.vim/plugins the offending plugin came up right away.
Try Ctrl+C as a synonym for Escape. Also check .vimrc for the plugins. This isn't standard behavior for vi. If I were you I wouldn't use any plugins unless I was absolutely sure what they did. Perhaps start from scratch and reinstall the ones you feel completely sure of.
I'm afraid asking this silly question but google looks like has no answer for this.
Every time I run VIM in terminal it automatically opens "help.txt" file with sp(split screen) mode.
It says "help.txt" "help.txt" [readonly] 217L, 8055C
Does anybody knows how to fix this problem?
in my case it was because I am using app called caffeine (prevents PC from sleeping) which is simulating pressing F15. After I change it status to inactive, it stopped opening vim help in terminal window.
Try running:
vim -u NONE
If this help file doesn't appear when doing that, then there's something in a vimrc file somewhere that is opening the help. Check in:
~/.vimrc
/usr/share/vim/vimrc
/etc/vimrc
...and anywhere else you might find a vimrc file on your system.
if you run
$ vim -u NONE
and the issue persists, maybe (like in my case) is some software simulating a key press to prevent the system from sleep.
try to change it for another key, like shift, and not f15.
good luck!
I have vimx installed, so I can copy in vimx to the x clipboard by using "+y and the like, which works well as long as I can keep the current vimx running.
However, I also love to be able to switch to the current running shell with ctrl-z and be able to paste what I copied from vim into the shell. Does anyone know how to do this, because as soon as I suspend vim with ctr-z the x-clipboard becomes empty, until I put vim into the fg again.
ok,
After about an hour of head bashing this issue, I have decided to use a different approach to do the same thing.
I will detail what I did here for the benefit of those with the same issue.
If you have wxcopy on your system that is enough to get copy/paste support on your system between vim and other apps. If you want to copy from vim, select the text using v or V or whatever method you prefer, then use the command :tee >(wxcopy). This will copy that code into the oldschool X11 cut buffer. This buffer has the added bonus of not requiring the parent application to be running for pasting to work, hence my problem goes away.
I realize it may be hard to get your hands on wxcopy, under fedora the package that provides it is:
WindowMaker
This isn't an answer as much as a push in the right direction, but start here:
:help quoteplus
:help x11-cut-buffer
Specifically the second help text has some interesting notes about suspending vim. It claims to write the buffer into PRIMARY and CUT_BUFFER0 so you can still use middle click after you've suspended. Maybe you've deleted those or a plugin is interfering? Maybe you are running an old version of vim (I'm running 7.2.182).
My suggestion is to disable all plugins you've manually installed and try vanilla vim. If that doesn't work, consider using vim's -V (verbose) flag and see if it will try to put the buffer into PRIMARY or CUT_BUFFER0 before it actually gets suspended.
I don't have vim compiled with X (vimx) so I can't actually test this myself. Hopefully that gets you in the right direction.