Lcd wrote:
> > > > > > > On 7 July 2016, Bram Moolenaar <[email protected]> wrote:
> > > [...]
> > > > > > I don't understand. What does "access to a buffer" mean?
> > > > >
> > > > > Syntastic is a sort of generalised compiler set, it runs
> > > > > external compilers, and shows the results in a loclist. Except
> > > > > it does a lot more than just open the loclist: it places signs,
> > > > > adds highlighting patterns, shows errors in balloons, shows the
> > > > > nearest error, and so on. There is some bookkeeping involved,
> > > > > and syntastic needs actual buffers to set local options, local
> > > > > variables, place signs, munge error messages according to
> > > > > context, check that error lines are not outside the file, and
> > > > > the like. Could all that be done starting from filenames?
> > > > > Probably, with a rewrite from scratch of the core. Somebody
> > > > > else might even take up that task some day.
> > > > >
> > > > > > Anyway, the idea was that this is only used for specific
> > > > > > purposes where a buffer is not needed, e.g. a list of matches
> > > > > > for "grep".
> > > > >
> > > > > The point is, there will be two kinds of loclists: "rich"
> > > > > ones (with buffers), and "poor" ones (with filenames).
> > > > > Syntastic would need to deal with both.
> > > >
> > > > I don't see the problem. If syntastic wants to do something that
> > > > requires a buffer, then it opens that buffer. The only difference
> > > > is that the buffer is created later, not when the item is added to
> > > > the quickfix list.
> > >
> > > As I said, doing that would involve rewriting the core from
> > > scratch.
> > >
> > > Admitting for the sake of the argument that rewriting wouldn't
> > > be a problem, let's say there's a file "example.c" that's mentioned
> > > in the list of errors, and I want to place a sign in it. The file
> > > is not open, how would I do that? Let's say I open the file and
> > > place the sign. Would jumping to the file from the loclist re-use
> > > my buffer?
> >
> > Sorry, I still don't see a problem. As soon as it tries to get the
> > buffer it will exist. How does it currently get the buffer?
>
> 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.
--
hundred-and-one symptoms of being an internet addict:
260. Co-workers have to E-mail you about the fire alarm to get
you out of the building.
/// Bram Moolenaar -- [email protected] -- 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 ///
--
--
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.
