On 11 September 2016, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Lcd wrote:
>
> > On 12 August 2016, Bram Moolenaar <b...@moolenaar.net> wrote:
> > >
> > > Patch 7.4.2200
> > > Problem: Cannot get all information about a quickfix list.
> > > Solution: Add an optional argument to get/set loc/qf list(). (Yegappan
> > > Lakshmanan)
> > [...]
> > > + If the optional {what} dictionary argument is supplied,
> > > then
> > > + returns only the items listed in {what} as a
> > > dictionary. The
> > > + following string items are supported in {what}:
> > > + nr get information for this quickfix list
> > > + title get list title
> > > + winid get window id (if opened)
> > > + all all of the above quickfix properties
> > > + Non-string items in {what} are ignored.
> > > + If "nr" is not present then the current quickfix list
> > > is used.
> > [...]
> >
> > I'm trying to make sure a plugin is not messing with some other
> > plugin's loclists. Towards that purpose, being able to set and get
> > a loclist's title is useful but not enough.
> >
> > One possible solution would be for loclists (and quickfix lists)
> > to have globally unique IDs. This ID could be as simple as a
> > global, always increasing sequence number that would be assigned to
> > loclists upon their creation, independently of the starting window.
> > Of course, getloclist() should be able to return this number upon
> > request.
> >
> > Another possible solution would be to track the current loclist
> > using the "nr" above, which is essentially the index of the current
> > loclist in the loclist stack. This is more problematic, as the
> > current interface is incomplete. It isn't possible to get the
> > current depth of the stack, and the only way to get the "nr" for
> > the current loclist is to query for "all" and ignore the irrelevant
> > fields in the result. These could be addressed by adding a new
> > field, say "max", that would return the current stack depth, and by
> > making a query for { "nr": 0 } return (just) the "nr" of the current
> > loclist.
> >
> > More seriously however, there is no way to tell when the stack
> > is full, and when some older loclists have been recycled. I also
> > don't think there is any way to explicitly discard a specific
> > loclist. Doing something like
> >
> > call setloclist(0, [], 'r')
> >
> > might have that effect (I haven't checked), but some more direct
> > cleanup mechanism that would free() all structures involved would be
> > nice.
> >
> > Yet another possible solution would be to add to loclists (and
> > quickfix lists) a field named, say, "owner" that would be get-able
> > and set-able. I think an unique ID would be preferrable though.
>
> Makes sense. For the same reason we added the window ID. So next to
> the title we can have a unique ID.
>
> I suppose we should then also have a function to get the list of IDs.
> In a way it maps to the index number.
A function to manipulate the stack could handle that. Christian
Brabandt posted something like that a while ago, but had a number of
bugs, and it tried to return the contents of the loclists, which could
be potentially huge. I think something that would just dump the list of
IDs, move the stack pointer around would be enough for most uses. Pop
would be nice too, but push probably doesn't make complete sense.
That would solve the problem of finding out when some loclists have
been recycled.
/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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
