Yegappan Lakshmanan wrote:
> 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.
The number of commands and functions for quickfix functionality keeps
growing. It would be good to reduce this a bit.
getqflist() currently does not take an argument. It could use an
argument to specify what to get, instead of the whole list.
So how about passing a dictionary? One of the items could be to get the
aux data instead of the list of errors.
For setqflist() it's a bit more tricky, since it already has a second
"action" argument. But we can add the dictionary as the third argument.
Perhaps getting and setting the quickfix title would also fit in here?
And it allows for the filtering that we had a patch for?
Would be good to get an overview before making more changes.
--
GUARD #2: Wait a minute -- supposing two swallows carried it together?
GUARD #1: No, they'd have to have it on a line.
GUARD #2: Well, simple! They'd just use a standard creeper!
GUARD #1: What, held under the dorsal guiding feathers?
GUARD #2: Well, why not?
The Quest for the Holy Grail (Monty Python)
/// 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.
