I’m unsure about the %t format specifier in Vim’s quickfix list. How does it affect the behavior/display of the quickfix buffer?
I tried to find it out with the following test file:
$ cat test.out
foo Error 1 foo.h foobar
bar Error 2 foo.h foobar
foobar Warning 3 foo.h foobar
barfoo Warning 4 foo.h foobar
And the following errorformat first:
set errorformat+=%.%#%*\\s%.%#%*\\s%l\ %f%*\\s%m
With this errorformat in place I can use :cgetfile test.out and jump to the line numbers in foo.h, but with the following errorformat:
set errorformat+=%.%#%*\\s%t%.%#%*\\s%l\ %f%*\\s%m
All that has changed is that now I see some spaces after the line numbers in the quickfix buffer, e.g. I see (two spaces after the 1)
foo.h|1 | foobar
instead of
foo.h|1| foobar
So I have two questions:
- What is wrong with my
errorformat? - What should I see if the error type could be extracted?
This is not really an answer to your question, but an alternate solution I use myself. Personally I find the errorformat system too complicated, and instead use a common very simple errorformat fed by the output of a real function, that I pipe the output of my make command through. I use this: "%f\ %l\ %c\ %m". I write these error parsing functions in python, but any of the supported scripting languages should do, or even vimL. The logic of this being that such a function is much easier to debug, usable outside of vim, and (at least for me) quicker to write than crafting an errorformat string.