On 17 July 2016, Yegappan Lakshmanan <[email protected]> wrote:
> Hi,
>
> On Mon, Apr 13, 2015 at 5:04 AM, <[email protected]> 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.
> >
> > 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.
> >
>
> I am attaching a patch to add the following functions to store and
> retrieve a context from a location/quickfix list:
>
> setqflistctx()
> getqflistctx()
> setloclistctx()
> getloclistctx()
>
> The context can be any Vim variable type.
>
> The patch also adds the following functions to set/get the title
> string:
>
> setqflisttitle()
> getqflisttitle()
> setloclisttitle()
> getloclisttitle()
>
> Let me know if you have any comments/suggestions on these functions.
Since you ask: in my opinion this is designed from the perspective
of a Vim's patcher, not from that of a Vim's user. The "ancillary" data
should be a special field in the location/quickfix list, and it should
be accessible as such, not through special getters and setters.
Having to access the data through getters and setters reminds me
of code for embedded appliances, where in order to set a variable to a
16-bits integer you need to write the first 12 bits in machine order
to port 25, and the last 3 bits in big endian order to port 31. It
works, sort of, but it's a pain for the user, and it makes Java code
look concise.
> I will add the tests for these functions later.
/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.
