On 12 April 2015, Christian Brabandt <cbli...@256bit.org> wrote:
> On Sa, 11 Apr 2015, LCD 47 wrote:
> > On 11 April 2015, Christian Brabandt <cbli...@256bit.org> wrote:
> > > On Sa, 11 Apr 2015, LCD 47 wrote:
> > >
> > > > Being able to save "ancillary" data in quickfix lists /
> > > > loclists as the OP suggests would be quite useful too. Then
> > > > w:quickfix_title could be saved there, and that would be easier
> > > > to implement than keeping track of updates to w:quickfix_title.
> > >
> > > Like what? Only save a custom dict, like w:quickfix_data?
> >
> > Right now setqflist() takes a list of dictionaries as an
> > argument. What I had in mind was an extra field (say, 'data')
> > in these dictionaries, pointing to a value of some unspecified
> > type. These fields would be saved by setqflist() and restored by
> > getqflist(), but would be ignored when showing the quickfix list in
> > a window.
>
> You need a custom data type for each quickfix item?
Actually, I need a custom data type for each compiler. This
translates to a set of custom attributes for each error item. The set
of attributes is the same for all errors in a list, but it may vary with
the compiler: sometimes it's just a second column field, sometimes I
need full coordinates for syntax highlighting, and sometimes it's useful
to flag various parsing conditions.
Things would be a lot simpler if the internal functions dealing with
errors would be able to work with the representation of a dict, rather
than a qfline_T. But, I don't think this is going to happen. :)
> > Also it would be tremendously useful to have a new %-format for
> > errorformat and friends, that would write to (subfields of) the new
> > 'data' field. Or perhaps some kind of mechanism that would direct
> > the output of an existing %-format to (subfields of) the 'data'
> > field. Right now, the only way to parse things like multiple column
> > numbers from a single line of compiler output is to do it with
> > the (otherwise mostly useless) %n, and post-process the resulting
> > quickfix.
>
> I am not sure about how to approach this one.
[...]
Well, the tricky part here is comming up with a meaningful design
that is backward compatible. The closest thing that comes to mind is
Python's format():
https://docs.python.org/2/library/string.html#formatstrings
But that's an output format, while we'd need a scanf(3)-type thing.
Given a design, I'd say the implementation would be straightforward
though. All the interesting pieces are in qf_init_ext().
/lcd
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
