On 17 July 2016, Yegappan Lakshmanan <[email protected]> wrote:
> Hi,
>
> On Sun, Jul 17, 2016 at 10:00 PM, LCD 47 <[email protected]> wrote:
> > 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.
> >
>
> The 'ancillary' data is a special field in the internal
> location/quickfix list.
>
> Are you looking for setting the context using the setqflist() and
> setloclist() functions? These functions can be extended to take the
> context.
>
> But it will be difficult to extend the getqflist() function to return
> the context though. The getqflist() function currently returns a list.
> I am not sure how to extend this function to return the entries and
> context without breaking backward compatibility.
I believe this has been discussed in some detail in the past.
There are two kinds of ancillary data that would be useful, a per-item
extra field, and a per-list variable (what you call "context").
In my experience the per-item version would be far more useful than
the per-list one, but it would be tricky to implement since it would
turn a list (the location/quickfix list) into a sort of mixture between
a list and a dictionary (per-item data would need reference counts and
so on).
On the other hand, the per-list variable could actually cover both
cases, since it can be a list itself. However, the interface would be
a pain for the user, since it would be the user's job to correlate the
data with the error items.
Per-item data can be implemented without changinging the interface.
Per-list data can be implemented with either getters and setters, or
with an extra parameter to getqflist() / getloclist() and setloclist()
/ setqflist() (or both). I'm not convinced getters and setters is the
better choice.
/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.
