What is the desired behaviour of vim's quickfix feature?
Should the quickfix window (:copen) only contain compiler errors/warnings or should the whole output be displayed?
I want the former, since the output of make can be very long, but I get the latter, even with compiler set to gcc and g:compiler_gcc_ignore_unmatched_lines set.
However, lines inside the quickfix window with warnings/errors are highlighted and :cnext correctly jumps to the next issue.
Furthermore, Lines without issues have a double pipe symbol prefixed, so it seems that vim properly parses the make output.
Are these lines displayed in addition to the warnings/errors and can be hidden or does the errorformat string not exactly match the make output?
I used the avrdude 5.11.1 sources as an example, but I get the same result with many other projects.
Does setting the compiler automatically adapt the errorformat string or do I have to set that string always manually?
Thanks
It's really however you want it to work. I often filter out some of the build output that I'm not interested in by adding grep to my makeprg, but I also want some of the build output even if it's not an error.
I don't think vim will remove non-error lines from the quickfix. If you don't want them there, you need to filter them yourself (or modify efm to include them in an error).
Related
A long file paths is broken up over multiple lines in the Vim quickfix window which then for example does not allow to jump to the error location displayed in the qf.
The file (and the lines around) are diplayed in the quickfix window as (the example is the output from neomakes pdflatex)
|| Enter file name:
|| /long/path/to/file/.../loca
tionOfTexFiles/myTexFile.tex|144 error| Emergency stop.
|| read
to be able to follow to the file line by lnext/cnext I should have
/long/path/to/file/.../locationOfTexFiles/myTexFile.tex|144 error| Emergency stop.
For quickfix files I have the following relevant (in my view) settings which are set to:
setlocal nolinebreak
setlocal nowrap
setlocal textwidth=9999
So I am wondering how I can display the file path in one line within the quickfix window?
On :make, Vim invokes 'makeprg', captures the output, and then parses it according to 'errorformat'. The latter does support multi-line error messages (cp. :help errorformat-multi-line), but that is mostly for what I would call intentional linebreaks, as specified by the compiler. What you suffer from is unintentional linebreaks because of line wrapping (due to overly long paths).
Now, I don't know about "neomakes pdflatex", but it looks like that tool creates the linebreaks, whereas it shouldn't, as Vim is capturing the output, and there's no receiving terminal (or user). Investigating in that direction (or opening an issue at the project's tracker) might be helpful.
The mentioned Vim options ('linebreak', 'wrap', etc.) have nothing to do with it. They apply to normal buffers; the quickfix buffer as such is not modifiable.
Workarounds
A possible workaround might be to :cd first to a directory that is "closer" to the processed files (or even :set autochdir); this might avoid the long paths in the output.
Alternatively, you may "unmangle" the output by adding a sed stage after the compiler:
let &makeprg .= "| sed -e 's/.../...'"
If I'm not mistaken, the issue is on pdflatex side. The || mark is a good indication: you'll have one per output line -- in case filename and/or lines numbers are recognized, they'll be fed in between the bars.
So. This means you'll need a way to fix the path names. It'll be better to do it outside vim. I'm not saying this is trivial. I'm just saying that if you can have a program able to fix pdflatex outputs, you'll just be one pipe away from the solution (plus a correct forwarding of error codes...).
If you prefer to implement it in vim script, this is possible. But you'll experience side-effects. In my BuildToolsWrapper plugin I'm able to post-process compilation output in vim side, but the result is far from being perfect. I'm working on getqflist() result, and parse each line. When I found a line where I want to fix the filename, it's not simply about fixing the filename but also about assigning a valid buffer number to it. See this function where I can replace a filename with another one. The magic happens where lh#buffer#get_nr() is used. Still you'd need to implement a vim script able to merge split filenames.
IOW: my understanding is that vim is not involved. It could be used to fix the issue, but IMO this is not the easier path to undertake.
In almost every copy of vim that I have used, the program will give a description of changes after replacing text. (For example, something like "92 substitutions on 20 lines" would be displayed.)
I'm now working with a copy of vim that does not do that by default.
Is there a simple command (or addition I can make to my vimrc file) that will enable this behavior?
It's governed by option report.
You can see you current setting with
set report?
To report even the minimal change
set report=0
I think you experience the effects of the 'report' option. If the (substitution, or any other command's) changes cover more than those (default 2), you'll see the message, else nothing.
So, you can put the following into your ~/.vimrc to always see those messages:
set report=0
Although not exactly your question,
in vim's substitutions, you can use the "n" flag to count the number of
matches and lines (without real substitutions).
Example
:%s/a//gn
55311 matches on 17459 lines
I know there are some threads about this on stackoverflow but when i write ":set list" in the editor, it seems to display hidden characters but it doesnt display the hidden characters in the code we are having problems with.
Some times now we have had some invisible symbols in our code making if loops break, i dont know how the symbols get there except from that some wierd keyboard combination much have been accidentally typed in. The code itself looks correct but the invisible symbol breaks it.
I have searched online about this but all i can find seems to be the ":set list" command in vim in addition to have to change the color of the hidden characters, but while this seems to display some hidden characters it doesnt display the problematic ones. We are getting two symbols which looks like a cross and one looks like a pistol. We have also tried to add the "draw_white_space" setting in sublime text but this only seems to display, well, whitspace like it says but the result was shown on google for showing hiden characters so i gave it a try.
The only way we have been able to see where the symbols are is with the DiffMerge tool, we have not been able to see these symbols in any other editor but we have actually been able to copy the sign to its own file and grep through all the files with the -f grep option which works, but it would be easier to display the characters in vim but using a keybinding.
Does someone have any suggestions? This is causing us to use a lot more time debugging the code when the problems is an invisible symbol.
Try the following search command:
/[^ -~<09>]
(you get the <09> by pressing the tab key). Or if you want to get rid of those nasty tabs, just:
/[^ -~]
That will find and highlight any non-ASCII or control-ASCII character.
If you still have hidden characters out there, you can try this command before the search:
:set enc=latin1
That will prevent any weird Unicode character to show up in your code.
This may be an odd question, but still. I use cat to display a file in bash (KDE Konsole),
cat foobar.rb
Now, I would like to use Vim to colourize that foobar.rb file according to what you would get when you start foobar.rb in Vim. Edit: But only for display purpose, on the terminal.
I am not sure this is possible, but I thought it would be neat if I could use Vim for that.
I really just want colourized keywords, and Vim has the perfect colour definitions.
So I thought combining this would be great.
Is this possible in Vim out of the box though?
One approach would be to use a library such as Pygments, which is a general purpose syntax highlighter. You could write a wrapper called ccat or something that would apply syntax highlighting to an input file and write to stdout.
If you want to page up and down in a highlighted file, you can use less with the -R switch, which passes control characters through to the terminal directly, preserving colours. So:
ccat file.rb | less -R
But at that point, you're pretty much at the capabilities of view.
I'm not sure if I understand your question correctly, but if you are only looking for a command that will give you a read-only view of the input file (like cat) but with coloured keywords, use view. view is an alternative way to start vim in read-only mode, so you have all syntax highlighting possibilities. From the vim man page:
view Start in read-only mode. You will be protected from writing
the files. Can also be done with the "-R" argument.
gvim gview
The GUI version. Starts a new window. Can also be done with
the "-g" argument.
evim eview
The GUI version in easy mode. Starts a new window. Can also
be done with the "-y" argument.
rvim rview rgvim rgview
Like the above, but with restrictions. It will not be possi-
ble to start shell commands, or suspend Vim. Can also be
done with the "-Z" argument.
I have always seen view on systems that have vim installed.
Closest is the less script that comes with vim:
cat myfile | vim -u /usr/share/vim/vim72/macros/less.vim -
Note the - argument to vim. You may need to change the vim72 to your version (and the whole path if you have it installed elsewhere)
Now, this isn't exactly what you want, because its behaviour is less-like, in that you have to press keys to make it scroll down or complete. However, they are briefer than usual vim. For example, space to scroll down; and q to quit (not :q).
You want a cat-like version; me too. But there doesn't seem to be one.
EDIT uh, there's also a vimpager project, that includes vimcat - exactly what you want. But it doesn't come with vim, and I haven't tried it yet.
vim.org: http://www.vim.org/scripts/script.php?script_id=1723
github: https://github.com/rkitover/vimpager
I have a warning I can not easily remove from my build, every time i run ":make" from inside vim the quickfix takes me to some header file I don't care about. How can I prevent VIM from doing this and only showing me warnings and errors I do care about?
As Luc Hermite said, it is possible to ignore warnings using 'errorformat'option.
Adjusting this option is a little bit complicated; it may be helpful to check $VIMRUNTIME/compiler for some examples.
When working with avr-gcc and C++ some annoying warnings like this
tests.cpp:492: warning: only initialized variables can be placed into program memory area
shows up, and it is likely to be result of a compiler fault.
To avoid that this warnings being displayed on quickfix window I've add this to ~/.vimrc:
compiler gcc
set errorformat^=%-G%f:%l:\ %tarning:\ only\ initialized\ varia
\bles\ can\ be\ placed\ into\ program\ memory\ area
The %-G can be used to specify patterns to be ignored.
The ^= in set errorformat^=... is used to prepend the ignored warning pattern to 'errorformat' -- using += (set errorformat+=...) would append to the option and wouldn't work, as 'errorformat' is a list of formats and the first one that matches is used, thus the "normal" warning pattern would apply instead.
Maybe you could adapt these settings for your environment.
Check :h 'errorformat' (aka &efm), there are options to ignore warnings as long as you can recognize them with a pattern.
A quick and dirty way would be to write a simple shell script that runs your make and greps out the warnings you don't want to see. Then have vim use this script instead of make (Add "set makeprg=yourscript.sh" to your .vimrc).
To build on what mMontu suggested, adding this to my .vimrc did the trick for me (ignore all warnings from my gcc compiler)
set errorformat^=%-G%f:%l:\ warning:%m
Learn from Bram himself.
I can vaguely remember he talks about this somewhere in this video.
He adds a filter to ignore some gnome warnings when he's compiling gvim.
The video's well worth watching anyway.
It's around the 30 minute mark.