Lcd wrote: > On 12 August 2016, Bram Moolenaar <[email protected]> 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. -- hundred-and-one symptoms of being an internet addict: 232. You start conversations with, "Have you gotten an ISDN line?" /// 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.
