Hi,

On Sun, Sep 11, 2016 at 4:08 AM, LCD 47 <lcd...@gmail.com> 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.
>

I am working on additional changes to getqflist/getloclist() and
setqflist/setloclist() to get and set the list items. Along with the
pending patch for getting/setting the context, you can use
this to save and restore any quickfix/location list. I am also
working on a patch for getting/setting the stack. Now that Vim 8.0
is out, Bram may not include any major changes for quite some
time (based on past precedence).

>
>     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.
>

You can set the 'nr' key to -1 when calling the getqflist()/getloclist()
function to use the current list.

>
> 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.
>

What do you think about modifying the getqflist()/getloclist() functions
to use the top of the list if 'nr' is set to a value large than (10)?

- Yegappan

>
>     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.
>
>     /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.

Raspunde prin e-mail lui