[vim/vim] Support file:line colon suffixes across entry points (PR #18689)
carli2
Summary
- Command-line parsing: Added a shared
parse_cmd_file_arg()helper and integrated it intomain.cso the firstfile:line[:col]argument (after stripping optional:TaBe) is
rewritten into the proper+{line}or+call cursor(line,col)form while respecting options that consume the next token. - Ex command support: Updated
do_exedit()and arglist navigation (do_argfile, drag/drop paths) to trim:line[:col]suffixes before editing, remember the requested coordinates on
each arglist entry, and move the cursor to the recorded line/column when no user+cmdoverrides them. - Tests: Added targeted coverage to
test_startup.vim,test_tabpage.vim, andtest_arglist.vimfor CLI invocations, tab commands, drag-and-drop, and arglist workflows to ensure the
new behavior is stable.
Testing
make -C src cd src/testdir && make -f Makefile TEST_FILTER=Test_cmdline_file_position test_startup.res cd src/testdir && make -f Makefile TEST_FILTER=Test_tabedit_file_position test_tabpage.res cd src/testdir && make -f Makefile TEST_FILTER=Test_drop_file_position test_tabpage.res cd src/testdir && make -f Makefile TEST_FILTER=Test_args_file_position test_arglist.res cd src/testdir && make -f Makefile TEST_FILTER=Test_arg_drop_file_position test_arglist.res
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/18689
Commit Summary
- 15de76f Support file:line colon suffixes across entry points
File Changes
(9 files)
- M src/arglist.c (56)
- M src/ex_docmd.c (29)
- M src/main.c (65)
- M src/misc2.c (118)
- M src/proto/misc2.pro (1)
- M src/structs.h (2)
- M src/testdir/test_arglist.vim (37)
- M src/testdir/test_startup.vim (113)
- M src/testdir/test_tabpage.vim (39)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
h_east
@h-east commented on this pull request.
In src/misc2.c:
> + break;
+ }
+ }
+ else if (*line_end == NUL)
+ {
+ suffix = p;
+ line_start = maybe_line;
+ col_present = FALSE;
+ break;
+ }
+ }
+
+ if (suffix == NULL || line_start == NULL)
+ return FAIL;
+
+ {
{ (and its matching }) isn't needed. Let's leave the optimization to the compiler.
In src/misc2.c:
> + }
+ }
+
+ if (suffix == NULL || line_start == NULL)
+ return FAIL;
+
+ {
+ char_u *scan = suffix;
+
+ while (scan > arg && VIM_ISDIGIT(scan[-1]))
+ --scan;
+ if (scan > arg && scan[-1] == ':')
+ return FAIL;
+ }
+
+ {
Ditto.
In src/misc2.c:
> + while (scan > arg && VIM_ISDIGIT(scan[-1]))
+ --scan;
+ if (scan > arg && scan[-1] == ':')
+ return FAIL;
+ }
+
+ {
+ size_t len = (size_t)(suffix - arg);
+
+ if (len == 0)
+ return FAIL;
+ if (fname_len != NULL)
+ *fname_len = len;
+ }
+
+ {
Ditto.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)Unless I am missing something, this would be a backwards incompatible change. What happens if I want to open a literal file name 'foobar:5'? It also misses accompanying documentation for such changes in behaviour.
Command-line parsing: Added a shared parse_cmd_file_arg() helper and integrated it into main.c so the first file:line[:col] argument (after stripping optional :TaBe) is
What is :TaBe?
- Aligns expectations between CLI usage and in-editor workflows—no more surprises when :tabedit foo:99 opens a new buffer literally named foo:99.
- Boosts productivity for anyone juggling compiler errors, test failures, or diagnostics that already emit file:line[:col] links.
- Comes with dedicated regression tests for startup, tab/page commands, drag-and-drop, and arglist manipulations, so the behavior stays consistent going forward.
And breaks existing scripts/user workflows 🙈
Please, if you do AI to generate a new PR, please mention this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#18689)See :help +cmd
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
carli2
carli2 left a comment (vim/vim#18689)And breaks existing scripts/user workflows 🙈
I also thought about this. Would it help that the checker first checks if a file "file.txt:5" already exists and in this case does not interpret the ":5" as line number?
Please, if you do AI to generate a new PR, please mention this.
yes, i had some help, but I also tracked that the AI does not boogie-woogie with the repo's source code :D
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)See :help +cmd Extending this to also accept a column might be a reasonable addition.
I checked briefly. The +cmd is part of posix, but since there is no valid : command, that should be possible I would think?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)I also thought about this. Would it help that the checker first checks if a file "file.txt:5" already exists and in this case does not interpret the ":5" as line number?
Would we really need this for ex commands? I am not so sure about this. For command line parsing this might be possible however.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#18689)I checked briefly the POSIX specs The
+cmdis part of POSIX, but since there is no valid:command, that should be possible I would think?
Well +42:cmd is valid for a range accepting cmd but +42:{digit} always fails as an invalid command.
I'm not really championing the feature but even if this PRs proposal is workable I think +{lnum} should be updated in lockstep if possible.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
carli2
@carli2 pushed 1 commit.
- 747582e Support column offsets in +cmd
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
carli2
carli2 left a comment (vim/vim#18689)The reason I'm doing this PR is that lot of tools and compilers always output errors in the format filename:line:column
since I'm working with pretty big files, in the current version of vim I have to memorize the line number, copy the filename (without colons) and then type "[LINENUMBER]gg". This feature request makes it much more user-friendly.
Is there anything that I can adjust to make this PR mergeable? Are there things that still have to be discussed? May it be that we define a feature definition first and then reimplement it following the then-created specs?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)There are a few vim plugins for this, see here: #9144 (comment)
Doesn't that work for you already?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18689)Since this issue recurs regularly with many duplicates, should the doc point to these plug-ins or one try to build it in?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)yeah, might make sense.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18689)compilers always output errors in the format filename:line:column
@carli2 the fetch plug-in also handles other variants and seems rather robust.
Still, it would make users' life more convenient if Vim could handle them out of the box
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#18689)What & Why
Opening a file at a specific spot is second nature in shells (
vim src/main.c:42:7), but Vim only honored that syntax on the first command-line argument. Anything routed through:tabedit, arglists (args,next,drop), or even GUI drag-and-drop silently treated:42:7as part of the filename. This change makes thefile:line[:col]idiom a first-class citizen everywhere: the suffix is stripped once, stored alongside the argument, and the cursor is driven to that location whenever the entry is opened (unless the user supplies their own+cmd).
As far as I can tell, the premise here is faulty. On recent Vim (9.1.1775), none of vim file:line or vim file:line:col work for me (they all consider the entire argument the file name, as expected).
User-visible changes
vim foo.ts:120:4,:tabedit foo.ts:120,args foo.ts:120,drop foo.ts:120(including drag-and-drop) now all land exactly where requested—only the firstfile:line[:col]token is
rewritten, and line/column numbers clamp to 1.- Subsequent navigation (
:next,:drop,argdo, etc.) preserves the recorded location so you can sprinkle positional suffixes across an arglist and walk through them.- Column jumps work too:
file:42:8becomes+call cursor(42,8)under the hood so long lines open with the cursor already at the right column.
Not entirely unreasonable, but as pointed out this should only trigger if the original syntax is not an existing file (and there should be a way to forcibly open a new file that uses this syntax, disabling the smarts).
Why merge this
- Aligns expectations between CLI usage and in-editor workflows—no more surprises when
:tabedit foo:99opens a new buffer literally namedfoo:99.
I know some folks are surprised by this, but I wonder where that surprise stems from and if we can address it's root more easily. I've never personally developed that expectation, especially since (as mentioned at the top) the example shell invocation does not do for me what you said it does.
- Boosts productivity for anyone juggling compiler errors, test failures, or diagnostics that already emit
file:line[:col]links.
This is what quickfix and location lists are for, especially with :compiler scripts. (It might be nice to have a way to quickly turn text in a :terminal window into a quickfix list, though; I think :[range]cbuffer more or less provides that.)
Please, if you do AI to generate a new PR, please mention this.
yes, i had some help, but I also tracked that the AI does not do boogie-woogie with the repo's source code :D
Not "boogie-woogie"-ing the code is not really sufficient disclosure, in my mind. See for example (all from git/git discussions):
- How does the use of the tool interact with your DCO obligation? (Not irrelevant for Vim, where a DCO applies and the maintainer often adds such a sign-off on your behalf1.)
- We need a direct answer to how your use of the tool affects your ability to license your contribution
- Other general concerns around the disclosure of such tools
The reason I'm doing this PR is that lot of tools and compilers always output errors in the format
filename:line:columnsince I'm working with pretty big files, in the current version of vim I have to memorize the line number, copy the filename (without colons) and then type "[LINENUMBER]gg". This feature request makes it much more user-friendly.
See above RE: quickfix lists, and you might want to learn how to use :cfile/:cbuffer/etc. in addition to the usual :grep/:make/…
To be clear about my own position:
- I think supporting something similar out of the box is a reasonable idea, but it needs care to preserve existing behavior and not induce more surprise.
- If there is genuine surprise about the use of colon-delimited error links, we might also want to address that somehow.
- I have concerns about the state of this PR's code contributions and the author's ability to sign them off.
- Where do we draw the line? Some tools use other formats—are they left out, or do we attempt to support them? (I'm genuinely not sure, but I feel it worth mentioning, just so there's a conscious decision.)
Footnotes
-
Legally, that seems a bit murky to me, but one thing at a time 😅 ↩
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
carli2
carli2 left a comment (vim/vim#18689)What & Why
Opening a file at a specific spot is second nature in shells (
vim src/main.c:42:7), but Vim only honored that syntax on the first command-line argument. Anything routed through:tabedit, arglists (args,next,drop), or even GUI drag-and-drop silently treated:42:7as part of the filename. This change makes thefile:line[:col]idiom a first-class citizen everywhere: the suffix is stripped once, stored alongside the argument, and the cursor is driven to that location whenever the entry is opened (unless the user supplies their own+cmd).As far as I can tell, the premise here is faulty. On recent Vim (9.1.1775), none of
vim file:lineorvim file:line:colwork for me (they all consider the entire argument the file name, as expected).
You are right. The PR consists of two commits, the first introduces file:line:col handline, the second one also delivers :tabedit support. I accidently copy&pasted only the message of the second commit into the PR
User-visible changes
vim foo.ts:120:4,:tabedit foo.ts:120,args foo.ts:120,drop foo.ts:120(including drag-and-drop) now all land exactly where requested—only the firstfile:line[:col]token is
rewritten, and line/column numbers clamp to 1.- Subsequent navigation (
:next,:drop,argdo, etc.) preserves the recorded location so you can sprinkle positional suffixes across an arglist and walk through them.- Column jumps work too:
file:42:8becomes+call cursor(42,8)under the hood so long lines open with the cursor already at the right column.Not entirely unreasonable, but as pointed out this should only trigger if the original syntax is not an existing file (and there should be a way to forcibly open a new file that uses this syntax, disabling the smarts).
Do you have any ideas to introduce an escaping scheme for that? I don't. And even if we introduce any escaping notation for that, the whole pipeline should support this.
The only thing I can think of is to leave the default behaviour as is and introduce a new flag --jump-to-line (+short form) that users can enable to get colons interpreted as line markers.
Why merge this
- Aligns expectations between CLI usage and in-editor workflows—no more surprises when
:tabedit foo:99opens a new buffer literally namedfoo:99.I know some folks are surprised by this, but I wonder where that surprise stems from and if we can address it's root more easily. I've never personally developed that expectation, especially since (as mentioned at the top) the example shell invocation does not do for me what you said it does.
A lot of compilers, debuggers, tools etc. print out filename:line:col triples, so for my convencience feeling, a good editor should be able to directly interpret this notation
- Boosts productivity for anyone juggling compiler errors, test failures, or diagnostics that already emit
file:line[:col]links.This is what quickfix and location lists are for, especially with
:compilerscripts. (It might be nice to have a way to quickly turn text in a:terminalwindow into a quickfix list, though; I think:[range]cbuffermore or less provides that.)
Do you mean by that to change the tools around vim (like the terminal emulator UIs) to translate the filename:line:col triples into proper vim opening commands? I consider this as impractical.
Please, if you do AI to generate a new PR, please mention this.
yes, i had some help, but I also tracked that the AI does not do boogie-woogie with the repo's source code :D
Not "boogie-woogie"-ing the code is not really sufficient disclosure, in my mind. See for example (all from git/git discussions):
* [How does the use of the tool interact with your DCO obligation](https://lore.kernel.org/git/xmqqo6p9zo8f.fsf@gitster.g/)? (Not irrelevant for Vim, where [a DCO applies](https://github.com/vim/vim/blob/3b682f56ac57aa054e8ba0bc0e6fd4cbcbf702cc/CONTRIBUTING.md?plain=1#L26-L32) and the maintainer often adds such a sign-off on your behalf[1](#user-content-fn-1-4a8c6e7ea51a43c65c53aa4b789782ac).) * [We need a direct answer to how your use of the tool affects your ability to license your contribution](https://lore.kernel.org/git/xmqq7bvwy3vi.fsf@gitster.g/) * [Other general concerns around the disclosure of such tools](https://lore.kernel.org/git/xmqqms4ok2xx.fsf@gitster.g/T/#m04de21e94f6b64a29791f0cf916f318a2620927f)
From the legal perspective, a computer program can not be a copyright owner. The copyright owner is always the user of the software. Hence, I see no concerns about the licensing. To enhance transparency, I can configure some standard signoff message if you want for every commit.
The reason I'm doing this PR is that lot of tools and compilers always output errors in the format
filename:line:column
since I'm working with pretty big files, in the current version of vim I have to memorize the line number, copy the filename (without colons) and then type "[LINENUMBER]gg". This feature request makes it much more user-friendly.See above RE: quickfix lists, and you might want to learn how to use
:cfile/:cbuffer/etc. in addition to the usual:grep/:make/…
To be clear about my own position:
* I think supporting something similar out of the box is a reasonable idea, but it needs care to preserve existing behavior and not induce more surprise.
Agreed
* If there is genuine surprise about the use of colon-delimited error links, we might also want to address that somehow.
Either with --enable-XXX or --disable-XXX ig
* I have concerns about the state of this PR's code contributions and the author's ability to sign them off.
So I should rebase them and commit with -s?
* Where do we draw the line? Some tools use other formats—are they left out, or do we attempt to support them? (I'm genuinely not sure, but I feel it worth mentioning, just so there's a conscious decision.)
Do you have examples or a complete list for other formats?
Footnotes
1. Legally, that seems a bit murky to me, but one thing at a time 😅 [↩](#user-content-fnref-1-4a8c6e7ea51a43c65c53aa4b789782ac)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#18689)Opening a file at a specific spot is second nature in shells
As far as I can tell, the premise here is faulty. On recent Vim (9.1.1775), none of
vim file:lineorvim file:line:colwork for me (they all consider the entire argument the file name, as expected).
You are right. The PR consists of two commits, the first introduces file:line:col handline, the second one also delivers :tabedit support. I accidently copy&pasted only the message of the second commit into the PR
Easy mistake, no worries. It certainly left me confused :)
Do you want to fix it to make it easier to digest the PR?
vim foo.ts:120:4,:tabedit foo.ts:120,args foo.ts:120,drop foo.ts:120(including drag-and-drop) now all land exactly where requested—only the firstfile:line[:col]token is
rewritten, and line/column numbers clamp to 1.- Subsequent navigation (
:next,:drop,argdo, etc.) preserves the recorded location so you can sprinkle positional suffixes across an arglist and walk through them.- Column jumps work too:
file:42:8becomes+call cursor(42,8)under the hood so long lines open with the cursor already at the right column.Not entirely unreasonable, but as pointed out this should only trigger if the original syntax is not an existing file (and there should be a way to forcibly open a new file that uses this syntax, disabling the smarts).
Do you have any ideas to introduce an escaping scheme for that? I don't. And even if we introduce any escaping notation for that, the whole pipeline should support this.
I don't, which makes this difficult. For example, I could imagine that :edit! <path> is always literal (abusing ! here for some extra semantics), but that doesn't help with vim <path>.
The only thing I can think of is to leave the default behaviour as is and introduce a new flag
--jump-to-line(+short form) that users can enable to get colons interpreted as line markers.
That might work at the shell. I suppose it could also be behind an 'option'.
- Aligns expectations between CLI usage and in-editor workflows—no more surprises when
:tabedit foo:99opens a new buffer literally namedfoo:99.I know some folks are surprised by this, but I wonder where that surprise stems from and if we can address it's root more easily. I've never personally developed that expectation, especially since (as mentioned at the top) the example shell invocation does not do for me what you said it does.
A lot of compilers, debuggers, tools etc. print out filename:line:col triples, so for my convencience feeling, a good editor should be able to directly interpret this notation
I can see how you might find that convenient! But that's not what the original said, and that's not the question I asked, so let me try again:
What leads people to think that :tabedit foo:99 or vim main.c:127 will work? Maybe we should try to address that.
- Boosts productivity for anyone juggling compiler errors, test failures, or diagnostics that already emit
file:line[:col]links.This is what quickfix and location lists are for, especially with
:compilerscripts. (It might be nice to have a way to quickly turn text in a:terminalwindow into a quickfix list, though; I think:[range]cbuffermore or less provides that.)Do you mean by that to change the tools around vim (like the terminal emulator UIs) to translate the filename:line:col triples into proper vim opening commands? I consider this as impractical.
That does sound impractical.
No, what I mean is:
- If you use
:compiler/:make, you don't have to juggle errors, test failures, or diagnostics: you use the quickfix list. Same for:grepwith searches, or arbitrary programs or files with various:c-prefix commands. (Andlfor location list.) - If you prefer to run the programs in a
:terminal, then you might need to get them into your quickfix list. Using:[range]cbufferseems like a nice way to do that.
Not "boogie-woogie"-ing the code is not really sufficient disclosure, in my mind. See for example (all from git/git discussions):
How does the use of the tool interact with your DCO obligation? (Not irrelevant for Vim, where a DCO applies and the maintainer often adds such a sign-off on your behalf1.)
From the legal perspective, a computer program can not be a copyright owner.
No, a computer is not a copyright owner (at least to the extent that I understand American copyright law—I am not a lawyer and I am not your lawyer). However, part of the way the DCO works is that you certify the following:
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
Can you attest to these claims? If not, you cannot sign off on this contribution under the DCO, and I don't think we can accept it.
The copyright owner is always the user of the software.
That is easily falsifiable: I own no copyright over Discord just because I use it.
Hence, I see no concerns about the licensing.
I do: see above. Can you certify that none of the produced code is covered under other copyright interest or licensing which prevents it from being contributed as-is? (Just as one example: say the code was part of an MIT-licensed project. One condition of that license is that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." That condition would presumably need to be met in such a contribution of the code in order to obey the terms of its license.)
To enhance transparency, I can configure some standard signoff message if you want for every commit.
No, you should not sign-off messages just to appease a requirement: you should do so (for this project!) to certify the above.
- If there is genuine surprise about the use of colon-delimited error links, we might also want to address that somehow.
Either with
--enable-XXXor--disable-XXXig
This seems like a non-sequitur to me? Maybe you meant that some feature could be conditionally compiled in, though I don't know what feature. I think a new conditional compilation flag has to justify its worth to grow the build surface, though (otherwise it could be an option unconditionally compiled in, for example).
- I have concerns about the state of this PR's code contributions and the author's ability to sign them off.
So I should rebase them and commit with
-s?
See above, that's not what I said.
- Where do we draw the line? Some tools use other formats—are they left out, or do we attempt to support them? (I'm genuinely not sure, but I feel it worth mentioning, just so there's a conscious decision.)
Do you have examples or a complete list for other formats?
I went looking; the first one I found is this ESLint definition. I certainly don't have a complete list.
I think it's worth deciding consciously for now what to include and what to exclude, just so the boundaries of the feature are clear. (Or, so that we can suggest new ways of approaching the problem: maybe a customizable resolver to parse messages and turn into the cursor() calls? OTOH, isn't that what the existing errorformat is? 🤔)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
arkissa
Arkissa left a comment (vim/vim#18689)That does sound impractical.
No, what I mean is:
If you use :compiler/:make, you don't have to juggle errors, test failures, or diagnostics: you use the quickfix list. Same for :grep with searches, or arbitrary programs or files with various :c-prefix commands. (And l for location list.)
If you prefer to run the programs in a :terminal, then you might need to get them into your quickfix list. Using :[range]cbuffer seems like a nice way to do that.
@benknoble, I’m not sure what your workflow looks like, but in my case I often use GDB or other debuggers to attach to my server application. Most debuggers print things like file:line or file:line:col for breakpoints, errors, exceptions, panics, and so on. When that happens, I usually have to manually split the : and replace it with + so I can use Vim to jump to the corresponding location in my project. This is quite inconvenient.
Vim can’t take messages from tools that behave like a REPL and then parse them into a valid format using errorformat to populate the quickfix list. So this isn’t an imaginary requirement—it's a very real one. I believe this need is not only from me or @carli2. If Vim could support this behavior out of the box, or through a builtin plugin, it would greatly improve the user experience.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18689)Vim can’t take messages from tools that behave like a REPL and then parse them into a valid format using errorformat to populate the quickfix list. So this isn’t an imaginary requirement—it's a very real one. I believe this need is not only from me or @carli2. If Vim could support this behavior out of the box, or through a builtin plugin, it would greatly improve the user experience.
vim -q <(echo buffer.c:15:10: .)
https://asciinema.org/a/M1GamwUJIAkj3ELlZY0MwOnxG
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
arkissa
Arkissa left a comment (vim/vim#18689)Vim can’t take messages from tools that behave like a REPL and then parse them into a valid format using errorformat to populate the quickfix list. So this isn’t an imaginary requirement—it's a very real one. I believe this need is not only from me or @carli2. If Vim could support this behavior out of the box, or through a builtin plugin, it would greatly improve the user experience.
vim -q <(echo buffer.c:15:10: .)
or to populate quickfix from grep:
vim -q <(grep -nw 'something' *.c)
@habamax This is great! It’s the first time I’ve learned about the -q command flag—you taught me a neat trick—but this doesn’t really solve our actual problem, right? I still can’t directly vim file:line:col to open a file; I still have to use a script to wrap my input, for example:
# script vimq #!/bin/env bash vim -q <(echo "${1}: .") # usege: # $ vimq file:line:col
But if I need to open multiple files, this script becomes more complicated, whereas using the arglist directly would be much simpler.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
carli2
carli2 left a comment (vim/vim#18689)Vim can’t take messages from tools that behave like a REPL and then parse them into a valid format using errorformat to populate the quickfix list. So this isn’t an imaginary requirement—it's a very real one. I believe this need is not only from me or @carli2. If Vim could support this behavior out of the box, or through a builtin plugin, it would greatly improve the user experience.
vim -q <(echo buffer.c:15:10: .)https://asciinema.org/a/M1GamwUJIAkj3ELlZY0MwOnxG
or to populate quickfix from grep:vim -q <(grep -nw 'something' *.c)@habamax This is great! It’s the first time I’ve learned about the
-qcommand flag—you taught me a neat trick—but this doesn’t really solve our actual problem, right? I still can’t directlyvim file:line:colto open a file; I still have to use a script to wrap my input, for example:# script vimq #!/bin/env bash vim -q <(echo "${1}: .") # usege: # $ vimq file:line:colBut if I need to open multiple files, this script becomes more complicated, whereas using the
arglistdirectly would be much simpler.
vimq and we also have to introduce :tabeq :D
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#18689)That does sound impractical.
No, what I mean is:
If you use :compiler/:make, you don't have to juggle errors, test failures, or diagnostics: you use the quickfix list. Same for :grep with searches, or arbitrary programs or files with various :c-prefix commands. (And l for location list.)
If you prefer to run the programs in a :terminal, then you might need to get them into your quickfix list. Using :[range]cbuffer seems like a nice way to do that.@benknoble, I’m not sure what your workflow looks like, but in my case I often use GDB or other debuggers to attach to my server application. Most debuggers print things like file:line or file:line:col for breakpoints, errors, exceptions, panics, and so on. When that happens, I usually have to manually split the : and replace it with + so I can use Vim to jump to the corresponding location in my project. This is quite inconvenient.
Vim can’t take messages from tools that behave like a REPL and then parse them into a valid format using errorformat to populate the quickfix list. So this isn’t an imaginary requirement—it's a very real one. I believe this need is not only from me or @carli2. If Vim could support this behavior out of the box, or through a builtin plugin, it would greatly improve the user experience.
If you run gdb inside a :terminal, then you can select the area visually and
do :cbuffer (with the auto-visual range '<,'>).
If you run GDB in another terminal, you could copy the relevant text and do
something like
:cexpr system('pbpaste') " or :cexpr system('xsel -bo') " or :cexpr system('tmux show-buffer')
Right?
I do think adding a whole family of :editq commands would nicely resolve the
ambiguity, and you could do :editl if you want the location list. But that's a
lot of commands to add 😅
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#18689)I do think adding a whole family of :editq commands would nicely resolve the
ambiguity, and you could do :editl if you want the location list. But that's a
lot of commands to add
We're having an analog discussion #18337 (comment) and the common work around seems to be a ++flag, though that's a bit of work to type it out on the command-line
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18689)closing
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18689.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.