I've got the (Mac)Vim Syntastic plugin installed via Janus. When I open the :Errors window to view the reason for syntax errors, it shrinks the file with the errors to one line and uses the rest of the real estate for the Errors window.
Is there a way to make it hog less room for errors and more importantly, how do I close just the Errors window? The usual :q closes both the Errors window AND the original file, even if the cursor is in the Errors window. (That's not 100% correct -- it gratefully does not close the file if the file hasn't yet been saved).
Syntastic uses the location list (a window-local variant of the quickfix list), so a :lclose will close it, but keep the other buffers.
As per syntastic's help pages, the initial height can be configured:
:let g:syntastic_loc_list_height=5
But I suspect that your intrusive Janus distribution has a hand in that. Vim "distributions" like spf-13 and Janus lure you with a quick install and out of the box settings, but you pay the price with increased complexity (you need to understand both Vim's runtime loading scheme and the arbitrary conventions of the distribution) and inflexibility (the distribution may make some things easier, but other things very difficult). Vim is incredibly customizable, using someone else's customization makes no sense.
The command to close the Syntastic error window is:
:SyntasticReset
Syntastic gets confused when you're juggling multiple buffers on one screen so here's a script that will collect information about the situation, then do the right thing:
function JustCloseSyntasticWindow()
"Check which buffer we are in, and if not, return to the main one:
if &ft == "qf"
normal ZZ
endif
"Since different buffers have different command spaces, check if we've
"escaped the other buffer and then tell syntastic to stop.
if &ft != "qf"
SyntasticReset
" --- or ----
SyntasticToggleMode
endif
endfunction
au FileType buffer1_ft nnoremap :yourcmd<CR>:call JustCloseSyntasticWindow()<cr>
au FileType main_win_ft nnoremap :yourcmd<CR>:call JustCloseSyntasticWindow()<cr>
Don't be shy on the duct tape for this job, it's the only thing holding the unit together.
You can use :lclose to close it.
Related
I am new to Vim and NERDTree, and I am trying to understand why a buffer appears as [No name] after I delete it using :bd. I want to keep my NERDTree clean so I wonder if there is a way to remove the [No name].
For example,
The l.py file is the one I am working on, and the [No name] ones are the files that I already closed (with :bd). I don't want them to show up at all because it looks messy.
Thanks!
I doubt NerdTree is putting buffers into your status line. I imagine some status line plugin like vim-airline. It would probably be best to look at your status line plugin's documentation for how to make customizations or submit an issue on the plugin's bug tracker.
We need to talk...
The biggest problem I see is that you are trying to use the status line as a makeshift "tab bar". Most other editors use a tab bar as a way to manage documents, but not Vim. This makeshift "tab bar" is probably a bad idea once you start using more files or more complicated workflows with splits or tabs (Vim's tabs are different).
Oh yeah? What about Buftabline, Airline, BufTabs, MiniBufExpl, ...?
All these plugins do is show you your currently listed buffers. Maybe with some kind of positioning information so that you feel comfortable cycling via :bnext and :bprevious (or whatever mappings you might be using) through your buffer list.
Now that is great and all, these plugins have recreated other editor's version of tabs, but Vim already let you cycle through buffers without these plugins. The only thing missing was a menu which :ls will gladly do for you without wasting any screen real-estate.
Imagine having 10, 25, 50, or 100+ buffers open. How is your Buftabline going to handle that? My bet is not well. You need to stop reaching for simple tools like :bnext / :bprev and start reaching for a power tool like :b.
Behold the power of :b
The :b command can take a buffer number to switch directly to a buffer. Far more interesting, :b can take a partial filename.
:b partial-name
Need more power in your :b?
Uses tab completion
Uses <c-d> to list out completions
Accepts globs. e.g. :b *foo
Use ** to descend into directories. e.g. :b foo/**/bar
Don't forget to add set hidden to your vimrc. See :h 'hidden'
Why ride a bike when you can fly?
taken from Bairui's collection of Vim infographics.
You can use a simple mapping to leverage both :ls and :b:
nnoremap <leader>b :ls<cr>:b<space>
Now you can travel directly to you buffer you want. No more cycling.
But I like plugins
Who doesn't like a good plugin. As a matter a fact if you are looking for a nice buffer switching plugin then I would recommend you look into a nice fuzzy finder like CtrlP to aid you in switching between buffers. A fuzzy finder actually adds value to switching between buffers by getting you there faster with less typing.
Conclusion
Eventually you workflow will require you to use more than 3 buffers at a time. At that moment I would suggest you take another look at the :b command or at the very least get a nice fuzzy finder. It will save you time and effort.
So stop riding your bike when you can fly.
Is there any way to stop vim from automatically updating folds on the fly? I really love vim's folding, and I prefer having it in syntax mode so that folds are created as I type. But for instance when I code C++ and I write a bracket { it automatically closes all subsequent folds, and when I then close the bracket again with a }, vim automatically expands all subsequent folds, meaning that I have to refold everything.
Another related problem, if I have the same document open in a different buffer, say I have run ":split", then writing an open bracket { will nest all folds in the buffer under the fold in which I opened the bracket, and closing it will un-nest the folds but also close all of them. If I use either "." or "->" to access a member function/variable, it resets all folds in the buffer to be whatever the current foldlevel is, regardless of which folds I have opened/closed myself.
This is somewhat frustrating when I have the same document open in two buffers so I can read the contents of one function when writing another, as I constantly have to switch buffers and reopen my folds.
In my .vimrc I have
set foldmethod=syntax
and that is about it. For autocompletion I use clang-complete and supertab with:
let g:SuperTabDefaultCompletionType = "<c-x><c-u><c-p>"
I think that is everything which migh affect this.
Edit:
Added some pictures to help illustrate the problem
Both problems can be solved with the following two autocmds:
autocmd InsertLeave,WinEnter * setlocal foldmethod=syntax
autocmd InsertEnter,WinLeave * setlocal foldmethod=manual
This sets the buffer local 'foldmethod' to manual when insert mode is entered or its window (a buffer display) is left, and sets it to syntax when insert mode is left or its window is entered.
This works because setting 'foldmethod' to manual will keep the folds automatically created by syntax as if you set them yourself (manually), and manual folds are not updated based on the syntax of the file.
I've found two bugs with this solution:
When switching windows while in insert mode, the autocmd will set the 'foldmethod' to syntax for the new window, even though it's in insert mode and should be set to manual.
This isn't really a problem for me because I use Vim like a civilized person and operate in normal mode by default.
When
a new buffer is created (e.g. by reading a file)
and 'foldlevel' is 0
and a particular syntax is used (I'm able to duplicate the issue with a C file)
and the o or O command is used to enter insert mode for the first time in that buffer (doing i<esc>o does not duplicate the bug),
then all folds below the cursor will be opened.
I accidentally discovered this when testing the above solution, and now looking back I'm surprised I found it; it's almost not even worth mentioning. I don't intend on trying to write a test file that has the exact syntax necessary to duplicate the bug, so this may go unnoticed for another eon.
I actually discovered this question several months ago and used the solution Ben linked to for a while, before eventually being annoyed enough with the multiple window for one buffer issue (your second problem) to fix it.
So thanks to Ben for his solution, and you for asking this question!
I made a bit of a modification to user4830797's answer which helps deal with situations where the file you're editing doesn't use foldmethod=syntax (for example, a .vimrc file which might use foldmethod=marker):
autocmd InsertLeave,WinEnter * let &l:foldmethod=g:oldfoldmethod
autocmd InsertEnter,WinLeave * let g:oldfoldmethod=&l:foldmethod | setlocal foldmethod=manual
I think you need to check :h 'foldlevel. You should also perhaps use :mkview, probably in autocmd which restores manually open and closed folds.
Other then that you should perhaps set folding method differently on different file types (for instance on C you could set it to manual or marker)
If you temporarily set the foldmethod to manual, then Vim will keep all the folds currently defined by syntax, and keep them in the exact open/closed state you have them in now. This can be done automatically with an InsertEnter autocmd and restored on InsertLeave to protect your fold states in a single window. Unfortunately I have not yet spent time trying to get it working in split windows, but using window-local variables it is easy enough to even account for the user switching windows or something without leaving insert mode. See http://vim.wikia.com/wiki/Keep_folds_closed_while_inserting_text for details and discussion.
I love Vim. But its giving me hard times right now.
I use a lot of plugins and during the last 6 months, I've found a lot of awesome ones. But my Vim got really sluggish too. I do constant cleanups, but it doesn't help much.
I'm at the point, where Vim is completely unusable. It feels like it renders at 2-5 frames per second, switching tabs/buffers takes about a second, scrolling with hjkl is awfully terrible, the lag is so bad, even typing a sentence in insert mode is confusing (due to lag).
Edit: Actually, when I open fresh instance of Vim its OK-ish, but than within 15 minutes it becomes unusable.
I've just spent 4 hours trying to figure out which plugin or config is causing the pain. I was unsuccessful.
However, I did find out, that removal of this setting causes all the lag to go away:
syntax on
These 3 lines in conjunction with syntax make everything even worse.
set t_Co=256
set background=dark
colorscheme candyman
Interesting. So, syntax highlighting is turning Vim from super snappy to incredibly sluggish?
I tried enabling syntax in "clean" mode:
vim -u NONE
And its not an issue there.
So what seems to be the issue is Syntax Highlighting in combination with one or more of my plugins. I tried disabling bunch, no luck.
Is there any way to do profiling? I'm fairly exhausted from manual testing.
Has anyone had similar experience? Maybe take a quick peek into my .vimrc, see if anything rings a bell.
https://bitbucket.org/furion/dotfiles
SOLUTION:
The plugin causing the mess was:
Bundle "gorodinskiy/vim-coloresque.git"
I recommend reading the answers tho, good insights.
Edit (1 month later): The coloresque plugin has seen some improvements.
EDIT: Blogged about how this all works, with screenshots and awesome-sauce.
https://eduncan911.com/software/fix-slow-scrolling-in-vim-and-neovim.html
Original answer below...
:syntime on
move around in your ruby file and then
:syntime report
It reported the following slowest matching for me, and you can see that there are not even 1 match.
I disabled rubyPredefinedConstant in ruby.vim file and problem solved. Vim regex engine does not like something in ruby syntax highlight regex. You will have to find the balance between enough syntax highligting and a good performance.
Here is the top 3 slowest syntax highlighting regex for ruby reported on my Mac OS 10.8.5, homebrew Vim 7.4 (console vim)
TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
3.498505 12494 0 0.008359 0.000280 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(STDERR\|STDIN\|STDOUT\|TOPLEVEL_BINDING\|TRUE\)\>\%(\s*(\)\#!
2.948513 12494 0 0.006798 0.000236 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(MatchingData\|ARGF\|ARGV\|ENV\)\>\%(\s*(\)\#!
2.438253 12494 0 0.005346 0.000195 rubyPredefinedConstant \%(\%(\.\#<!\.\)\#<!\|::\)\_s*\zs\%(DATA\|FALSE\|NIL\)\>\%(\s*(\)\#!
Or you can try vim-ruby as pointed out by Dojosto
You have autocmd spam. You should wrap all of your autocmd statements in groups which clear the group before re-adding the autocmds. It looks like your .vimrc has most autocmds commented-out, so maybe there is a plugin that is causing the issue. Check the output of this command:
:au CursorMoved
If there's a bunch of duplicate handlers there, that's your problem.
Here's an example of autocmd discipline from my .vimrc:
augroup vimrc_autocmd
autocmd!
"toggle quickfix window
autocmd BufReadPost quickfix map <buffer> <leader>qq :cclose<cr>|map <buffer> <c-p> <up>|map <buffer> <c-n> <down>
autocmd FileType unite call s:unite_settings()
" obliterate unite buffers (marks especially).
autocmd BufLeave \[unite\]* if "nofile" ==# &buftype | setlocal bufhidden=wipe | endif
" Jump to the last position when reopening a file
autocmd BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g`\"" | endif
" ...etc...
augroup END
The autocmd! at the beginning of the augroup block clears out the current group (vimrc_autocmd, in this case) before re-adding the autocmds.
From another stack overflow question, I get vim fast by adding the following line in .vimrc file:
set re=1
This will force vim to use a older version of regex engine and it is actually FASTER for ruby.
I found that "set foldmethod=syntax" makes 7.4 almost unusable slow e.g. for js&ruby files (ubuntu 13.10) whereas "set foldmethod=indent" works fine.
I've noticed that vim can slow down to a halt if you're using anything that dynamically changes the background color. Try turning off :set cursorline or :set cursorcolumn (if you have them set).
I'd like to thank everyone helping me out on this issue. Good news is, my Vim is snappy again.
I've started with fresh Vim re-install. I've than added plugin by plugin, until I found the root of all evil.
Bundle "gorodinskiy/vim-coloresque.git"
Its a plugin that was causing me all this pain. Since I had it for a while, it wasn't a suspect, thats why I discovered it so late.
What this plugin does, is whenever it finds a word for color (eg red, green), or hex value (eg. #FFFFFF), it sets background color of the text to match the color that its describing. Brilliant idea, but seems like poor implementation.
Removing this plugin removed the lags.
But I didn't stop here. I've done a major cleanup of my .vimrc as well. Removed some more plugins I hadn't used. Grouped my autocmds and removed unnecessary ones.
My Vim is very snappy now. I'm happy again.
Syntax highlighting can be slow, but that should be limited to some (somewhat pathological) files, and particular syntax(es). The latest Vim 7.4 has a new command :syntime to troubleshoot syntax highlighting slowness.
Apart from that, often, a binary search where you disable half of your plugins, then only one half of that (when the problem is still there), or the other half (when the problem vanished) lets you get to the problematic script quickly.
I'm pretty sure that
set t_Co=256
set background=dark
colorscheme candyman
have nothing to do with that lag. The two first lines are useless (the number of usable colors is defined according to your $TERM and your colorscheme already does set background=dark) but not really harmful.
Common "Vim is slowing to a crawl" causes include poorly written autocmds, too many autocmds, reloading one's ~/.vimrc too often, poorly written plugins…
Please post your setup so that we can help you find out why you experience that lag.
I have had this problem for a long time, and it was driving me crazy. I tried installing vim-ruby. Not sure if that helped but at least now I have the most up-to-date version of ruby syntax highlighting (with any performance improvements since the last version of Vim was released).
But then I looked further, and discovered that vim-ruby has a mode that skips all the expensive highlighting. Try adding this line to your vimrc and see if it helps (it did for me, finally!):
let ruby_no_expensive=1
For me that was set relativenumber feature which was slowing it down. Try to disable it with set norelativenumber and test.
Just in case it helps anyone out there:
I had accidentally created an extremely large tag file for my project; so my syntax highlighter was searching the large file to highlight function names.
So check your tag file! (In my setup I was using easy-tags so mine was placed at ~/.vimtags
Very late, but I figured this may help someone in a similar boat as me.
The plugin vim-nerdtree-syntax-highlight turned out to be lagging my entire editor. They do mention on their Github that people have reported lag issues, and offer some solutions.
So if anyone happens to be using that plugin, try using some of the fixes listed; this one works, but you need to be selective about which languages you want to keep:
let g:NERDTreeSyntaxDisableDefaultExtensions = 1
let g:NERDTreeDisableExactMatchHighlight = 1
let g:NERDTreeDisablePatternMatchHighlight = 1
let g:NERDTreeSyntaxEnabledExtensions = ['c', 'h', 'c++', 'php', 'rb', 'js', 'css']
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! :)
I'm a pretty new Vim user and I've found that its learning curve is quite steep (at least for me). I just installed this vim script for JavaScriptLint error checking, which shows errors in vim's quickfix window once I save a buffer.
However, I don't know what to do next.. How do I 'scroll' through all the errors? How do I close the quickfix 'window'? How do I get it to check for errors after I've made changes to my code?
I've looked at the vim quickfix docs but the amount of commands are overwhelming and I can't seem to find what I want. Any help would be appreciated.
A side question: is there any way to have javascriptlint check for js errors for code residing in a .html file?
There are a lot of commands for quickfix as you have said, but I tend to find I only use a small subset of them:
:copen " Open the quickfix window
:ccl " Close it
:cw " Open it if there are "errors", close it otherwise (some people prefer this)
:cn " Go to the next error in the window
:cp " Go to the previous error in the window
:cnf " Go to the first error in the next file
:.cc " Go to error under cursor (if cursor is in quickfix window)
I tend to use this with :make and :vimgrep, so I can't comment on the Javascript lint checker, but this should give you something to get started.
Regarding the general use of JavascriptLint, I'm not a javascript programmer, but it looks like the script exposes a function called "JavascriptLint", so if you want to call it manually, you can use :call JavascriptLint(). However, it works on the disk copy of the file, so it'll have to be saved first. If (and only if) the command line jsl works on html files, you should be able to use :call JavascriptLint() on an html file to check the internal javascript. You could also do:
autocmd BufWritePost,FileWritePost *.html call JavascriptLint()
to automate it. If jsl doesn't support html files, then (short of patching the application or asking the author to change it), it's probably a lost cause...
The easiest way to navigate the quickfix list (or the location list, for that matter) is the unimpaired plugin.
Once the quickfix window is populated, [q and ]q go forward and back (respectively) in the quickfix list. [Q and ]Q go to the beginning and end (which is especially handy if you only have one item in the list; this makes vim complain about [q and ]q). So the workflow is:
Run whatever command populates the quickfix list
Type [Q to go to the first item
Scroll through subsequent items (if any) with [q and ]q
If you're using Syntastic, you'll get the location list instead of the quickfix list. No problem; just use [L, ]L, [l, and ]l in the same way.
unimpaired has loads of other handy mappings too -- [e and ]e "bubble" lines up and down, [<Space> and ]<Space> insert blank lines above and below, etc. I was surprised nobody mentioned it here before; that's probably because it didn't exist until January 2010, though the question was asked in 2009.
Put the following two lines in your .vimrc file:
map <C-j> :cn<CR>
map <C-k> :cp<CR>
Now you can navigate through the errors using ctrl-j and ctrl-k, which mimics the standard down and up motion commands j and k.
You can also use :cc 2 (or any other number) to jump to, in this case, the second error in the quickfix window. Navigating with :cn, :cc 4, etc will put the cursor on the line in question.
In addition to #DrAl's great answer about how to open and close the quick window and navigate between entries, I made an image to show some of the other quick fix navigation commands.
Each group of 3 files below represents a set of quickfix results, e.g. from a vimgrep. cnewer and colder are for going through historic result sets.
Maybe this option didn't exist when this question was written (or maybe I'm embarrassing myself because there's something in my .vimrc that makes this happen) but when I get a Quickfix List, I just navigate it with j and k then hit <CR> (i.e. the Enter key) to jump to that place in the file.
Then, to get back to the Quickfix List I type Ctrl+W j for "move down a window" and I'm back.
Finally, when I'm done, I just type :q, like I would to close any normal window.
The best-practice way of integrating JavaScript syntax-checking is using the Syntastic Vim plugin, which is using Vim's location-list (which is parallel to the quickfix) window.
I've written answers for this question and this question explaining how to do it, plus also how to get source-code browsing / tag-list for Vim using the community-driven jshint.com (which is way better than JSLint IMO) and Mozilla's DoctorJS (formerly jsctags).
the quickfix window is operated mostly like any other vim window: j down a line, k up a line, :cn to jump to the next error/warning, etc.
experiment!
Although this requires > Vim 7.4.858, the cdo (or ldo for location lists) command allows updating a non-contiguous set of lines in a way you could once only do with sed:
:vimgrep /re/ %:p
:cdo! norm #a
# or
:cdo! s/re/repl/
The above shows running a recorded macro or a simple search and replace. Missing seems to a be a way to pipe through and external command as you can with :range! command