[vim/vim] Option to set quickfix item limit (Issue #10266)
Sharlock93
As mentioned in issue #4780 items in the quickfix window are limited to 1023 bytes.
I was wondering if its possible to add an option to set this limit in .vimrc?
looking at the source code it seems IObuff is allocated very early on so maybe its not possible to do this via .vimrc but maybe from the command line?
I changed IOSIZE manually and recompiled, seems to work well enough.
For context: I use a plugin (asyncrun) to run files which captures the stdout and puts them into quickfix.
And vulkan validation messages (some of them) go over the 1024 byte limit which gets truncated in the quickfix window.
I was bitten by this because I didn't know the validation messages could be that long.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> As mentioned in issue #4780 items in the `quickfix` window are limited to 1023 bytes.
> looking at the source code it seems `IObuff` is allocated very early on so maybe its not possible to do this via `.vimrc` but maybe from the command line?
> I changed `IOSIZE` manually and recompiled, seems to work well enough.
>
> For context: I use a plugin (asyncrun) to run files which captures the `stdout` and puts them into quickfix.
> And vulkan validation messages (some of them) go over the 1024 byte limit which gets truncated in the quickfix window.
> I was bitten by this because I didn't know the validation messages could be that long.
For the quickfix window the idea was that there is not so much need for
displaying very long lines. But there might be cases where relevant
info is at the end and gets dropped. Is that what happens for you?
It would just be a matter of allocating a bigger buffer, which isn't
really much of a problem these days.
--
Don't read everything you believe.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Sharlock93
But there might be cases where relevant info is at the end and gets dropped. Is that what happens for you?
Indeed that is the case here is a screenshot:
It would just be a matter of allocating a bigger buffer, which isn't really much of a problem these days.
I would assume even if you increase the
IOSIZEto something much larger due to it being static it might still be a problem,
looking at the source code again I don't quite understand why qf_get_next_file_line grows the buffer until it reaches LINE_MAXLEN but then goes on to discard all the read data? this is just a quick glance so I might be missing something.
Ideally I think having an option to set LINE_MAXLEN or IOSIZE would be the best option but I don't know enough about the code to see the ramifications
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > But there might be cases where relevant info is at the end and gets dropped. Is that what happens for you?
>
> Indeed that is the case here is a screenshot:
>
> > It would just be a matter of allocating a bigger buffer, which isn't
> > really much of a problem these days.
> I would assume even if you increase the `IOSIZE` to something much
> larger due to it being static it might still be a problem,
would need to check all of them to make sure there won't be a problem.
> looking at the source code again I don't quite understand why
> `qf_get_next_file_line` grows the buffer until it reaches
> `LINE_MAXLEN` but then goes on to discard all the read data? this is
> just a quick glance so I might be missing something.
> Ideally I think having an option to set `LINE_MAXLEN` or `IOSIZE`
> would be the best option but I don't know enough about the code to see
> the ramifications
LINE_MAXLEN is more a safety against reading a bogus error file. E.g.
when accidentally using a binary file.
--
hundred-and-one symptoms of being an internet addict:
42. Your virtual girlfriend finds a new net sweetheart with a larger bandwidth.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Sharo
Increasing IOSIZE is not a good way, it is used in many places and you would need to check all of them to make sure there won't be a problem.
Yeah this is what I was worried about, updating IOSIZE directly while it worked for me as a test it wouldn't be safe to just change that and even if it was safe what size would you pick?
Unfortunately due to starting a new job I cannot dedicate enough time to this. It would be amazing to have it implemented in someway even if its at the compilation level.
At this point you can leave the issue open if there is a chance of it being implement it or you can close it. Thank you.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Maybe @yegappan can look into this, he has done work on quickfix before.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
I have created PR #11357 to address this issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Thanks for the quick reply. I have included the PR, therefore closing.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #10266 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.