Re: quickfix information

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: quickfix information

Yegappan Lakshmanan

I am reviving an old thread.

On Monday, April 13, 2015 at 5:04:20 AM UTC-7, [hidden email] wrote:

> Hello,
> I did not expect that many reactions. This is nice.  Thank you all for
> your interest in the matter.
> > > Ah, but as long as you are OK with that information showing up in
> > > the title, if you can set w:quickfix_title to an arbitrary string,
> > > then you *can* store arbitrary data associated with a given
> > > quickfix list.
> >
> > 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.
> Indeed, having "ancillary" data would be much more easier to use.
> Storing several variables in the w:quickfix_title wouldn't very
> practical. Actually, I want to export several buffer-local variables
> to the quickfix buffer. I use some of them to conceal part of the
> generated error messages, other like &l:tags are required to be able
> to jump on definition/declaration from identifiers found in the error
> messages, &l:makeprg will be needed in order to have :make compile the
> same thing, others variables (like project and compilation mode) will
> be displayed in the status(air)line, etc.

Patch 8.0.0590 added support for adding context information to the quickfix
and location lists. You can now use the setqflist() and getqflist() commands
to set and get context information.

- Yegappan

> Moreover, I've experienced some odd behaviours regarding the
> w:quickfix_title -- as it's automatically set to things like
> "setqflist()".
> [I can't really comment on the other internal ways of handling
> quickfix data]
> Thus, I take notice so far that there is no neat way to store
> variables along with a quickfix list. An optional data field would do
> the trick. I guess it would be more expensive than what I need, but it
> would do the trick.
> Thank you all anyway.
> I'll try to override the meaning of "nr" field for my needs.
> --
> Luc Hermitte

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

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 [hidden email].
For more options, visit