On 16 September 2016, Yegappan Lakshmanan <yegapp...@gmail.com> wrote:
> 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.

    This doesn't seem to work, getloclist(0, {'nr': -1}) always seems
to return an error:

        :echo getloclist(0, {'all': 1})
        {'nr': 2, 'winid': 1001, 'title': ':SyntasticCheck gcc (c)'}

        :echo getloclist(0, {'nr': -1})

> > 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)?

    As I see it, the main problem with "nr" right now is that you can't
get any clue about its possible values.  That's why it would be useful
to get information about the stack (mainly current and maximum depth,
and current pointer).

    Using the top of the list when "nr" is too large is just a
convention.  It may or may not be the right thing to do (I can't really
put it in a context to get an idea about its usefulness), but adding
more conventions and magic numbers won't solve the problem of finding
where you are on the stack.


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

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