On 10 July 2016, Bram Moolenaar <[email protected]> wrote:
>
> Lcd wrote:
>
[...]
> > Currently an error item from loclist looks like this:
> >
> > {
> > 'lnum': 148,
> > 'bufnr': 1,
> > 'col': 7,
> > 'valid': 1,
> > 'vcol': 0,
> > 'nr': -1,
> > 'type': 'W',
> > 'pattern': ',
> > 'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs used (See
> > page 20 of PBP)'
> > }
> >
> > If I want to place a sign at the file, I can do this:
> >
> > sign place 12345 line=148 name=SyntasticError buffer=1
> >
> > This works regardless if the fuffer is hidden or not, and can be
> > done before the user jumps to the error.
> >
> > How would I do the same starting only with a filename, assuming
> > the user hasn't jumped to the error yet, or opened the file?
>
> Yeah, when using getqflist() or getloclist() we currently only get the
> "bufnr". This I would think, by default the file name is changed to
> a buffer at that point. Since this can be expensive, we could add an
> argument to return the file name instead of a buffer number.
>
> So we have a dilemma: For the plugin that intentionally avoids
> creating a buffer for every error, it can have these extra options
> to make it (a lot) faster. But as soon as another plugin comes into
> play, which depends on the buffer, things fall back to how they were.
> I think that is unavoidable.
So functions that create qflists and loclists (make, cgetexpr etc.)
would create them with filenames, and it would be up to getqflist()
and getloclist() to request the corresponding files to be loaded
into buffers (with the default being to load files, for backwards
compatibility). Also, the results could be cached. That would work
nicely, and it wouldn't be slower for plugins that want old-style
qflists and loclists.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
