Support file:line colon suffixes across entry points #18689
Conversation
| if (suffix == NULL || line_start == NULL) | ||
| return FAIL; | ||
|
|
||
| { |
There was a problem hiding this comment.
{ (and its matching }) isn't needed. Let's leave the optimization to the compiler.
| return FAIL; | ||
| } | ||
|
|
||
| { |
| *fname_len = len; | ||
| } | ||
|
|
||
| { |
|
Unless I am missing something, this would be a backwards incompatible change. What happens if I want to open a literal file name
What is
And breaks existing scripts/user workflows 🙈 Please, if you do AI to generate a new PR, please mention this. |
|
See |
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?
yes, i had some help, but I also tracked that the AI does not do boogie-woogie with the repo's source code :D |
I checked briefly the POSIX specs The |
Would we really need this for ex commands? I am not so sure about this. For command line parsing this might be possible however. |
Well I'm not really championing the feature but even if this PRs proposal is workable I think |
|
The reason I'm doing this PR is that lot of tools and compilers always output errors in the format 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? |
|
There are a few vim plugins for this, see here: #9144 (comment) Doesn't that work for you already? |
|
Since this issue recurs regularly with many duplicates, should the doc point to these plug-ins or one try to build it in? |
|
yeah, might make sense. |
@carli2 the fetch plug-in also handles other variants and seems rather robust. |
As far as I can tell, the premise here is faulty. On recent Vim (9.1.1775), none of
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).
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.
This is what quickfix and location lists are for, especially with
Not "boogie-woogie"-ing the code is not really sufficient disclosure, in my mind. See for example (all from git/git discussions):
See above RE: quickfix lists, and you might want to learn how to use To be clear about my own position:
Footnotes
|
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
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
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
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.
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.
Agreed
Either with
So I should rebase them and commit with
Do you have examples or a complete list for other formats?
|
Easy mistake, no worries. It certainly left me confused :) Do you want to fix it to make it easier to digest the PR?
I don't, which makes this difficult. For example, I could imagine that
That might work at the shell. I suppose it could also be behind an
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
That does sound impractical. No, what I mean is:
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:
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.
That is easily falsifiable: I own no copyright over Discord just because I use it.
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.)
No, you should not sign-off messages just to appease a requirement: you should do so (for this project!) to certify the above.
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).
See above, that's not what I said.
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 |
@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. |
https://asciinema.org/a/M1GamwUJIAkj3ELlZY0MwOnxG or to populate quickfix from grep: |
@habamax This is great! It’s the first time I’ve learned about the # 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 |
vimq and we also have to introduce :tabeq :D |
If you run If you run GDB in another terminal, you could copy the relevant text and do :cexpr system('pbpaste')
" or
:cexpr system('xsel -bo')
" or
:cexpr system('tmux show-buffer')Right? I do think adding a whole family of |
We're having an analog discussion #18337 (comment) and the common work around seems to be a |
|
closing |
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-classcitizen 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).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 isrewritten, and line/column numbers clamp to 1.
:next,:drop,argdo, etc.) preserves the recorded location so you can sprinkle positional suffixes across an arglist and walk through them.file:42:8becomes+call cursor(42,8)under the hood so long lines open with the cursor already at the right column.Why merge this
:tabedit foo:99opens a new buffer literally namedfoo:99.file:line[:col]links.Technical details
parse_cmd_file_arg()helper and integrated it intomain.cso the firstfile:line[:col]argument (after stripping optional:TaBe) isrewritten into the proper
+{line}or+call cursor(line,col)form while respecting options that consume the next token.do_exedit()and arglist navigation (do_argfile, drag/drop paths) to trim:line[:col]suffixes before editing, remember the requested coordinates oneach arglist entry, and move the cursor to the recorded line/column when no user
+cmdoverrides them.test_startup.vim,test_tabpage.vim, andtest_arglist.vimfor CLI invocations, tab commands, drag-and-drop, and arglist workflows to ensure thenew behavior is stable.
Testing