This question already has answers here:
How to open a file in a list of files in Vim?
(11 answers)
Closed 7 years ago.
I'm analyzing a regression of thousands of test cases in linux. So I want to open many files(failed) in gvim at once.
I have a file as mention in below with 100+ lines specifying 100+ files in a directory. I want to open all these files in gvim(in single gvim).
./Linux2/Lint/case1/DIFF
./Linux2/Lint/case4/DIFF
./Linux2/Lint/case10/DIFF
./Linux2/range/case1/DIFF
./Linux2/operator/case7/DIFF
100+ lines like this.
Is there any way to open files in all these files in gvim with some navigation mechanism.
I know it is possible to use,
gvim file1 file2 .....
But it is not easy with 100+ files.
I need to do this in gvim, not in vim.
I just used find . -name DIFF | xargs vim and was able to navigate through all the files using :next and :prev and :buffers
Only ugly bit was when I hit about 1500 files I'd get two invocations of vim and would have to finish editing the first 1500 files before moving on to the next 1500 (Due to the way xargs works).
Another option is to use vims error file parsing. List all the files in an file with information about the line and error, open that file and run :cbuffer in that buffer (it will close the error file and move you to the first listed erro). :copen will open the list of errors as the Quickfix List. Then you can use the usual :cn and :cp to move between forward and backward in the quickfix list (and <CR> in the quickfix list will work too. Something like this should work out of the box for you.
:./Linux2/Lint/case1/DIFF:1: Not really an error
:./Linux2/Lint/case2/DIFF:1: Not really an error
:./Linux2/Lint/case3/DIFF:1: Not really an error
Now this can be improved since vims error parsing is flexible. You could remove the requirement for the leading : by using set errorformat=%f:%l:\ %m or just use a raw list of files using set errorformat=%f.
It sounds like you want to produce a command line argument from a file. You can do that with command substitution in bash.
gvim $(cat ListOfFiles.txt)
Related
Say I had opened vim with no arguments, then from within vim opened 10 .txt
files and 10 .py files. Also, let's say the files are scattered around my file
system. The buffer list contains all 20 files.
Now I want to add the 10 .py files to the arguments list. I want to do
something like :argadd *.py, but this just creates a new file called '*.py'
and adds it to the arguments list.
I see from the help that argd[elete] can use a pattern, so I could delete all
the .py files with :argd *.py. Is there a way to do something similar for
:arga[dd]?
:[count]arga[dd] {name} ..
Add the {name}s to the argument list.
:argd[elete] {pattern} ..
Delete files from the argument list that match the
{pattern}s.
Surely there's a better way than navigating to each .py file and running
:argadd?
You can go through all your buffers and add them to the argument list based on some discriminant with a single easy command:
:bufdo if &ft == 'python' | argadd | endif
or, if you really don't like typing:
:bufdo if&ft=='python'|arga|en
See :help :bufdo.
Well, it's sort of a "made up" question, I think. One rarely needs so many buffers/args at the same time that naive :argadd #10 #12 #15 #20 would be totally impractical.
But if you insist you need this then I'd suggest to try expression register, sort of
:argadd <C-R>=join(expand("*.py",1,1))<CR>
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.
I have indexed my c++ codebase with ctags, I can open a header file as follows:
:tag myfile.h
(It doesn't matter where myfile.h is located, as long as it is inside the indexed codebase it will open correctly in vim)
When I'm editing a c++ file, I can get the header filename as follows:
:e%<.h
e.g. when editing myfile.cpp, executing this command will display myfile.h on the command line.
A file can be opened in vertical split, by issuing:
:vs <myfile>
Now what I want to accomplish, is to have 1 command or function which I can use to open a header file of the corresponding c++ file that I'm currently editing in vertical split. Hence basically I want to combine the 3 above commands as if I would be doing a Unix pipe, e.g.:
:vs tag | e%<.h
" :vs to open file in vertical split
" :tag to find tag
" :e%<.h to get header filename
Obviously the Unix pipe doesn't work on vim, alternatively I've tried to write a function at which I assign the result of a command to a variable, e.g.
headerFileName = :e%<.h
Which apparently is not the correct way of doing this, I'm a bit lost here so I hope somebody can provide some help.
There exist several plugins that already do this (without needing a ctags database BTW).
For instance, with alternate (aka a.vim), you just have to type :VS from the header file or the source file to open the other one in a vertically split window.
Note that alternate have an option to tell where to find the other file (same directory, substitute on directory name, ...)
Otherwise, I suspect you are looking for expand() and :exe. If you write a function it may be
function! s:whatever() abort
let crt = expand('%:t:r')
vnew
exe 'tag '.crt.'.h'
endfunction
command! whatever call s:whatever()
This question already has answers here:
Jump to function definition
(11 answers)
Closed 7 years ago.
When reading through a person's code, I may be looking through a program that comprises 10+ files. I would like the ability to search for where an object/struct/type def have been declared.
Does vim allow you to do this kind of search? If so how?
You can use the CTRL-] command to "Jump to the definition of the keyword under the cursor." (see :h ctrl-]).
For this to work, you will need to create a tags file, for example with a program like ctags. The manual has more on this, see :h tag.
Sounds like you could use lvim to grep a word across multiple files.
From the documentation :
to search for the words "house" or "home" in all .txt files in the
current directory, use:
:lvim /\<\(house\|home\)\>/gj *.txt
:lw
You can also integrate external programs, like grep or findstr into vim for faster searching, but those will depend on your OS: http://vim.wikia.com/wiki/Find_in_files_within_Vim#Using_external_programs_for_fast_searches
I need to add several lines all at the same location to multiple files. I was wondering if I could possibly open all files with Vim, and only make the changes in one file for which the changes will be made in all files simultaneously. I really want to avoid opening X number of files, copying this, pasting, then repeating for each file of X files...There's gotta be a better way to do this, hopefully with vim...
Thanks!
Amit
You could record macro and execute it on other files. See http://www.thegeekstuff.com/2009/01/vi-and-vim-macro-tutorial-how-to-record-and-play/ for detailed tutorial.
You can use the windo command to operate in all windows. Combine this with a substitute command and you have this (say you want to add "This is a new line." at line 2 in every file):
:windo 2s/\(.*\)/This is a new line.^M\1
Off course, as others noted, there are much better tools for this job (awk comes to mind).