Re: Patch 7.4.2200

[Yegappan Lakshmanan]

Hi Bram,

On Tue, Sep 27, 2016 at 12:29 PM, Bram Moolenaar  wrote:
>
> Yegappan Lakshmanan wrote:
>
>> On Fri, Sep 16, 2016 at 11:32 PM, LCD 47  wrote:
>> > On 16 September 2016, Yegappan Lakshmanan  wrote:
>> >> Hi,
>> >>
>> >> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
>> >> > On 12 August 2016, Bram Moolenaar  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)
>> >> >
>> >> > 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})
>> > {}
>> >
>>
>> I am attaching a patch to return information about the current
>> quickfix/location list, if the 'nr' field is set to zero.
>>
>> Without this change, to get the current quickfix/location list
>> number, you need to set 'all' to 1, leave out 'nr' and then parse the
>> returned information (as you suggested above).
>
> Thanks.  I'll add a simple test, but perhaps you can test some more.
>

The test looks good to me and I think this is sufficient to
test this feature.

Regards,
Yegappan

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

Re: Patch 7.4.2200

[LCD 47]

On 27 September 2016, Yegappan Lakshmanan  wrote:
> Hi,
> 
> On Fri, Sep 16, 2016 at 11:32 PM, LCD 47  wrote:
> > On 16 September 2016, Yegappan Lakshmanan  wrote:
> >> Hi,
> >>
> >> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
> >> > On 12 August 2016, Bram Moolenaar  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)
> >> >
> >> > 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})
> > {}
> >
> 
> I am attaching a patch to return information about the current
> quickfix/location list, if the 'nr' field is set to zero.
>
> Without this change, to get the current quickfix/location list number,
> you need to set 'all' to 1, leave out 'nr' and then parse the returned
> information (as you suggested above).

Works as expected, thank you!

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

Re: Patch 7.4.2200

[Bram Moolenaar]

Yegappan Lakshmanan wrote:

> On Fri, Sep 16, 2016 at 11:32 PM, LCD 47  wrote:
> > On 16 September 2016, Yegappan Lakshmanan  wrote:
> >> Hi,
> >>
> >> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
> >> > On 12 August 2016, Bram Moolenaar  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)
> >> >
> >> > 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})
> > {}
> >
> 
> I am attaching a patch to return information about the current
> quickfix/location list, if the 'nr' field is set to zero.
> 
> Without this change, to get the current quickfix/location list
> number, you need to set 'all' to 1, leave out 'nr' and then parse the
> returned information (as you suggested above).

Thanks.  I'll add a simple test, but perhaps you can test some more.

-- 
ARTHUR:Well, it doesn't matter.  Will you go and tell your master that
   Arthur from the Court of Camelot is here.
GUARD #1:  Listen, in order to maintain air-speed velocity, a swallow
   needs to beat its wings 43 times every second, right?
ARTHUR:Please!
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.2200

[Yegappan Lakshmanan]

Hi,

On Fri, Sep 16, 2016 at 11:32 PM, LCD 47  wrote:
> On 16 September 2016, Yegappan Lakshmanan  wrote:
>> Hi,
>>
>> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
>> > On 12 August 2016, Bram Moolenaar  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)
>> >
>> > 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})
> {}
>

I am attaching a patch to return information about the current
quickfix/location list, if the 'nr' field is set to zero.

Without this change, to get the current quickfix/location list
number, you need to set 'all' to 1, leave out 'nr' and then parse the
returned information (as you suggested above).

- Yegappan

-- 
-- 
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.
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 43d1883..4e01477 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -4521,7 +4521,8 @@ getqflist([{what}])   
*getqflist()*
winid   get the |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.
+   If "nr" is zero or is not present then the current quickfix
+   list is used.
In case of error processing {what}, an empty dictionary is
returned.
 
diff --git a/src/quickfix.c b/src/quickfix.c
index 51c894b..d2bac05 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -4591,9 +4591,14 @@ get_errorlist_properties(win_T *wp, dict_T *what, dict_T 
*retdict)
/* Use the specified quickfix/location list */
if (di->di_tv.v_type == VAR_NUMBER)
{
-   qf_idx = di->di_tv.vval.v_number - 1;
-   if (qf_idx < 0 || qf_idx >= qi->qf_listcount)
-   return FAIL;
+   if (di->di_tv.vval.v_number == 0)
+   qf_idx = qi->qf_curlist;/* use the current list */
+   else
+   {
+   qf_idx = di->di_tv.vval.v_number - 1;
+   if (qf_idx < 0 || qf_idx >= qi->qf_listcount)
+   return FAIL;
+   }
flags |= QF_GETLIST_NR;
}
else

Re: Patch 7.4.2200

[LCD 47]

On 16 September 2016, Yegappan Lakshmanan  wrote:
> Hi,
> 
> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
> > On 12 August 2016, Bram Moolenaar  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.

/lcd

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

Re: Patch 7.4.2200

[Yegappan Lakshmanan]

Hi,

On Sun, Sep 11, 2016 at 4:08 AM, LCD 47  wrote:
> On 12 August 2016, Bram Moolenaar  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.

Re: Patch 7.4.2200

[LCD 47]

On 11 September 2016, Bram Moolenaar  wrote:
> 
> Lcd wrote:
> 
> > On 12 August 2016, Bram Moolenaar  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.

Re: Patch 7.4.2200

[Bram Moolenaar]

Lcd wrote:

> On 12 August 2016, Bram Moolenaar  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 -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.2200

[LCD 47]

On 12 August 2016, Bram Moolenaar  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.

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

Re: Patch 7.4.2200

[Bram Moolenaar]

John Marriott wrote:

> On 13-Aug-2016 12:29 AM, Bram Moolenaar 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)
> > Files:  runtime/doc/eval.txt, src/evalfunc.c, src/proto/quickfix.pro,
> >  src/quickfix.c, src/tag.c, src/testdir/test_quickfix.vim
> >
> >
> After this patch I get the following warning (mingw64) if FEAT_QUICK_FIX 
> is not defined:
> gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 
> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32
>   -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer 
> -freg-struct-return -s evalfunc.c -o gobjnative/eva
> lfunc.o
> evalfunc.c:4697:1: warning: 'get_qf_loc_list' defined but not used 
> [-Wunused-function]
>   get_qf_loc_list(int is_qf, win_T *wp, typval_T *what_arg, typval_T *rettv)
>   ^~~
> 
> Please check the attached patch.

Thanks.  We can also drop the declaration.

-- 
hundred-and-one symptoms of being an internet addict:
18. Your wife drapes a blond wig over your monitor to remind you of what she
looks like.

 /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.2200

[John Marriott]

On 13-Aug-2016 12:29 AM, Bram Moolenaar 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)
Files:  runtime/doc/eval.txt, src/evalfunc.c, src/proto/quickfix.pro,
 src/quickfix.c, src/tag.c, src/testdir/test_quickfix.vim


After this patch I get the following warning (mingw64) if FEAT_QUICK_FIX 
is not defined:
gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 
-DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32
 -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer 
-freg-struct-return -s evalfunc.c -o gobjnative/eva

lfunc.o
evalfunc.c:4697:1: warning: 'get_qf_loc_list' defined but not used 
[-Wunused-function]

 get_qf_loc_list(int is_qf, win_T *wp, typval_T *what_arg, typval_T *rettv)
 ^~~

Please check the attached patch.
Cheers
John

--
--
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.
--- evalfunc_orig.c	2016-08-13 06:39:03.050027900 +1000
+++ evalfunc.c	2016-08-13 07:01:09.688973700 +1000
@@ -4691,12 +4691,12 @@
 get_buffer_lines(curbuf, lnum, end, retlist, rettv);
 }
 
+#ifdef FEAT_QUICKFIX
 static void get_qf_loc_list(int is_qf, win_T *wp, typval_T *what_arg, typval_T *rettv);
 
 static void
 get_qf_loc_list(int is_qf, win_T *wp, typval_T *what_arg, typval_T *rettv)
 {
-#ifdef FEAT_QUICKFIX
 if (what_arg->v_type == VAR_UNKNOWN)
 {
 	if (rettv_list_alloc(rettv) == OK)
@@ -4719,8 +4719,8 @@
 		EMSG(_(e_dictreq));
 	}
 }
-#endif
 }
+#endif
 
 /*
  * "getloclist()" function