[patch] get quickfix stack

[Christian Brabandt]

Bram,
here is a patch, that returns the complete quickfix/location list stack.
This is needed, so plugin writers can correctly handle quickfix and
location lists.
Currently, there is no way, to set the quickfix lists back to their
original values (without running through the complete stack (using
colder/lolder).

regards,
Christian
--
Unsere Zeit ist ein gro�er Wecker. Die gro�e eiserne Wanduhr rasselt
und ruft mit gewaltigen Schl�gen.
-- Johann Gottfried Herder

[Bram Moolenaar]

Christian Brabandt wrote:

> Bram,
> here is a patch, that returns the complete quickfix/location list stack.
> This is needed, so plugin writers can correctly handle quickfix and
> location lists.
> Currently, there is no way, to set the quickfix lists back to their
> original values (without running through the complete stack (using
> colder/lolder).

getlocstack() needs some more explanation about what it returns.
It's not obvious.

> +getqfstack({nr}) *getqfstack()*
> + Returns a dictionary with the stack of the quickfix lists
> + with the following items:
> + "cur" The current position in the quickfix stack
> + "entry0" A list with all errors of the first quickfix list.
> + See |getqflist()| for detail information on the
> + entries.
> + "entry1" A list with all errors of the second quickfix list.
> + ...
> + "entry9" A list with all errors of the last quickfix list.
> + "title0" |w:quickfix_title| of the first quickfix list.
> + "title1" |w:quickfix_title| of the second quickfix list.
> + ...
> + "title9" |w:quickfix_title| of the last quickfix list.

Wouldn't it be better to have the entries and the titles in a list?

If getqfstack() is to be used to restore, how does one do that restore?


--
DEAD PERSON: I'm getting better!
CUSTOMER: No, you're not -- you'll be stone dead in a moment.
MORTICIAN: Oh, I can't take him like that -- it's against regulations.
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@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 ///

[Christian Brabandt]

Hi Bram!

On So, 12 Mai 2013, Bram Moolenaar wrote:

> Wouldn't it be better to have the entries and the titles in a list?

We could do this as well. I don't mind.

> If getqfstack() is to be used to restore, how does one do that restore?

The idea is to do something like
" get location list stack
: let stack = getlocstack(0)
" jump to first location list
:lolder 10
" repopulate location lists
:for id in range(10)
exe printf("call setqflist(a.entry%d, '', a.title%d)", id,id)
endfor


Mit freundlichen Gr��en
Christian

[Bram Moolenaar]

Hmm, that's doable, but not simple. What if the returned structure
changes? It's probably better to add setlocstac().

--
We do not stumble over mountains, but over molehills.
Confucius

[Christian Brabandt]

Hi Bram!

On So, 12 Mai 2013, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
> > On So, 12 Mai 2013, Bram Moolenaar wrote:
> >
> > > Wouldn't it be better to have the entries and the titles in a list?
> >
> > We could do this as well. I don't mind.
> >
> > > If getqfstack() is to be used to restore, how does one do that restore?
> >
> > The idea is to do something like
> > " get location list stack
> > : let stack = getlocstack(0)
> > " jump to first location list
> > :lolder 10
> > " repopulate location lists
> > :for id in range(10)
> > exe printf("call setqflist(a.entry%d, '', a.title%d)", id,id)
> > endfor
>
> Hmm, that's doable, but not simple. What if the returned structure
> changes? It's probably better to add setlocstac().

Here is an updated patch, containing setlocstack()/setqfstack() function
and which also includes the title list suggestion. For some reason, the
stack returned by getqfstack()/getlocstack() looks a little bit weird:

Here an example for an empty stack:
{'entry6': [{}], 'entry7': [{}], 'entry8': [{}], 'entry9': [{}],
'title': ['', '', '', '', '', '', '', '', '', ''], 'cur': 0, 'entry0':
[{}], 'entry1': [{}], 'entry2': [{}], 'entry3': [{}], 'entry4': [{}],
'entry5': [{}]}

(Note, that there are entry6, entry7, entry8, entry9, then comes the
title list and current item and finally there are the remaining entry0
till entry5 items).

I am not sure, what causes this. But other then that, it seems to work.

regards,
Christian
--
Gute Vors�tze sind vorsorgliche Bu��bungen.
-- Helmar Nahr

[ZyX]

> :for id in range(10)
> exe printf("call setqflist(a.entry%d, '', a.title%d)", id,id)
> endfor

Even in this example lists would be more appropriate in place of `entry%d` keys.

[Christian Brabandt]

On Di, 14 Mai 2013, Christian Brabandt wrote:

> > Hmm, that's doable, but not simple. What if the returned structure
> > changes? It's probably better to add setlocstac().
>
> Here is an updated patch, containing setlocstack()/setqfstack() function
> and which also includes the title list suggestion. For some reason, the
> stack returned by getqfstack()/getlocstack() looks a little bit weird:
>
> Here an example for an empty stack:
> {'entry6': [{}], 'entry7': [{}], 'entry8': [{}], 'entry9': [{}],
> 'title': ['', '', '', '', '', '', '', '', '', ''], 'cur': 0, 'entry0':
> [{}], 'entry1': [{}], 'entry2': [{}], 'entry3': [{}], 'entry4': [{}],
> 'entry5': [{}]}
>
> (Note, that there are entry6, entry7, entry8, entry9, then comes the
> title list and current item and finally there are the remaining entry0
> till entry5 items).
>
> I am not sure, what causes this. But other then that, it seems to work.

Grrml, wrong patch attached. Here is the correct one.


regards,
Christian
--
Computer sind nicht intelligent. Sie glauben das nur.

[LCD 47]

On 14 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
> Here is an updated patch, containing setlocstack()/setqfstack() function
> and which also includes the title list suggestion. For some reason, the
> stack returned by getqfstack()/getlocstack() looks a little bit weird:
>
> Here an example for an empty stack:
> {'entry6': [{}], 'entry7': [{}], 'entry8': [{}], 'entry9': [{}],
> 'title': ['', '', '', '', '', '', '', '', '', ''], 'cur': 0, 'entry0':
> [{}], 'entry1': [{}], 'entry2': [{}], 'entry3': [{}], 'entry4': [{}],
> 'entry5': [{}]}
>
> (Note, that there are entry6, entry7, entry8, entry9, then comes the
> title list and current item and finally there are the remaining entry0
> till entry5 items).
>
> I am not sure, what causes this. But other then that, it seems to work.

[...]

I'm the guy who (inadvertently) started this, related to a bug in
the syntastic plugin. If you're curious about the initial discussion:
https://github.com/scrooloose/syntastic/issues/637

Here is my take on the matter:

(1) getqfstack() / getlocstack() should simply return a list of
loclists;
(2) there should be a separate function for getting (and perhaps another
one for setting) the stack pointer in these lists, namely a number
in range 0 .. len(list)-1;
(3) "title" should be an attribute of the individual loclists;
(4) there should be separate functions for getting and setting the title
for a given loclist;
(5) I'm not sure setqfstack() / setlocstack() would be all that useful;
instead, I'd rather see lifted (or perhaps made configurable) the
limit of 10 loclists per stack.

Best regards,

/lcd

[Bram Moolenaar]

In a dictionary hashing is used, the keys are stored in semi-random
order.

I see there is still a discussion about how to use the functions.
It might help to try explain in the help what these functions are used
for. If it's not for restoring state, then the set functions might not
be needed.


--
f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng

[Christian Brabandt]

Hi LCD!

On Mi, 15 Mai 2013, LCD 47 wrote:

> (1) getqfstack() / getlocstack() should simply return a list of
> loclists;
> (2) there should be a separate function for getting (and perhaps another
> one for setting) the stack pointer in these lists, namely a number
> in range 0 .. len(list)-1;

Okay. I'll update the patch accordingly.

> (3) "title" should be an attribute of the individual loclists;

That doesn't make sense. The getqflist() returns a list of dictionary
items each one describing one error. You can theoretical add an
attribute to each error for the title or even add the title as last
element to the list, but that really is ugly.

> (4) there should be separate functions for getting and setting the title
> for a given loclist;

Okay.

> (5) I'm not sure setqfstack() / setlocstack() would be all that useful;
> instead, I'd rather see lifted (or perhaps made configurable) the
> limit of 10 loclists per stack.

Okay, scratch that. I'll post an updated patch soon.

regards,
Christian
--
Denke viel, spreche wenig, schreibe nichts!

[LCD 47]

On 15 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
> Hi LCD!
>
> On Mi, 15 Mai 2013, LCD 47 wrote:
>
> > (1) getqfstack() / getlocstack() should simply return a list of
> > loclists;
> > (2) there should be a separate function for getting (and perhaps
> > another one for setting) the stack pointer in these lists,
> > namely a number in range 0 .. len(list)-1;
>
> Okay. I'll update the patch accordingly.

Great, thank you!

> > (3) "title" should be an attribute of the individual loclists;
>
> That doesn't make sense. The getqflist() returns a list of dictionary
> items each one describing one error. You can theoretical add an
> attribute to each error for the title or even add the title as last
> element to the list, but that really is ugly.

Right, not like that. What I was thinking of was more along the
lines of what Vim does with buffers, windows, tabs, etc.: give them
symbolic (non-repeating) numbers, and manipulate them through those
numbers. This should work as long as loclists can't exist outside of a
stack. Thus:

- getlocstack() would return something like [2, 3, 7]
- 3 would be the ID of the third loclist created in the current session
- locerrors(3) would return the list of dictionary items for loclist 3
- locnr(loclist) would return the ID of loclist, say 3
- loctitle(3, 'foo') would set the title of loclist 3
- loctitle(3) would return the title of loclist 3
- locsp(2) would set the index in [2, 3, 7] of the current loclist
- locsp() would return the index in [2, 3, 7] of the current loclist.

Or, if you prefer, the equivalent getmumble() / setmumble() instead
of overloaded functions.

> > (4) there should be separate functions for getting and setting the
> > title for a given loclist;
>
> Okay.
>
> > (5) I'm not sure setqfstack() / setlocstack() would be all that
> > useful; instead, I'd rather see lifted (or perhaps made
> > configurable) the limit of 10 loclists per stack.

The point here is that knowing the location inside the stack etc. is
enough only as long as the stack doesn't become full. If there are real
chances of the stack filling up, a setlocstack() might be a better
solution.

> Okay, scratch that. I'll post an updated patch soon.

It always pays to get the design right before starting to write the
code. Perhaps give it a few days to sink in, then check that it still
makes sense...

/lcd

[Christian Brabandt]

Attached is an updated patch. It adds the following functions:

getlocstack() returns the location list stack as list
getlocstackptr() returns the current position in the location list stack
getloctitle() returns a list of titles for the location list stack
getqfstack() returns the quickfix stack as list
getqfstackptr() returns the index in the quickfix stack
getqftitle() returns a list of titles in the quickfix stack
setlocstackptr() sets the index in the location list stack
setqfstackptr() sets the index in the quickfix list
setqftitle() sets the title for the current item in the quickfix list stack
setloctitle() sets the title for the current item in the location list stack

regards,
Christian
--
Achtung nutzt sich ab wie Liebe.
-- Luc de Clapiers Vauvenargues (Reflexionen und Maximen)

[LCD 47]

On 21 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
[...]

> Attached is an updated patch. It adds the following functions:
>
> getlocstack() returns the location list stack as list
> getlocstackptr() returns the current position in the location list stack
> getloctitle() returns a list of titles for the location list stack
> getqfstack() returns the quickfix stack as list
> getqfstackptr() returns the index in the quickfix stack
> getqftitle() returns a list of titles in the quickfix stack
> setlocstackptr() sets the index in the location list stack
> setqfstackptr() sets the index in the quickfix list
> setqftitle() sets the title for the current item in the quickfix list stack
> setloctitle() sets the title for the current item in the location list stack

Thank you. What version should this be applied to? Applying the
patch to 7.3.1000 produces at least two reject chunks that are not
obvious to solve.

/lcd

[Christian Brabandt]

Hi LCD!

That was made against I think 7.3.95X I think. I see if I can get an
updated patch (I lost track on the many new patches and are just trying
to catch up).

regards,
Christian
--
Fur mich gibt es nur "entweder-oder". Also entweder voll oder ganz!
-- Toni Polster

[Christian Brabandt]

Hi vim-dev!

Ah I think I found the problem. You need to apply the other patch for
setting the quickfix title first.

regards,
Christian
--
Fliegt der Bauer in den Sumpf, ist bei den Fischen Frohsinn Trumpf.

[LCD 47]

I see. Can you please post that as a single patch, against a
well-defined version of Vim? There are several versions floating around
by now, and figguring out which pieces are still current and which are
obsolete is, well, too complex a task for my tiny brain. :)

/lcd

[Christian Brabandt]

On Mi, 22 Mai 2013, LCD 47 wrote:

> I see. Can you please post that as a single patch, against a
> well-defined version of Vim? There are several versions floating around
> by now, and figguring out which pieces are still current and which are
> obsolete is, well, too complex a task for my tiny brain. :)

try this patch.

regards,
Christian
--
Dies ist die Probe, wie hoch man einen andern Menschen stelle und
liebe, inwieweit man von ihm in R�cksicht der Gl�cksg�ter abh�ngig
sein will. Nur dies Gef�hl entscheidet �ber die Ansicht fremden
Gehalts.
-- Jean Paul

[LCD 47]

On 21 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
>

> On Mi, 22 Mai 2013, LCD 47 wrote:
>
> > I see. Can you please post that as a single patch, against a
> > well-defined version of Vim? There are several versions floating around
> > by now, and figguring out which pieces are still current and which are
> > obsolete is, well, too complex a task for my tiny brain. :)
>
> try this patch.

Excellent, thank you! I'll play with it for a while, then post my
conclusions.

/lcd

[LCD 47]

On 21 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
[...]

> getlocstack() returns the location list stack as list
> getlocstackptr() returns the current position in the location list stack
> getloctitle() returns a list of titles for the location list stack
> getqfstack() returns the quickfix stack as list
> getqfstackptr() returns the index in the quickfix stack
> getqftitle() returns a list of titles in the quickfix stack
> setlocstackptr() sets the index in the location list stack
> setqfstackptr() sets the index in the quickfix list
> setqftitle() sets the title for the current item in the quickfix list stack
> setloctitle() sets the title for the current item in the location list stack

[...]

On 22 May 2013, LCD 47 <lcd...@gmail.com> wrote:
[...]

> Excellent, thank you! I'll play with it for a while, then post my
> conclusions.

There seems to be a bug in getlocstack(), it misses the first entry.
Example: after a single run of syntastic check:

:echo len(getlocstack(0))
3

:echo len(getloctitle(0))
4

Here getloctitle() seems to work correctly. Also getlocstackptr()
should probably return -1 rather than 0 if the stack is empty (calling
getlocstack() to find out is expensive in terms of memory).

I haven't looked at setlocstack() and getqf*() / setqf*().

There are a few mistakes and omissions in the manual:

(1) getlocstackptr() and getloctitle() take an argument, while
getqfstack() doesn't;
(2) the arguments for the new functions are not described;
(3) it's not clear if the stack pointers are 0- or 1-based.

From the point of view of design, I still claim it would have been
cleaner to assign handle IDs to loclists, the same way it's done for
buffers, windows, tabs, and basically everything else. It would have
allowed to solve the last piece of the puzzle, namely converting between
the current window, the associated loclist, and the associated loclist
window: these might all have been attributes of the loclists.

Without handle IDs, you basically have to use the stack to point
functions to the relevant loclist. This works, but it's a rather ugly
hack, and it doesn't extend easily to finding, say, the loclist window
associated to the current window.

/lcd

[Christian Brabandt]

Hi LCD!

On Mi, 22 Mai 2013, LCD 47 wrote:
> On 22 May 2013, LCD 47 <lcd...@gmail.com> wrote:
> [...]
> > Excellent, thank you! I'll play with it for a while, then post my
> > conclusions.
>
> There seems to be a bug in getlocstack(), it misses the first entry.
> Example: after a single run of syntastic check:
>
> :echo len(getlocstack(0))
> 3
>
> :echo len(getloctitle(0))
> 4
> Here getloctitle() seems to work correctly.

I don't see this. How did you make this? (I only checked by calling
:setloclist(0, [...]) several times and not sure how to make syntastic
do this.

> Also getlocstackptr() should probably return -1 rather than 0 if the
> stack is empty (calling getlocstack() to find out is expensive in
> terms of memory).

Ok. Updated the patch.

> I haven't looked at setlocstack() and getqf*() / setqf*().
>
> There are a few mistakes and omissions in the manual:
>
> (1) getlocstackptr() and getloctitle() take an argument, while
> getqfstack() doesn't;
> (2) the arguments for the new functions are not described;
> (3) it's not clear if the stack pointers are 0- or 1-based.

Ok, seems I mixed up the documentation yesterday. I have updated it now.

>
> From the point of view of design, I still claim it would have been
> cleaner to assign handle IDs to loclists, the same way it's done for
> buffers, windows, tabs, and basically everything else. It would have
> allowed to solve the last piece of the puzzle, namely converting between
> the current window, the associated loclist, and the associated loclist
> window: these might all have been attributes of the loclists.
>
> Without handle IDs, you basically have to use the stack to point
> functions to the relevant loclist. This works, but it's a rather ugly
> hack, and it doesn't extend easily to finding, say, the loclist window
> associated to the current window.

I have still no idea how to approach this yet.

regards,
Christian
--

[LCD 47]

On 22 May 2013, Christian Brabandt <cbl...@256bit.org> wrote:
> Hi LCD!
>
> On Mi, 22 Mai 2013, LCD 47 wrote:
> > On 22 May 2013, LCD 47 <lcd...@gmail.com> wrote:
> > [...]

> > > Excellent, thank you! I'll play with it for a while, then
> > > post my conclusions.
> >
> > There seems to be a bug in getlocstack(), it misses the first
> > entry. Example: after a single run of syntastic check:
> >

> > :echo len(getlocstack(0))
> > 3
> >
> > :echo len(getloctitle(0))
> > 4
> > Here getloctitle() seems to work correctly.
>
> I don't see this. How did you make this? (I only checked by calling
> :setloclist(0, [...]) several times and not sure how to make syntastic
> do this.

Hmm, this is interesting. I can reproduce the problem if I run
syntastic check (getlocstack() is missing the first entry), but not if I
start from scratch and I create a few loclists with lvimgrep
(getlocstack() is working fine in that case). The difference is that
syntastic runs lmake, then calls setloclist() a number of times.

> > Also getlocstackptr() should probably return -1 rather than 0 if the
> > stack is empty (calling getlocstack() to find out is expensive in
> > terms of memory).
>
> Ok. Updated the patch.

[...]

Excellent, thank you!

/lcd