Starting up vim and then No mapping found shows up at bottom.
running the command: vim -V20logfile
line 3: redir => res
line 4: silent! execute a:cmd
line 5: redir END
line 6: let &verbosefile = oldverbosefile
I had the same issue.
I commented out all maps, thinking they were all fine. Sure enough, vim loaded without err.
Then, I reintroduced the mappings until one broke it. Sure enough I had left out the space between the lhs and the rhs. As soon as I corrected this, it worked perfectly again.
I found the best way to debug your .vimrc is to enable the debug and pip it to a log file. Examine the file and search for the error.
If the error you are receiving is " no mapping found", open the log file and search for the these words.
:/no mapping found.
It will show you where the error is coming from. In my case I found that the error is from a plugin I installed. I disabled it and it works fine again.
Run the following command at the prompt:
vim -V20 2>&1 | tee logfile
Related
prt path <mru>={ files }=<buf> <-> /home/....
Error detected while processing function <SNR>48_NormalPasta:
line 13:
E21: Cannot make changes, 'modifiable' is off
Press ENTER or type command to continue
kind of a strange vim error I get when I try to type the 'p' character using vim & ctrlp, using linux ubuntu here
Let's take that message one line at a time:
Error detected while processing function <SNR>48_NormalPasta:
There is an error in function NormalPasta() in the 48th script that was sourced by Vim.
line 13:
The error is on line 13 of that function.
E21: Cannot make changes, 'modifiable' is off
The function is trying to edit a non-modifiable buffer.
From there, you can do:
:filter 48 scriptnames
or:
$ grep -R NormalPasta ~/.vim/**/*.vim
to find in what script the problematic function is located.
This leads to this plugin, which appears to be OK. The whole situation seems rather strange, though, because the problematic function is supposed to be called from normal mode and I don't think a) that you should be in normal mode at CtrlP's prompt and b) that the CtrlP prompt is supposed to be non-modifiable.
My opinion is that the vim-pasta plugin is OK and thus that there is something fishy going on with CtrlP itself or the way you use it.
I use a msdos-script to search with vim for patterns and show me the result
Script: tel.bat
rem script is called: tel.bat <pattern>
gvim -R %WORKSPACE%\telliste.csv "+set ignorecase" "+set ft=javascript" -c /%1
This works fine if the pattern exist in the file. If the pattern is not matched, I get an error message and I am stuck. No keystroke or mouse action changes the state. Like:
Enter key - has no effect
Esc key - has no effect
Ctrl + C - the error-messages disappears, but the editor is frozen. No action possible
Mouse click in editor - has no effect
I can only close vim and try again. That's what I get as error, when I call the script tel.bat konez on the command line:
Error message translated:
Error during execution of "command line":
E486: Pattern not found: konez
Confirm with the ENTER Key or place a command
How can I work further on the file, even if the pattern is not found? In other words how can I avoid that I am stuck in vim.
I tried already with -c ":execute 'silent !'" in the batch file, but this was not recognized. Perhaps I did it in the wrong way...
This should work, and I cannot reproduce this on Linux with Vim version 8.0.1358; I can accept the error message with <Enter> and continue.
This could be a plugin / configuration issue; try launching with gvim --clean.
The multi-line error message is ugly. You could avoid it by moving to the lower-level search() function:
gvim ... -c "call search('%1')"
By evaluating its return value; you could also craft your own error message: if search(...) == 0 | echomsg 'No matches' | endif
I am using vim and Latex Suite for editing and compiling LaTeX documents.
Quickfix is not able to resolve the error location when compiling with Lualatex (it works fine with the default compile rule).
One error output line in the quickfix window looks like this:
|11 error| Undefined control sequence. askdlfj\jsepackage {icomma}
There is no file specified so it is no surprise that vim can not go to the error. I am using the following compile rule in .vimrc:
let g:Tex_CompileRule_pdf = 'lualatex -synctex=1 -src-specials -interaction=nonstopmode $*'
I've been trying to solve this for hours so any ideas are welcome.
I found a solution myself. "man luatex" (not lualatex) says:
--file-line-error
Print error messages in the form file:line:error which is similar to the way many compilers format them.
So the correct compiler rule shoudl be
let g:Tex_CompileRule_pdf = 'lualatex -synctex=1 -file-line-error -interaction=nonstopmode $*'
I am using command :%s/foo/bar/g | wq to find and replace using vim. It works fine if pattern is available but if pattern isn't available it Error detected while processing command line:
E486: Pattern not found: foo
How can I forcefully exit even if pattern isn't found? I tried wq! in above command but didn't help
The problem is with substitute issuing the error. You can set the flag e
:%s/foo/bar/ge | wq
which should prevent the "No match" error from breaking a mapping or commands.
:h :s_flags
Every time I tried to exit with :q it gave me an error message "E486: Pattern not found:..."
If I press ":" it appears "?" and instead of :q appeared ?q and gave me the error message: "E486: Pattern not found:..."
Cause? Instead of the US keyboard, I had set the Romanian (Standard) keyboard.
And instead of ":" type "ș" (special Romanian character).
I set back to US keyboard and everything was solved.
When I load vim I get the following message that I cannot figure out how to debug.
4FNVHQ1|tmp
λ vim
default
Press ENTER or type command to continue
4FNVHQ1|tmp
λ
I've run vim -V9myVimLog and got this in the output but there's still nothing useful to me.
....
chdir(/c/Users/bjones/.vim/bundle/vundle/autoload/vundle)
fchdir() to previous dir
line 5: sourcing "/c/Users/bjones/.vim/bundle/vundle/autoload/vundle/config.vim"
finished sourcing /c/Users/bjones/.vim/bundle/vundle/autoload/vundle/config.vim
continuing in function vundle#rc
default
Searching for "filetype.vim" in "/c/Users/bjones/.vim/bundle/vim-javascript,/c/Users/bjones/.vim/bundle/vim-coffee-script,/c/Users/bjones/.vim/bundle/vim-jade,/c/Users/bjones/.vim/bundle/nerdtree,/c/Users/bjones/.vim/bundle/vim-rails,/c/Users/bjones/.vim/bundle/vim-commentary,/c/Users/bjones/.vim/bundle/vim-rake,/c/Users/bjones/.vim/bundle/snipMate,/c/Users/bjones/.vim/bundle/bsh.vim,/c/Users/bjones/.vim/bundle/vim-csharp,/c/Users/bjones/.vim/bundle/vim-distinguished,/c/Users/bjones/.vim/bundle/surround.vim,/c/Users/bjones/.vim/bundle/ctrlp.vim,/c/Users/bjones/.vim/bundle/jshint2.vim,/c/Users/bjones/.vim/bundle/vim-ps1,/c/Users/bjones/.vim/bundle/MatchTag,/c/Users/bjones/.vim/bundle/VCard-syntax,/c/Users/bjones/.vim/bundle/vim-liquid,/c/Users/bjones/.vim/bundle/vim-jst,/c/Users/bjones/.vim/bundle/vim-stylus,/c/Users/bjones/.vim/bundle/vim-swigjs,/c/Users/bjones/.vim/bundle/xmledit,/c/Users/bjones/.vim/bundle/vim-less,/c/Users/bjones/.vim/bundle/vim-markdown,/c/Users/bjones/.vim/bundle/vim-nerdtree-tabs,/c/Use
Searching for "/c/Users/bjones/.vim/bundle/vim-javascript/filetype.vim"
Searching for "/c/Users/bjones/.vim/bundle/vim-coffee-script/filetype.vim"
....
As you can see the word "default" is printed awkwardly in the debug log but there's nothing helpful.
Any help would be greatly appreciated.
EDIT: My vimrc is here: https://gist.github.com/brettof86/9906968
EDIT2 [FIX?]: IDK how it made a difference but I commented out every "Bundle" command in my vimrc then saved and quit. Then I went back and uncommented them 5 at a time and it started working? I have no idea why it was broken but I hope this helps anyone who may also run into this issue.
You mistakenly added an extra line colors in your vimrc, that as an VIM Ex command outputs the current selected colorscheme and since you haven't defined one yet, it outputs default since that is, as the name suggests, the default VIM colorscheme. You should comment it out since it clearly appears to be a documenting comment rather than executing an Ex command.