[vim/vim] Add bvimgrep command (#858)
Christian Brabandt
This patch adds the :bvimgrep and :bvimgrepadd command.
This is allows to vimgrep for all available buffers and has the
advantage, that vim does not need to load files from disk.
This patch does not add the :blvimgrep(add). Would that be needed
as well? Or should that be :lbvimgrep(add)?
Also this allows to execute :vimgrep in buffers, that have no
corresponding file on disk (or which are changed for which :vimgrep
would only run on the disk-version).
Usage:
:bvimgrep[!] /{pattern}/[g][j] [{buffer} ...]
:bvimgrep[!] {pattern} [{buffer} ...]
Same as ":vimgrep", except that it searches the given
buffers. If no buffer is given, searches the current
buffer. Buffer can be given as buffer name (including
file-patterns) or number.
*:bvimgrepa* *:bvimgrepadd*
:bvimgrepa[dd][!] /{pattern}/[g][j] [{buffer} ...]
:bvimgrepa[dd][!] {pattern} [{buffer} ...]
Just like ":bvimgrep", but instead of making a new
list of errors thep matches are appended to the
current list.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/858
Commit Summary
- Add bvimgrep command
File Changes
- M runtime/doc/quickfix.txt (15)
- M src/buffer.c (85)
- M src/ex_cmds.h (6)
- M src/ex_docmd.c (9)
- M src/proto/buffer.pro (1)
- M src/proto/screen.pro (1)
- M src/quickfix.c (106)
- M src/screen.c (15)
- A src/testdir/test_bvimgrep.vim (63)
Patch Links:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
chdiza
Wow, this would be great. I can't tell you how many times I've done :vimg /something/ % in a buffer that doesn't have an associated file.
I wonder if maybe it would be better if this functionality were implemented as a flag passed to :vimgrep rather than as a separate command. Like :vimg -b /pattern/ [bufs]. That would also get rid of the need for further commands starting with b or bvimg.
Christian Brabandt
updated patch according to comments
Justin M. Keyes
@justinmk commented on this pull request.
In src/ex_docmd.c:
> */
if ((ea.argt & BUFNAME) && *ea.arg != NUL && ea.addr_count == 0
- && !IS_USER_CMDIDX(ea.cmdidx))
+ && !IS_USER_CMDIDX(ea.cmdidx) && ea.cmdidx != CMD_bvimgrep
+ && ea.cmdidx != CMD_bvimgrepadd && ea.cmdidx != CMD_blvimgrep
+ && ea.cmdidx != CMD_blvimgrepadd)
If the -b suggestion were implemented, these special cases sprinkled everywhere could be avoided.
Justin M. Keyes
By the way, why can't :vimgrep and :lvimgrep instead be changed to support searching non-file buffers? Why always more special-cases commands?
Christian Brabandt
Updated patch implements a new approach. Use <buffer> argument to the various :vimgrep commands to search buffers instead of files. I hope that is more useful than the various :bvimgrep commands.
Justin M. Keyes
Thanks. It's certainly an improvement in my opinion.
For what it's worth, my previous comment was asking if :[l]vimgrep can do this by default. I don't think anyone would be surprised if the command finds text in a buffer that hasn't actually been written to disk. And it would more strongly justify the existence of :[l]vimgrep vs plain :grep.
Christian Brabandt
That is not be possible, because a command either works with buffers or with files. It can't handle both at the same time (and even if it could, that would be backwards incompatible). I think the best we can do is add a flag to make the command switch its behaviour depending on what the user actually wants. However this requires the ugly workaround with get_vimgrep_type() in do_one_cmd()
Christian Brabandt
updated patch, fixed link error for non-gui builds.
Codecov
Codecov Report
Merging #858 into master will decrease coverage by
<.01%.
The diff coverage is87.27%.
@@ Coverage Diff @@ ## master #858 +/- ## ========================================== - Coverage 74.58% 74.57% -0.01% ========================================== Files 76 76 Lines 124841 124931 +90 ========================================== + Hits 93111 93172 +61 - Misses 31730 31759 +29
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/screen.c | 74.13% <100%> (+0.03%) |
⬆️ |
| src/ex_docmd.c | 74.2% <100%> (+0.03%) |
⬆️ |
| src/buffer.c | 75.32% <80%> (+0.23%) |
⬆️ |
| src/quickfix.c | 90.47% <89.47%> (-0.02%) |
⬇️ |
| src/if_xcmdsrv.c | 83.42% <0%> (-1.85%) |
⬇️ |
| src/message.c | 68.04% <0%> (-0.41%) |
⬇️ |
| src/gui_gtk_x11.c | 47.26% <0%> (-0.11%) |
⬇️ |
| src/channel.c | 83.79% <0%> (-0.1%) |
⬇️ |
| src/term.c | 54.17% <0%> (-0.07%) |
⬇️ |
| src/gui.c | 45.48% <0%> (-0.06%) |
⬇️ |
| ... and 2 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update d5d3753...1235c2a. Read the comment docs.
Bram Moolenaar
Christian Brabandt wrote:
> Updated patch implements a new approach. Use `<buffer>` argument to
> the various `:vimgrep` commands to search buffers instead of files. I
> hope that is more useful than the various `:bvimgrep` commands.
<buffer>. For most users a file and a buffer are the same thing.
So, what is different when using <buffer> ?
--
hundred-and-one symptoms of being an internet addict:
227. You sleep next to your monitor. Or on top of it.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Bram Moolenaar
Christian Brabandt wrote:
> That is not be possible, because a command either works with buffers
> or with files. It can't handle both at the same time (and even if it
> could, that would be backwards incompatible). I think the best we can
> do is add a flag to make the command switch its behaviour depending
> on what the user actually wants. However this requires the ugly
> workaround with `get_vimgrep_type()` in do_one_cmd()
too many options already. And when using the command from a plugin it
would have to save the option, set it to a known value and restore the
option.
--
hundred-and-one symptoms of being an internet addict:
pass that 2000 mark.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Justin M. Keyes
That is not be possible, because a command either works with buffers or with files. It can't handle both at the same time (and even if it could, that would be backwards incompatible).
Backwards incompatible with what? What could it possibly break?
Christian Brabandt
Bram wrote:
An option that changes what a command does it not a good idea. We have too many options already. And when using the command from a plugin it would have to save the option, set it to a known value and restore the option.
That's why use the magic value "". We have a similar flag already for :autocommand and mappings
I think the help should say something about when you would want to use . For most users a file and a buffer are the same thing. So, what is different when using ?
Okay, will update the help a bit more then.
Justin wrote:
Backwards incompatible with what? What could it possibly break?
It changes, how the
{file}argument is interpreted. We cannot change it to mean buffer and not files anymore. That breaks users expectations. However, one could argue, that whenever a file is already loaded use the available buffer instead. Not sure, if this wouldn't be too confusing.
Christian Brabandt
updated to latest source 8.0.1129
Bram Moolenaar
This has slid down the todo list... Looking at the help for ":vimgrep ", this is hard to type. How about calling this ":bufgrep" ? Default would be to search the current buffer: ":bufg theThing" creates a quickfix list, so you can iterate through the matches. Without first saving the buffer in a file.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Nick Jensen
This has slid down the todo list... Looking at the help for
":vimgrep <buffer>", this is hard to type. How about calling this ":bufgrep" ? Default would be to search the current buffer: ":bufg theThing" creates a quickfix list, so you can iterate through the matches. Without first saving the buffer in a file.
I'm just commenting here to point out to github users that the <buffer> argument above got lost in github rendering (it is visible in the mailing list).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
K.Takata
(I edited Bram's comment to make <buffer> visible by using backquotes instead of doublequotes.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
I am not sure this is still useful. There was not much demand for that and I think one can implement the same using a couple of lines of Vimscript.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
Closed #858.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
closing as it doesn't seem to be too useful
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.