How to stop these Vim errors? - vim

It seems like almost every time I open a file in Vim anymore, I'll get an error like this:
Error detected while processing /Users/me/.vim/view/=+something=+something=+something...
E518: Unknown option: nomacmeta
The option is usually something different depending on the file. I've done :help view but the results weren't very helpful. Is there some way I can disable this view feature so I can stop getting these errors? I don't have time to run down every one of them.

:help 'macmeta' is an option specific to MacVim. You are having this error because you are sourcing a view script that contains the command set nomacmeta in a Vim that is not MacVim and thus doesn't support that option.
Either…
you are on a Mac but you are using the built-in Vim at /usr/bin/vim, which is not MacVim,
or you are on a Mac but you are using a manually built Vim, which is very likely to not be MacVim,
or you are on some other system where Vim is pretty much guaranteed to not be MacVim.
To prevent those errors, remove any non-cross-platform option from your view scripts and consider reading :help :mkview carefully, specially the part about :help 'viewoptions'.
Also, &macmeta is disabled by default so disabling it doesn't make much sense to begin with.

Related

vim syntax highlighting weirdness

I have some specific settings for my latex highlighting and am using the indentLine plugin, which requires let g:indentLine_fileTypeExclude = ['tex', 'bib'] to avoid the conceal feature annoyance. Anyway, when I start vim with vim filename.tex my vimrc gets loaded properly, but when I simply call vim and then open a given tex file, it'll ignore the vimrc.
Any idea what's causing it? Also, let me know what information you need, as I am far from certain on what would be needed.
EDIT:
Okay so I've found that for both cases i'm in a [tex] environment, but if I'm in a [plaintex] environment then the weirdness doesn't happen. If that helps anyone.
2nd EDIT:
New development, it is only the first file that's opened that seems to ignore the exclusion for indentLine, the remainder are shown exactly as they ought to.
The plaintex is a separate filetype in Vim (cp. :help ft-plaintex), so you need to add it to the IndentLine config:
let g:indentLine_fileTypeExclude = ['tex', 'plaintex', 'bib']
Edit This now looks like a command ordering issue. It's hard to remotely troubleshoot this, as the exact plugins and their initialization order may be important. Please capture a full log of a Vim session with vim -V20vimlog. After quitting Vim, examine the vimlog log file for the ordering of commands (but it might be difficult to see what's happening in a potentially vast list of commands).
It might be sufficient to just reload the first file that has those problems, with :e!.

Warning keep popping when running conque in VIM

When running conque in VIM, the warning message prompts out every time:
Warning:
Global CursorHoldI and CursorMovedI autocommands may cause ConqueTerm to run slowly
I found a method to remove the warning is to comment out the warning-function in the conque_term.vim, but I don't think it's a decent and safe way to solve the problem.
I'm new with VIM, so I found no way to identify the source of problem by myself. Could anyone help? Thanks a lot!
One integration point into Vim is through events, which can trigger automatic commands; the Conque plugin itself uses these to implement its functionality. Events like CursorMovedI are fired whenever you type something or move the cursor in insert mode; this can have an impact on performance, and that's what the warning is about.
You can list all such automatic commands via:
:verbose autocmd CursorHoldI,CursorMovedI
As long as Conque works well for you, it's fine to ignore (and suppress) the warning. But if you indeed run into problems, you'd need to check the other autocmd sources and maybe disable one or the other plugin (at least for the Conque buffer). (See :help autocmd-remove for how to do this.)
Off topic, but using Ctrl+Z to drop back to shell and fg to return to vim seems to work way better than Conque. That is if you're using vim from the terminal, which you should.
Some inspiration: http://statico.github.com/vim.html

What is the difference between gVim and gVim easy?

The question is self explanatory, but I haven't found a single resource that explains what the difference is after an hour of searching. After poking around a little bit in both, it appears that gVim and gVim easy are identical.
Gvim easy is started and locked in insert-mode (every character you type is printed like a simple notepad).
Standard gvim starts in normal mode and you have to toggle between normal/insert like all other vim.
From help:
Easy mode. Implied for |evim| and |eview|. Starts with
'insertmode' set and behaves like a click-and-type editor.
This sources the script $VIMRUNTIME/evim.vim. Mappings are
set up to work like most click-and-type editors, see
|evim-keys|. The GUI is started when available.
{not in Vi}
gVim-Easy, which is installed with gVim, has all the functionality of
normal gVim but lacks modes. This is especially useful for begginers
and people who do not want to, or do not have the time to, learn how
to use gVim. Users can benefit from gVim's superior syntax
highlighting and auto-indentation while not having to have to learn
the, often deemed complex, command set of gVim in order to edit a
simple document. It is recommended that readers of this tutorial at
least try to learn how to use gVim in normal mode, the learning curve
is steep, but, the benefits in speed and usability this confers is
worth the investment.
Read here
gVim Easy: gvim.exe -y (pass a parameter y)
gVim: gvim.exe
It seems that Insert and Replace are available modes, and command mode is missing. And at first glance it appears to have lost the ability to save a document using keystrokes - the File menu shows only ":w" for Save and without command mode, the command simply isn't there. What isn't shown however is Alt-F followed by S - this works, although also missing is the status line confirmation of the file being written.

How to know commands I've been typing?

I'm using gVim and I would like to know if there is a way to see the commands I've been typing.
For example, when I pressed the visual mode (v) I've got message -- Visual --, but I don't know which letters I've been pressing so far.
Is there a way to permanent see which characters/commands I've typing?
You can use this setting:
:set showcmd
Type :help 'showcmd' to read more.
You could set this up:
alias vim="vim -W ~/.last_vim_session_key_pressed"
But this file is written only when you exit vim. You can source it with vim -s but beware, with vim gui versions you can have problems.
Check your home directory for a .viminfo file.
This will have, among other things, a history from newest to oldest of recent commands you've typed.
There is a tricky way to show all vim keystrokes which were pressed by using -w parameter which record all the characters that you type in the file. The problem is, that vim writes keystrokes only when you exit Vim as Benoit already said.
To workaround this, Kana Natsuno came up with this single-line patch, which disables buffering of the -w option, so you have access to realtime stream of keystrokes. Then it's a matter of reading them (e.g. tail -f), parsing or you can try to display them in the statusbar (:set statusline).
Check out a custom build of Vim using Drew's live-stream-keystrokes branch of MacVim, to get the realtime stream of keystrokes.
Source: Vimprint - a Vim keystroke parser at Drew Neil blog
This is useful if you'd like to reveal the Vim pressed keystrokes in live video tutorials (or GIFs).

Vim response quite slow

If I open a file containing 5,000 lines of code and continue to input, I found that my vim became very slow, it displays my input after about 1s.
It even won't become any better after I start up with --noplugin. But after switching my .vimrc file, everything gets fine again. The .vimrc file is written by myself and after checking for some time, I still can't locate the error. I have clear all the key maps, but the problem still exists.
So can you give my any advise or tell my how to debug in vim? I found there is a debug option but can't get how to work.
You can use the --startuptime option when start vim:
--startuptime {fname} *--startuptime*
During startup write timing messages to the file {fname}.
This can be used to find out where time is spent while loading
your .vimrc, plugins and opening the first file.
When {fname} already exists new messages are appended.
(Only available when compiled with the |+startuptime|
feature).
Take following steps to diagnose the problem:
type vim --startuptime log.txt main.java in bash to start vim
type :tabe log.txt in vim to view the log.
The reason for slowness is often the not set or wrong set ruby_path on compile time of vim (see also discussion on google vim/ruby google group). It is easier to set it in vimrc, because you can change it without recompiling vim. You can set the path through the g:ruby_path variable in your .vimrc file. Don't copy and paste both, use the right one.
If you setup RBENV you have to use this one:
" ruby path if you are using rbenv
let g:ruby_path = system('echo $HOME/.rbenv/shims')
If you setup RVM you have to use this one:
" ruby path if you are using RVM
let g:ruby_path = system('rvm current')
You can also use the vim-rbenv plugin, which sets the path too.
For me the part on loading ruby specific functions in vim got 10 times faster.
If you are using jruby, than the start up slowliness can be even bigger. See examples for fixing it here.
If running vim 7.4,
put this in your .vimrc
set regexpengine=1
vim 7.4 has a new regex engine that appear not to work well in some situations. Previous version vim 7.3 used the old engine ( set regexpengine=1 ).
The "slow response" from syntax highlighting problem affects the vim help files as well ( and .vimrc file too ).
Something like this is usually caused by syntax colouring. Try with :syntax off.
Add these lines to your ~/.vimrc or ~/.config/nvim/init.vim:
set lazyredraw " don't redraw everytime
set synmaxcol=128 " avoid slow rendering for long lines
syntax sync minlines=64 " faster syntax hl
Also if you're using tmux, consider adding this to your ~/.tmux.conf:
set -sg escape-time 10

Resources