So, fiddling with the EasyGrep.vim plugin, trying to get it into a state that suits me.
I am using it for recursive searching of a Rails project. Ive almost got it how I want it, this is an example of the grep command my modified EasyGrep executes:
:grep -R -i --include=*.rb --include=*.rbw --include=*.gem --include=*.gemspec --include=[rR]akefile --include=*.erb --include=*.rhtml SEARCH_WORD .
Which finds the word under the cursor, and opens the search results in quicklist.
Only problem is, :grep seems to automatically open the file containing the first match into the current buffer, which I do not want it to do, because then I lose the file I was just looking at.
Anyone know how I can prevent this behavior? Or, at least a hacky workaround that reopens the file I was searching from?
:vimgrep is not an option - its far too slow.
From :help :grep:
Just like ":make", but use 'grepprg' instead of 'makeprg' and 'grepformat' instead of 'errorformat'.
From :help :make:
If [!] is not given the first error is jumped to.
So: :grep!
Add this to your .vimrc:
let g:EasyGrepOpenWindowOnMatch=0
EasyGrep has many options that can control how it behave. Type :GrepOptions for a listing of all of these.
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.
There is a lot of documentation about vim's quickfix but I would like to know:
How I can I use a text file (or copy+paste from a terminal), and put this into a quick-fix list in vim?
All the docs I found so far assume that you run make or vimgrep, but in this case I just want to use a text file created elsewhere.
You're looking for :cfile / :cgetfile:
:cf[ile][!] [errorfile] Read the error file and jump to the first error.
The file you're reading naturally must be in a format that can be parsed by the 'errorformat' option.
One way to do it is to change makeprog to cat from your text file, pretty sure there's a better way to do it though.
How can I create a Vim command and copy it's results to clipboard?
I want to convert Markdown to HTML and copy the result to the clipboard. So far I got:
nmap md :%!/bin/markdown/Markdown.pl --html4tags
But this will substitute my opened file on Vim to the result of Markdown.
You didn't say which system you're using, but generally saving it in the +
register should work. You can call system():
:let #+=system("markdown --html4tags", join(getline(1,line("$")), "\n"))
The system() function takes the second parameter (optional) as input to the
command, and here I'm using a chain of other functions to retrieve the contents
of the current buffer. Not sure, but there should be a better way to do it (if
someone knows, please let me know).
Alternatively, you can pass markdown your file name as input directly:
:let #+=system("markdown --html4tags " . shellescape(expand("%:p")))
But keep in mind that you'll need to write the file before calling this.
Two important notes:
I didn't type your full path to markdown. Use it.
I didn't use maps here, the final result would be something like:
nnoremap md :let #+=system(...)
get the xsel package
and pipe stdout to xsel --clipboard
For instance:
cat /etc/passwd | xsel --clipboard
Is that what you're looking for?
Filling in a missing piece (2+ years late). With the clarification that the user was on a Mac and since the asker's "why doesn't it work for me?" question was not answered.
To redirect the output of a command to the system clipboard from within MacVim (GUI version) you need to set the '*' to be the "clipboard register" you need to change the clipboard setting to 'unnamed':
set clipboard 'unnamed' # 'cb' can be substituted for 'clipboard'
Then sidyll's answer should work except specify the '*' register and not the '+' register:
:let #*=system(...)
The clipboard feature is likely not compiled into the "terminal version" of MacVim and when it is available option setting is different from 'unnamed'. To see more details regarding what works where and how, see the documentation in MacVim using the Vim help command:
:help 'clipboard' (include the single quotes since it's a set option!)
(I'll skip the command mapping issue since it always takes me several tries and I still have to look it up; finding the help for the mapping commands should be easier than finding it for the * register.)
How can I bring back the last string I used for a search or a search&replace?
For example, assume that I enter :%s/some_text/some_other_text/gc and vim gives me the E486: Patterns not found: some_text error message back. I then realize that I actually meant to write some_magic_text instead of some_text. At that point, how can I get back my original string in the bottom command row (or whatever it is called) so I can change it and do a second search? Is there a nifty little command for that?
In this brief example it looks unnecessary, but when the text you are looking to replace is mighty long and you just typed one letter wrong, it is fantastically annoying to have to retype everything.
And I am using MacVim if that makes any difference.
From the normal mode, hit q/ to navigate through your search history!
Check out this vimvcast which explains what you want.
More generally, you can recall any command you have previously typed by entering the first few characters, and then use arrow multiple times to navigate in history.
In your case, you could type:
:%s<Up>
See :help history
This answer might be good an improvement to what you are after, after all.
Use search with highlighting, to interactively check if the regex you are crafting is definitely working, and then use it in a search-replace.
:se is (incsearch, better put se is in your .vimrc)
/<search term>
check with n/N if you are happy with the matches
:s%//<replace term>/g
When omitting the <search term> in the search-replace in 4., the last used search will be used.
For acessing the list of last (search-replace) commands use q:, or as already noted q/ for the list of last search terms.
Bonus:
When using :se gd, s/<search>/<replace> will behave as s/<search>/<replace>/g.
Accessing just the first search match in each line can then still be done with adding /g, so essentially both behaviours are just switched.
/ and then up to bring up the last search query.
Say, I have files foo.js and bar.css in my project. There is a ":find" command in vim, which find files, matching string. But this command, alas, has some limitations. For example, if I launch this way - "vim", or even this way - "vim ." - there's nothing to be find in js subdirectory. But if I launch vim this way - "vim js/any_file_other_than_foo.js", then calling ":find foo.js" works pretty well.
Since it is not intuitive (i'm working in the same directory, "pwd" returns the same path), my first question is - can anybody explain how to circumvent this issue? And, even broader, is there any way to type something like find foo - and open first file, which name matches pattern foo.
thanks in advance.
You could try
:e[dit] **/*foo* and then press 'tab' to move to the first match.
the ** is a directory globbing pattern, while * is character matching.
If you were so inclined, you could write a simple fuzzy finder command, for more information you can check out the vim tips wiki: http://vim.wikia.com/wiki/Find_files_in_subdirectories
Vim's :find works by searching each directory in the path variable (and ignores pwd). By default, it does not search recursively. That's why find is only working for you when you open a js file. The '.' in path refers to the directory for the current file -- not pwd.
You can change path to include your desired directories:
set path+=$PROJECT/js
See :help path.
One of the magic bits to use is to add ** to a path to search that path recursively:
" search recursively in my project
set path+=$PROJECT/**
" search recursively from the current file's directory
set path+=./**
See :help file-searching for more magic.
A nice plugin that accomplishes a similar effect is Command-T.
The Command-T plug-in provides an
extremely fast, intuitive mechanism
for opening files with a minimal
number of keystrokes. It's named
"Command-T" because it is inspired by
the "Go to File" window bound to
Command-T in TextMate.
Files are selected by typing
characters that appear in their paths,
and are ordered by an algorithm which
knows that characters that appear in
certain locations (for example,
immediately after a path separator)
should be given more weight.should be given more weight.
Here is a screencast of Command-T in action.