I'm using :make from vim and ending up jumping to the file with issues.
Recently, at least I noticed with gcc 4.6.1, vim jumps to incorrect file/line because it goes to the first reported line which has "In file included from ABC.h|5| 0," and there is no file called "In file included from ABC.h".
There is a solution to extract just the file name from the above line, ABC.h in this case, but that does not solve the problem as the problematic file is only included there.
Usually the next line indicates where the issue is and that's where I would like to jump:
MyDir/FGH.h|56 col 32| error: 'bad bad thing happened here'
Is there a known fix for this in vim?
This a bug that is solved on new versions of Vim: Bug report logs - #62169.
You can use the following setting to solve the problem without upgrading Vim:
set errorformat^=%-GIn\ file\ included\ from\ %f:%l:%c:,%-GIn\ file
\\ included\ from\ %f:%l:%c\\,,%-GIn\ file\ included\ from\ %f
\:%l:%c,%-GIn\ file\ included\ from\ %f:%l
(setting extracted from latest Vim source code, from file src/option.h)
:make! doesn't jump to the first result.
The problem is with slight differences in the errorformat required for recent versions of gcc.
I believe this was mentioned in C++ Lounge (chat) the other day, and an errorformat was posted that supposedly works better. I haven't tested that it does:
https://chat.stackoverflow.com/search?q=errorformat&room=10
errorformat=%*[^"]"%f"%*\D%l: %m,"%f"%*\D%l: %m,%-G%f:%l: (Each undeclared identifier is reported only once,%-G%f:%l: for each function it appears in.),%-GInfile included from %f:%l:%c:,%-GIn file included from %f:%l:%c\,,%-GIn file included from %f:%l:%c,%-GIn file included from %f:%l,%-G%*[ ]from %f:%l:%c,%-G%*[ ]from %f:%l:,%-G%*[ ]from %f:%l\,,%-G%*[ ]from %f:%l,%f:%l:%c:%m,%f(%l):%m,%f:%l:%m,"%f"\, line %l%*\D%c%*[^ ] %m,%D%*\a[%*\d]: Entering directory `%f',%X%*\a[%*\d]: Leaving directory `%f',%D%*\a: Entering directory `%f',%X%*\a: Leaving directory `%f',%DMaking %*\a in %f,%f|%l| %m
Related
I have a local Makefile which simply calls make -C ... As a result I get the output from the compiler with filenames and path to the directory relative to ...
Now vim isn't able to get the correct path for quickfix.
Q: How can I set the base path for vim quickfix to .. ?
My path structure:
<bla>/base/proj1/<localMakeFile>
<bla>/base/<globalMakefile>
<bla>/src/source1.cpp
I compile inside /base/proj1/
Compiler output for a error is like:
src/source1.cpp|141 col 54| Error: ....
But I am working in
/proj1/ so vim is unable to get the file src/source1.cpp
EDIT:
I see that the problem is basically related to the output of gnu make
make[4]: Entering directory '<bla>/...'
which is not parsed correctly if I use not an English environment. Setting the shell with export LANG= all works fine.
Q: Can vim parse also the German output of gnu make?
Appending the localized version with set errorformat+=<localized version> should work.
I am not aware that VIM supports it out of the box. After looking at the output of :set errorformat, which on my machine is a scary...
errorformat=%*[^"]"%f"%*\D%l: %m,"%f"%*\D%l: %m,%-G%f:%l: (Ea
ch undeclared identifier is reported only once,%-G%f:%l: for ea
ch function it appears in.),%-GIn file included from %f:%l:%c:,
%-GIn file included from %f:%l:%c\,,%-GIn file included from %f
:%l:%c,%-GIn file included from %f:%l,%-G%*[ ]from %f:%l:%c,%-G
%*[ ]from %f:%l:,%-G%*[ ]from %f:%l\,,%-G%*[ ]from %f:%l,%f:%l:
%c:%m,%f(%l):%m,%f:%l:%m,"%f"\, line %l%*\D%c%*[^ ] %m,%D%*\a[%
*\d]: Entering directory %*[`']%f',%X%*\a[%*\d]: Leaving direct
ory %*[`']%f',%D%*\a: Entering directory %*[`']%f',%X%*\a: Leav
ing directory %*[`']%f',%DMaking %*\a in %f,%f|%l| %m
...and by changing the output of the build process from
make: Entering directory `<directory>`
to
make: Entering `<directory>`
i got it to work by extending errorformat like this:
:set errorformat+=%D%*\\a:\ Entering\ %*[`']%f'
I am trying to override a markdown file syntax by placing the following file md.vim in my after/syntax directory. md.vim contains the following code:
syntax region mdNote start=/\<\cNOTE\>/ end=/\r/
highlight def link mdNote Todo
I have tested that the code works by sourcing it directly but when I launch a file with an extension .md, the mdNote syntax does not work. For example, given the following markdown file:
# Main Heading
Note: This is a note
If I put the cursor inside the word Note and get the syntax group, I get:
mkdNonListingItemBlock which comes from the plasticboy/markdown plugin that I have installed.
Does anyone know why my syntax file is not working?
Markdown files will reference the markdown.vim file in after/syntax. To get this information for any file, you can open a file of the desired format and run :set syntax?. Rename your file to markdown.vim and it should work.
I've recently seen this error whenever I hit autocomplete macros in Vim (e.g. ctrl-n):
E431: Format error in tags file "tags"
The tags file is generated with Exuberant Ctags and it's about 1MB. How do I find the error that's triggering this error?
I found some extra lines present before !_TAG_FILE_FORMAT line in the generated tags file.When i remove these extra lines, vim starts working.
Really long function names can cause this error. You can find these functions by opening the tags file in vim and looking for method names longer than 50 chars.
/^[^\t]{50,}
I think ctags has a problem with parsing java script files. Excluding it from tagging fixed this problem for me.
ctags -R --exclude=*.js .
The tags database is line-oriented; after the header (line(s) starting with !_TAG_FILE_...), each line corresponds to a tag.
By using binary search, you should be able to quickly locate the offending line(s): Save a copy of the tags file, remove one half, test. If you still get the error, repeat (until you're down to one line). Else, take the other half and repeat.
This is a general troubleshooting technique; for example, it's also helpful to locate problems in Vim plugins (by disabling one half of them).
Fixed it by generating tags only for git files.
git ls-files | ctags --links=no --languages=javascript,java,python -L-
In addition to jaster's answer:
I found this, which states that lines longer that 512 characters break vim:
1. Keep the text short, because:
- The line length that Vi can handle is limited to 512 characters.
http://ctags.sourceforge.net/FORMAT
EDIT: updated source: https://neovim.io/doc/user/vi_diff.html
Maximum length of a line in a tags file: 512 bytes.
I indeed did have a tag line longer that 512 characters - removing that line fixed the issue for me.
I solved this problem by rebuilding the tags.
First remove all tags files and then rebuild tags from your project.
I think the reason was i built the tags files twice, first time the tags built for child directories, then build the parent directories.
So, the child directories tags couldn't contain some parent directories information.
I came across the same issue, seems not all file formats are well supported. I used the option -L to create tags for only c and c++ files ,the issue went away .
You might want to try the following , just substitute the *.postfix with the corresponding format you need.
ctags -L $(find . -name *.c -or -name *.cpp -or -name *.h -or -name *.lua )
Removing extra lines non-comforming to the ctags standard fix the issue for me.
I try to generate Turkish spell file for Vim from a word list with the following command:
mksp /tmp tr_TR.words
tr_TR.words resides in C:\Program Files\Vim\vim72
Vim starts reading the word file but the process is interrupted before completion. Vim gives the following error message:
Compressed 5110514 of 6389213 nodes; 1278699 (20%) remaining
Writing spell file /tmp/tr.utf-8.spl ...
E484: Can't open file/tmp/tr.utf-8.spl
I use Gvim 7.2 on Win 7. The word list file tr_TR.words contains lines of words such as:
aba
abaca
abacası
abacı
I couldn't find the cause of this error on internet. Do you have any suggestions?
Well if you are on windows, you should know, there is no /tmp directory. So try:
mksp YOUR_INPUT_FILE_PATH\FILENAME C:\tmp\tr_TR.words
Try to replace /tmp in the command with C:\Program Files\Vim.
I am using Vim and I have set the path (set path+= c:/work/etc/etc) to my project directory (for C#), but still using command 'gf' give me error:
E:447 Can't find file.
Is there anything I am doing wrong over here?
G'day,
To get a bit more detail on your current path settings you can see what's being included and the files vim can't find by entering the command:
:checkpath
and you'll get a dump of the files not found, e.g.
--- Included files not found in path ---
<io.h>
vim.h -->
<functions.h>
<clib/exec_protos.h>
Or you can get a listing of all included files, both found and not found, by entering
:checkpath!
Enter
:help path
to get more info on the path syntax.
Edit: Don't forget that using the syntax
set path=/work
will completely reset your path variable to what you've just declared. I'd suggest using
set path+=/work
instead. This won't clobber the current path and will just add your /work directory instead.
HTH
I also found out that
:set path+=./foo/bar
adds a search location relative to the directory of the current file, just like '.' does.
My vim didn't want to search for such include
#include <common/util/string.h>
So what I needed to do was
:set path+=foo/bar
instead of
:set path+=./foo/bar
The former adds a search path relative to current working directory. Hopefully it helps someone.
First can you open the file using :find file.name ? (:help find for more info). If this does not work then your path is wrong. If :find does locate your file then do the following:
Insure that you are not in Visual/Insert mode
Place cursor on the first letter of the filename and press gf
I know this is an old question, but I also had some troubles with this for another reason and it took me some time to find out why. I hope this might be helpful to someone.
When a directory is matched with wildignore, gf does not work for files in it, nor does :find.
This is obvious if you read wildignore's documentation, but I forgot I ever changed this variable, and what it was for exactly. Also I used a glob, and it was not immediately apparent to me that the directory I was using gf in, was also matched with this glob.
Make sure there is no leading character to the file name if you press gf, i.e. using gf when the cursor is on help.txt will not work here:
file=help.txt
If you are talking about the gf tool wri††en by tomnomnom then here's how to set-up:
Setting PATH for GO (if you have not setup yet).
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
Step 1: Download tool from github
Step 2: cp -r path/to/tomnomnom/gf/examples ~/.gf
Step 3: source ~/tools/gf/gf-completion.bash
Now gf should work along with auto-completion from anywhere.
Source: Original sources are present at his repo.