I'm attempting to edit files on a remote system. I've ssh'd to the system and I start editing with vim.
However, I notice that all the lines are drawing 2 lines above where they really exist in the file. I assumed this was a problem I could fix by dropping my terminal settings to something simpler, but that didn't help.
My TERM variable was set to xterm-color. I set it to vt100, but that didn't fix the line drawing issue. I also noticed that this seems to be specific to vim. emacs doesn't show the problem, and I haven't noticed any odd drawing artifacts in less, more or other paging tools.
Other specifics: I'm ssh-ing into the remote system from a Mac, using the Terminal.app. The remote system is running Ubuntu 9.04.
I'm hoping there is something I just need to set in vim to get it to play nice. If it allows me to keep syntax color highlighting, so much the better.
Zhaojun's suggestion works. Setting TERM=xterm is clearing things up.
Related
I have an instance of vi on a remote server that is not behaving like it used to, and I'm not sure what made this happen.
On my local shell, (and the remote server before this started happening), if I scroll with my mouse/touchpad, it would navigate the cursor within vim. I have checked my .vimrc and there's nothing in it relating to the mouse, and I did not make any changes to it before this issue started.
The only thing I can think of is that a few weeks ago, I was trying to figure out how I could split two files in the same vi instance so I could yank from one file to another, and I tried some : commands that I didn't really understand (didn't get any productive results). And also, I ran tmux once, but I don't think there are any . files that are applying unwanted settings (not sure).
I can't find anything to check the vi settings being applied, but I know that my .vimrc is working, and it's not anything in there (if I comment everything out it still behaves this way).
I just want my vi to respond the same way.
Describing the problem more exactly:
If I scroll, the cursor doesn't move, instead it scrolls on the terminal window, and it shows the previous bash commands instead of scrolling the file being edited. If I navigate using vim keys, it still works.
Randomly, I discovered that it actually had to do with the a specific terminal instance that was causing the issue. Closed it, opened a new one, no issue now. If anyone has any insight on why this could've been, I'd love to know.
.vimrc applies to vim not vi, doesn't it ?
the problem of scrolling might come from your terminal emulator as well.
I usually use embedded terminal in VS code which is not ideal (since it's not made for administration ...) but it's practical with keybinds to jump from one window to another, copy paste ...
I know some colleagues who use, mobaXterm or mremoteNG on windows.
I know I should give a go to Terminator, but it's on linux only and I don't want to run a local vm just for that.
Vim & NeoVim both leave patches of simply black text scattered in random locations across the viewport. This is most common when scrolling or jumping between locations. This affect has happened on multiple different colorschemes so I suspect its more a problem with vim or my shell, than with the scheme. Generally when I load a file these patches don't exist, but they appear pretty quickly after starting vim. Reloading my configuration file or changing the scheme definitely makes them appear. Restarting the shell or quitting and restarting vim doesn't have any affect.
I'm running windows build 17763.92 on windows 10 Education & vim/neovim on Ubuntu (version 18.04 Bionic) bash for windows under the WSL.
Could anyone enlighten me as to why this is happening?
Heres my vim version info.
Heres my vimrc File & A Screenshot of The Described Affect.
This is usually caused by a wrong terminal setting in $TERM. The commands that Vim sends to the terminal to clear it then don't properly set the background color, and only text written on top has the correct background.
If you don't find a fix for that, you can work around the problem by clearing the background color of the Normal highlight group:
:hi Normal ctermbg=NONE
This happened to me as well, I would get black highlighting when opening a new line using o or O, and it would also appear when paging down (ctrl D) then scrolling up (k).
I was using vim (.vimrc - colorscheme desert with syntax on) on windows ubuntu subsystem WSL.
I was able to make it go away by updating my Windows 10 version 1909, to Windows 10 version 2004.
My problem was similar to this post: https://vi.stackexchange.com/questions/21437/vim-is-highlights-everything-after-eol-in-yellow-upon-scrolling
and, someone had also mentioned it being related to the terminal type xterm-256color here (their recommendation was to upgrade Windows version, it worked for me): https://superuser.com/questions/1526515/vim-highlighting-newlines-in-a-file-how-to-disable
I'm guessing lots of people get this problem, but I can't seem to find any other threads/questions about it anywhere. I guess it's difficult to capture in keywords.
Basically, Vim doesn't draw the background color when scrolling up in places where there is no text. I've also seen it on my friend's Mac, so it's not peculiar to my setup.
I have a pretty big vimrc, but I get the same problem without a vimrc and setting :colorscheme blue.
I'm using gnome-terminal on Ubuntu 11.10 (Oneiric Ocelot). It's a fairly clean install that I set up only a few days ago, so there's not really any funny business going on. I expect this would happen out of the box.
I've not had this problem in other contexts e.g. over SSH with PuTTY or previous versions of Ubuntu which I'm guessing was also gnome-terminal.
What's going on?
In Linux I had export TERM=xterm-256color in my .bashrc. That caused Vim to look like this (after setting set t_Co=256):
When I removed that line from my .bashrc and opened a new terminal (exec bash didn't do it). This is what I get (you need to have set t_Co=256):
Try running :set t_Co=256 (replacing 256 with the value corresponding to the number of colors your terminal supports). A similar looking (though less conspicuous) problem of mine was caused by using too few of the available terminal colors in Vim. To figure out how many colors your terminal supports, see this.
I had to do two things:
Remove set t_Co=256 in my .vimrc. (The terminal showed 256 colors anyway)
The color blocks still appeared when scrolling though, so I had to do the change detailed here: https://superuser.com/questions/457911/in-vim-background-color-changes-on-scrolling
Something extremely weird is happening when I open files in vim, and I can't remember doing anything that would have caused it.
Weird behaviors include:
no text being visible until I highlight it in visual mode, at which point it is visible from thereon. ":redraw!" does not make anything visible.
line 1 missing
occasionally the cursor appears one line below where it is editing
statuses become permanent and scroll up from the bottom, rather than just redrawing at the bottom
the vim text not extending to the bottom of the vertically maximized window
I lack the reputation to post screenshots but I'll happily provide any other information that could help in a diagnosis.
ETA: Ah! My .vimrc specified a column/row size. I've removed that line, and so far things are behaving well. Thank you!
vim is terminal based, and errors like this happen when the terminal you are using does not match the terminal vim thinks you are using. Most people use vim with terminal emulators. This kind of thing can happen when you resize the emulator window and vim does not find out about it, or more rarely, when the terminal-identifying-string specified in the environment does not match the terminal emulator you are running.
Without more details about the platform on which you are running vim, it is hard to be more specific-- but as a tip: don't resize the emulator window after it is created but before running vim.
Terminal emulators are supposed to communicate size changes back to the program running within them, but this is not 100% foolproof, especially when you are logged in to a remote machine within the emulator.
If you're doing this from a UNIX (Linux et al), try running :!resize to force your terminal to re-adjust its size parameters. At the very least it'll tell you what the system thinks your window is sized to, which may not match its actual size.
I had a similar problem when using vim with bash. When I switched from bash to zsh, it gave redraw errors where, while I typed, the cursor or screen would appear to go down one row for every 10 characters I typed. Scrolling with arrow keys also caused major display problems along the same lines, but worse.
I had this line in my previous .vimrc, I believe it was to set the color for vim
set t_256
I changed it to set term=xterm=256color and the problem went away.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Background
I'm building an application where it detects what documents you're using from the file system. To do this it must access the AXDocument attribute of the active window. MacVim provides this. Running Vim in the Terminal wouldn't provide this.
I've just put out a survey to ask what editor coders who are interested in my app use. A significant number of the folk using Vim used it directly from the command line.
Why not use a GUI Vim?
Why do some people prefer to run Vim this way versus a GUI implementation like MacVim?
What advantages does this offer? As I understand it, you can send files to MacVim from the command line just as easily as command line Vim.
These reasons may be different for each specific developer but my guess would be:
vim is pretty much vim on any platform. GUI implementations can
vary.
Familiarity - being familiar with vim does not nessecarily mean
being familar with vim wrapped ina
GUI - espectially given #1.
"Elite Complex" ;-)
No definite avantages to the users over cli vim.
One might not have access to a gui (think ssh) or simply force of habit.
Although I don't use any feature exclusive to the GUI version (never touch the mouse while editing) I find GVIM more pleasing to the eye for fonts rendering and color management. So the only reason to use the cli version is not having access to a graphic environment (like when accessing a remote machine via ssh). Using GVIM also allows reuse of the terminal it was called from without having to use screen.
being able to run vim under screen provides
reliability: it will stay alive if X or the terminal app crashes. not sure how applicable this is to the Mac.
the option to multiplex sessions within terminal tabs. I actually end up rarely using terminal tabs because of this. It's possible (albeit a bit confusing) to set up heirarchical screen sessions and move branches of them around. screen is super awesome. This also provides an additional layer of text buffering in which you can search by regexp — this is useful if you spawn a shell command that is pages long and you're looking for a particular word in there.
the ability to connect to an existing session from another computer or reconnect after a network outage
and friends
in addition to making it possible to use screen, the console vim provides better shell integration. Although it's possible to run shell commands from within gvim (again, I'm not sure how this applies to the Mac, I'm a linux guy), there are limitations. I rarely use a gui vim so I'm not sure about the exact limits. For example, ANSI color codes are removed. I find this annoying because I tend to interact with SCM that way, for example running :!git diff --cached to check the changes in the index before committing. It makes for a somewhat quicker and more satisfying (mmm, diffy!) read if it's colourized.
I used to feel that gvim was a big improvement for viewing diffs, but I've changed the background colour of my terminal to a dark non-black shade, and set
:highlight DiffAdd ctermbg=Black
:highlight DiffChange ctermbg=Black
:highlight DiffDelete ctermbg=Black
:highlight DiffText cterm=Bold ctermbg=None
The result of this is that in diff mode, differing text shows up with a black background, and unchanged text is coloured with the terminal background colour. For side-by-side diffs, this works wonderfully, since you can tell immediately based on the other side whether a given line is a change or add; for non-side-by-side you will be able to see an unchanged part in a changed line.
This means that you can leave syntax colouring on and still be able to see diffs. Again, you do need to be able to set the background colour of the terminal to a unique, dark, non-black shade. This facility is available in the terminal emulators that I use (yakuake/konsole and roxterm) and many others.^[?Mac^M"mya)^O^Op
This also assumes that you're using a colourscheme meant for use with a dark background colour; I use a modified delek.
Although I haven't tried this, there is also the option to run console vim in 256-colour mode on terminals which support that mode — which I believe includes most or all modern ones. This can serve to make much of the subtlety of GUI colorschemes available to console vim.^["mp
I also like it that it lives in the place where it was started, and starts up quick. So if I'm navigating around in the shell, as per my wont, I can edit a file without interrupting that flow or having to farm that operation out to a different piece of conceptual real estate. Having less things to keep track of is a big plus. Being able to background it is helpful, too, for example if I need to grab the contents of an unexported shell variable via xclip. If I'd spawned a GUI window instead I might have some trouble remembering where that shell was, or might have already closed it.
My main reason for using a gui vim at all is that it makes somewhat more sense as something spawned from a gui app, eg a browser. In practice I never do this, and I suspect that it's fairly equivalent to just have a new terminal window pop up with a new console vim in it. Though there is likely some (window manager) window management functionality that is exclusive to gui implementations. This is pretty similar to the use case you're discussing.
gvim is actually just a basic terminal emulator with vim running in it, and some menus and toolbar buttons up the top.
So if you have a good, full-featured terminal emulator already, you may as well use that instead, since you'll be using the same type of terminal window that you are familiar with across all your terminal sessions.
Another benefit is that it makes it easy to switch to a shell inside vim and then switch out seamlessly.
On Windows I prefer gvim. On Linux it's vim inside gnome-terminal, which is nice and configurable thankyou.
To avoid (or at least minimize) the use of the mouse.
some gvim variations can't handle
some of my hotkeys
some spawn separate window when i try
to compile program
sometimes they simply can't use fonts
like fixed or terminus correctly
(think about "terminus bold" - some
gvim variations simply stretch
"terminus normal" instead of
rendering with the separate font)
cli generally works faster than gui,
especially if running in real
textmode console (not possible on a
mac though)
there are almost no benefits in using
GUI version, and i'd loose ability to
run in screen, ssh, to suspend
process with ctrl+z, and many more.
The main reason I use the command line is that I spend most of my day in a terminal already, and my use of vim reflects this. I do not open up vim for a long while just editing different files then opening others without closing it; I usually open a file or two do a few edits then do some command line tasks, maybe change a directory, and open up vim somewhere else. When using the a gui there is substantial lag when opening the editor. This wouldn't bother me if I opened it once and left it open but I tend to not work that way. So the command line works better for my workflow. Furthermore since there is no real benefit feature-wise of the GUI over the command line and vise-versa, I've always just stuck with the command line since it suited me better.
vim is way more performant with huge files (100-500MB .csv or .xml files in my case).
gvim beats vim hands-down when used to compare files (gvimdiff): setting the font (want more content on the screen?), dragging the window split line (want to see more of one file rather than the other) etc.
Other than that, I haven't seen other mayor differences and use gvim except when working with large files because I find it more handy in a graphical environment (gnome).
Speed of rendering
proper shell integration with
suspend (C-z),
alternate terminal,
uniform copy/paste
nicer quickfix integration (all external programs run inside your terminal, instead of popup windows... )
network agnostic: can run over ssh
using GNU screen, can detach/attach session over internet;
To the sometimes mentioned 'downside':
mouse support is up to par with :se mouse +=a; this enables selection, window border dragging with the mouse, even over GNU screen over ssh
Pair coding via vim + gnu screen is the selling point for me. I work in screen/vim all day, it allows people to remote into my screen session and we can both edit files fluidly. It's so hot right now.
As a big vim user myself, although I know about GUI vims, I don't use them just out of habit.
I've been using vi since 1990, switched to vim a few years ago but still call it through an alias (alias vi=vim).
For me its just habit. vim works well as it is. Perhaps the gui offers more and I should explore it, but vim works just the way I expect it to and want it to.