So in vim all kinds of scrolling works perfectly, but in Gvim when scrolling screen flickers, especially noticable on faster scrolls like pgdn/pgup, Ctrl+U and Ctrl+D. Same thing when I scroll by dragging slider with mouse. I tried different background colors, but it does not make any difference.
Any ideas how to fix this?
Ask the developer(s) to make sure that a screen redraw is double-buffered.
I remember running into this years ago when I was using plain, non-antialiased X11 draw calls in Gvim (around version 6.0). In that case, the drawing speed was not-noticeable. When using anything anti-aliased, I could observe the flicker.
Obviously, the double-buffering is not necessary for the original terminal code and I'm assuming that the GUI updates are derived from the original terminal update code.
NOTE: This answer is only here for a reference for future development.
I have encountered similar problem in Gvim on windows. During scrolling bottom and top line flickers, it's even worse with e.g. 10j.
I have been able to eliminate it completely by adding lines in my .vimrc:
set lazyredraw
nnoremap <silent> j j:redraw<CR>
nnoremap <silent> k k:redraw<CR>
My current workaround is to use Vim-Qt, which is a fork of Vim with the GUI being based on Qt instead of GTK. Although it does have some shortcomings like lack of scrollbars, lack of maintenance (last commit 2 years ago), its advantage is that it doesn't flicker at all.
My fork of Vim-Qt now implements the scrollbars, so if you need them, you may want to try it instead of original Vim-Qt.
Related
Sometimes, when switching between windows in screen, my vim gets messed up and e.g. my actual and shown cursor position don't match up (by 1 line), which is infuriating. I tinkered around a bit and its probably because of vim-airline being too long for the terminal. You can see the reason for my suspicion in the following image. Notice the orange rectangles in the lines below the airline. FYI, here is my minimized vimrc.
Switching tabs fixes the bug temporarily, but it's not a long-term solution.
I'd appreciate any help.
I tried to do syntax highlighting in vim, but I've got weird color highlighting letters on blocks. On black, it is not much of a problem, but when it's sunny blue, it's not readable, so I would prefer a light background.
~/.vimrc does not seem to respond to set background=light if there is no colorscheme.
I'm not very proficient with vim, and I think I might have turned on a function inadvertently, by accidental key strokes. Is there a way to turn off all kind of search and highlight?
I'm reading readmes, but this makes it difficult. The image below shows my screen.
I've heard about such incomplete screen updates occurring then the value of $TERM isn't right. Especially inside a screen / tmux session, be sure to have set the correct value (screen-256color in that latter case).
You could try GVIM (the non-terminal GUI version of Vim) to get moving with your work; it shouldn't have those issues.
I think I might have turned on a function inadvertently, by accidental key strokes
Fear not, any settings only persist by editing the ~/.vimrc file (or by saving a session). You'll always get a clean new instance by quitting and re-starting Vim.
How do I need to adjust my vimrc to make vertical scrolling smoother? I want to achieve that one iteration of the mouse wheel just scrolls one instead of three lines.
try adding this into your vimrc:
map <ScrollWheelUp> <C-Y>
map <ScrollWheelDown> <C-E>
P.S. the best solution would be: don't use that mouse-wheel...
The relevant information is at :help scroll-mouse-wheel:
For the Win32 GUI the scroll action is hard coded. It works just like
dragging the scrollbar of the current window. How many lines are scrolled
depends on your mouse driver. If the scroll action causes input focus
problems, see intellimouse-wheel-problems.
For the X11 GUIs (Motif, Athena and GTK) scrolling the wheel generates key
presses <ScrollWheelUp>, <ScrollWheelDown>, <ScrollWheelLeft> and
<ScrollWheelRight>.
So, if you're on Windows, you can only influence this globally through your driver, whereas on X, you can do
:map <ScrollWheelUp> <C-Y>
etc.
Is there an autocmd for when the preview window is opened/closed?
I want to scroll the main window n lines up when it the preview window is opened, then n lines down when it is closed, to counteract the "moving text" effect that occurs natively.
Am I able to do this with the relevant autocmd (and what is it), or is there a better way for me to achieve this?
There is no such autocmd event. But you can use WinEnter and BufDelete associated with previewwindow option to achieve something similar.
Using WinEnter you can check previewwindow; if you are on preview window, you can set a buffer variable to differ this event from subsequent events that can be generated by moving to another window and back to preview window. You can also set au BufDelete <buffer> call MyRestoreMainWindow() to call your function when preview window is closed.
I see this question asked often and always scratch my head wondering what is that window-shifting people talk about that I don't experience.
Well, today it occurred to me that two options that I've added to my ~/.vimrc a long time ago have the pleasant side effect of preventing that dreaded window-shifting:
set splitbelow
set splitright
Give it a try!
I was actually wondering the same thing except with the tab bar -- how to prevent that annoying shift from occuring when the tab bar is shown or hidden. Have you considered a wrapper function? The following seems to work for the ps example (it will still cause a shift if the preview window would obscure the cursor)
se splitbelow splitright
fun! PsWrapper(text)
let view=winsaveview()
exe 'ps' a:text
call winrestview(view)
endfun
While we're here ... the tab bar case seems to require some black magic. Ie, as someone pointed out, the tabbar will cause the text to scroll down if the cursor is above the middle line (??). But this seems to work - to always show a tab bar:
let [view,g:stal]=[winsaveview(),&stal]
let [view.topline,&stal]=[view.topline+!g:stal,2]
call winrestview(view)
and to restore the original tabbar setting
let [view.topline,&stal]=[view.topline-!g:stal,g:stal]
call winrestview(view)
You can't really do this with a simple autocmd - Using the WinEnter/WinLeave/BufEnter/BufLeave auto commands all have minor quirks (stated in the vim documentation) so they won't consistently solve your problem completely.
If this happens to you when opening splits, then you can solve this like #romainl suggested, by defining in your .vimrc :
set splitright
set splitbelow
BUT... This will still happen when opening various 'preview' windows, or using the quickfix or location list windows vim has to offer. I use them a lot, and this problem really annoyed me, so I wrote a plugin to solve this.
You can check it out here: https://github.com/gillyb/stable-windows
It works by maintaining state of the cursor position and top line number of the windows open in your vim layout, and restoring them each time you switch to a different buffer.
It's relatively new (as of writing this answer) so if you find any bugs feel free to open an issue, and I will try to address them quickly.
Hope this helps! :)
When I type :!ls, for example, and see the result, it shifts up the current window to make space for it.
I've been annoyed by how the whole content moves up and down. I'm wondering if there's a way to fix that in either vim or gvim 7.3 - like in Emacs.
So for example, if I have lines 1~30, and the message area takes up 5 lines, I want my code window to show lines 1~25 instead of 6~30. That's what Emacs does, I think.
Thanks.
As far as I am aware, this is not possible in vim. However, there are ways to get around it. You can use screen or tmux and use that to create a lower window to execute commands in. You can also take a look into conque, which simulates a terminal within vim.