Re: quickfix information

[Yegappan Lakshmanan]

Hi,

On Mon, Apr 13, 2015 at 5:04 AM, <herm...@free.fr> wrote:
> Hello,
>
> I did not expect that many reactions. This is nice.
> Thank you all for your interest in the matter.
>
>> > Ah, but as long as you are OK with that information showing up in
>> > the title, if you can set w:quickfix_title to an arbitrary string,
>> > then you *can* store arbitrary data associated with a given
>> > quickfix list.
>>
>> Being able to save "ancillary" data in quickfix lists / loclists
>> as the OP suggests would be quite useful too. Then w:quickfix_title
>> could be saved there, and that would be easier to implement than
>> keeping track of updates to w:quickfix_title.
>
> Indeed, having "ancillary" data would be much more easier to use. Storing
> several variables in the w:quickfix_title wouldn't very practical. Actually,
> I want to export several buffer-local variables to the quickfix buffer. I use
> some of them to conceal part of the generated error messages, other like
> &l:tags are required to be able to jump on definition/declaration from
> identifiers found in the error messages, &l:makeprg will be needed in order
> to have :make compile the same thing, others variables (like project and
> compilation mode) will be displayed in the status(air)line, etc.
>
> Moreover, I've experienced some odd behaviours regarding the w:quickfix_title
> -- as it's automatically set to things like "setqflist()".
>
> [I can't really comment on the other internal ways of handling quickfix data]
>
> Thus, I take notice so far that there is no neat way to store variables along
> with a quickfix list. An optional data field would do the trick. I guess it
> would be more expensive than what I need, but it would do the trick.
>
> Thank you all anyway.
>
> I'll try to override the meaning of "nr" field for my needs.
>

I am attaching a patch to add the following functions to store and retrieve
a context from a location/quickfix list:

setqflistctx()
getqflistctx()
setloclistctx()
getloclistctx()

The context can be any Vim variable type.

The patch also adds the following functions to set/get the title string:

setqflisttitle()
getqflisttitle()
setloclisttitle()
getloclisttitle()

Let me know if you have any comments/suggestions on these functions.

I will add the tests for these functions later.

- Yegappan

[Yegappan Lakshmanan]

Hi,

The documentation for these new functions is below:

setqflistctx({val})
Sets the quickfix list context to {val}. {val} can be any Vim
variable type (Number, String, List, Dict, etc.). Returns 0 on
success and -1 on error.

getqflistctx()
Returns the quickfix list context. The quickfix list context is
set using |setqflistctx()|. Returns 0 if the context is not
set.

setloclistctx({nr}, {val})
Sets the location list context for window {nr} to {val}. {val}
can be any Vim variable type (Number, String, List, Dict, etc.)
Returns 0 on success and -1 if the window {nr} is not present.
If the location list is not present for window {nr}, then it
will be created.

getloclistctx({nr})
Returns the location list context for window {nr}. For the use
of {nr}, see |getloclist()| above. The location list context is
set using |setloclistctx()|. Returns 0 if the context is not
set or the location list is not present.

setqflisttitle({string})
Sets the quickfix list title to {string}. By default, the title
is set to the command that created the quickfix list. Returns 0
on success and -1 on error.

getqflisttitle()
Returns the quickfix list title string. The quickfix list title
is set using |setqflisttitle()|. Returns an empty string if the
title is not set.

setloclisttitle({nr}, {string})
Sets the location list title for window {nr} to {string}. By
default, the title is set to the command that created the
location list. Returns 0 on success and -1 if the window {nr}
is not present. If the location list is not present for window
{nr}, then it will be created.

getloclisttitle({nr})
Returns the location list title string for window {nr}. For
the use of {nr}, see |getloclist()| above. The location list
title is set using |setloclisttitle()|. Returns an empty string
if the title is not set or the location list is not present.

- Yegappan

[LCD 47]

Since you ask: in my opinion this is designed from the perspective
of a Vim's patcher, not from that of a Vim's user. The "ancillary" data
should be a special field in the location/quickfix list, and it should
be accessible as such, not through special getters and setters.

Having to access the data through getters and setters reminds me
of code for embedded appliances, where in order to set a variable to a
16-bits integer you need to write the first 12 bits in machine order
to port 25, and the last 3 bits in big endian order to port 31. It
works, sort of, but it's a pain for the user, and it makes Java code
look concise.

> I will add the tests for these functions later.

/lcd

[Yegappan Lakshmanan]

Hi,

The 'ancillary' data is a special field in the internal location/quickfix
list.

Are you looking for setting the context using the setqflist() and
setloclist() functions? These functions can be extended to take
the context.

But it will be difficult to extend the getqflist() function to return the
context though. The getqflist() function currently returns a list.
I am not sure how to extend this function to return the entries and
context without breaking backward compatibility.

- Yegappan

[LCD 47]

I believe this has been discussed in some detail in the past.
There are two kinds of ancillary data that would be useful, a per-item
extra field, and a per-list variable (what you call "context").

In my experience the per-item version would be far more useful than
the per-list one, but it would be tricky to implement since it would
turn a list (the location/quickfix list) into a sort of mixture between
a list and a dictionary (per-item data would need reference counts and
so on).

On the other hand, the per-list variable could actually cover both
cases, since it can be a list itself. However, the interface would be
a pain for the user, since it would be the user's job to correlate the
data with the error items.

Per-item data can be implemented without changinging the interface.
Per-list data can be implemented with either getters and setters, or
with an extra parameter to getqflist() / getloclist() and setloclist()
/ setqflist() (or both). I'm not convinced getters and setters is the
better choice.

/lcd

[Bram Moolenaar]

The number of commands and functions for quickfix functionality keeps
growing. It would be good to reduce this a bit.

getqflist() currently does not take an argument. It could use an
argument to specify what to get, instead of the whole list.
So how about passing a dictionary? One of the items could be to get the
aux data instead of the list of errors.

For setqflist() it's a bit more tricky, since it already has a second
"action" argument. But we can add the dictionary as the third argument.

Perhaps getting and setting the quickfix title would also fit in here?
And it allows for the filtering that we had a patch for?
Would be good to get an overview before making more changes.

--
GUARD #2: Wait a minute -- supposing two swallows carried it together?
GUARD #1: No, they'd have to have it on a line.
GUARD #2: Well, simple! They'd just use a standard creeper!
GUARD #1: What, held under the dorsal guiding feathers?
GUARD #2: Well, why not?
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 ///

[Yegappan Lakshmanan]

Hi Bram,

On Mon, Jul 18, 2016 at 2:11 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

>
> Yegappan Lakshmanan wrote:
>
>> >>
>> >> I am attaching a patch to add the following functions to store and
>> >> retrieve a context from a location/quickfix list:
>> >>

>> >> Let me know if you have any comments/suggestions on these functions.
>> >
>> > Since you ask: in my opinion this is designed from the perspective
>> > of a Vim's patcher, not from that of a Vim's user. The "ancillary" data
>> > should be a special field in the location/quickfix list, and it should
>> > be accessible as such, not through special getters and setters.
>> >
>>
>> The 'ancillary' data is a special field in the internal location/quickfix
>> list.
>>
>> Are you looking for setting the context using the setqflist() and
>> setloclist() functions? These functions can be extended to take
>> the context.
>>
>> But it will be difficult to extend the getqflist() function to return the
>> context though. The getqflist() function currently returns a list.
>> I am not sure how to extend this function to return the entries and
>> context without breaking backward compatibility.
>
> The number of commands and functions for quickfix functionality keeps
> growing. It would be good to reduce this a bit.
>
> getqflist() currently does not take an argument. It could use an
> argument to specify what to get, instead of the whole list.
> So how about passing a dictionary? One of the items could be to get the
> aux data instead of the list of errors.
>

What about adding a optional 'detail' flag to getqflist()? When this flag
is specified, it returns a dictionary with the following items:

1. title - Quickfix title
2. nr - Quickfix list number (in the quickfix stack)
3. items - List of quickfix entries
4. context - Context information set by setqflist()

Another alternative is to pass a dictionary (as you suggested) with the
following items:

1. title:1
2. context:1
3. items:1
4. nr:1
5. all:1

>
> For setqflist() it's a bit more tricky, since it already has a second
> "action" argument. But we can add the dictionary as the third argument.
>

Yes. The dictionary can contain the following items:

1. title - Quickfix title
2. context - Context information (can be any Vim variable type)

>
> Perhaps getting and setting the quickfix title would also fit in here?
>
> And it allows for the filtering that we had a patch for?
>

As we have ex commands for creating and managing the quickfix entries,
I think the filtering functionality should have an ex command instead
of a function.

- Yegappan

[Yegappan Lakshmanan]

Hi,

Any preference between the two approaches for adding an additional
argument to getqflist()?

- Yegappan

[Yegappan Lakshmanan]

Hi,

On Mon, Jul 18, 2016 at 2:11 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>

> The number of commands and functions for quickfix functionality keeps
> growing. It would be good to reduce this a bit.
>
> getqflist() currently does not take an argument. It could use an
> argument to specify what to get, instead of the whole list.
> So how about passing a dictionary? One of the items could be to get the
> aux data instead of the list of errors.
>
> For setqflist() it's a bit more tricky, since it already has a second
> "action" argument. But we can add the dictionary as the third argument.
>
> Perhaps getting and setting the quickfix title would also fit in here?
> And it allows for the filtering that we had a patch for?
> Would be good to get an overview before making more changes.
>

I am attaching a patch to enhance the getqflist/getloclist() functions to
return the title string and the setqflist()/setloclist() functions to set
the title string.

After this patch is incorporated, it will be easy to add the additional
items (e.g. context, items, number, stack, etc.).

The getqflist/setqflist functions now accept an optional dictionary
parameter. The dictionary parameter specifies which items to get or set.
If the {dict} argument is specified, then the getqflist function returns a
dictionary.

- Yegappan

[LCD 47]

On 24 July 2016, Yegappan Lakshmanan <yega...@gmail.com> wrote:
> I am attaching a patch to enhance the getqflist/getloclist() functions
> to return the title string and the setqflist()/setloclist() functions
> to set the title string.
>
> After this patch is incorporated, it will be easy to add the
> additional items (e.g. context, items, number, stack, etc.).
>
> The getqflist/setqflist functions now accept an optional dictionary
> parameter. The dictionary parameter specifies which items to get or
> set. If the {dict} argument is specified, then the getqflist function
> returns a dictionary.

Why a dictionary (where values are ignored), rather than a list, or
a string of, say, comma-separated names? Or both?

/lcd

[Yegappan Lakshmanan]

Hi,

This is to be consistent between the getqflist()/getloclist() and the
setqflist()/setloclist() functions. In the setqflist() function, the value of
a dictionary key specifies the value to set. In the getqflist() function,
it specifies the value to return. For example, the following call sets
the quickfix title:

call setqflist([], 'a', {'title' : 'example'})

The following call returns the quickfix title:

call getqflist({'title' : 1})

- Yegappan

[LCD 47]

The arguments of setqflist() are already different from those of
getqflist(), so why does an extra argument has to be the same? Why not
something like this:

call getqflist('title,context,nr')
or
call getqflist(['title', 'context', 'nr'])

vs.

call setqflist(errors, 'r',
\ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })

(BTW, { 'nr': -1 } could mean last).

/lcd

[Bram Moolenaar]

Although we can probably do a lot with a list of strings, there is a
tendency for builtin-functions to use a dictionary to pass optional
extra argumens through a dict. A list can only use "present" flags, a
dictionary can also use values for the arguments.

Usually the argument dicts are short: {'title': 1}.
If they do get long and all the values are one, you could use a list and
turn it into a dict. Hmm, we don't have a function for that...

--
ARTHUR: What does it say?
BROTHER MAYNARD: It reads ... "Here may be found the last words of Joseph of
Aramathea." "He who is valorous and pure of heart may find
the Holy Grail in the aaaaarrrrrrggghhh..."
ARTHUR: What?
BROTHER MAYNARD: "The Aaaaarrrrrrggghhh..."
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Bram Moolenaar]

I think this generally is a good way to do it.

In the implementation, splitting f_getqflist() into two functions that
look quite similar doesn't seem like a good idea.


--
User: I'm having problems with my text editor.
Help desk: Which editor are you using?
User: I don't know, but it's version VI (pronounced: 6).
Help desk: Oh, then you should upgrade to version VIM (pronounced: 994).

[LCD 47]

So basically you want all plugins daring enough to use the new
features to carry along dicts with useless values, just because some
of these values might become useful at some unspecified point in the
future? Vim can nicely deal with changing the type of an argument, so
why not use lists for now, and add dict arguments when and if there is
an actual use for those?

> Usually the argument dicts are short: {'title': 1}. If they do get
> long and all the values are one, you could use a list and turn it into
> a dict. Hmm, we don't have a function for that...

/lcd

[Yegappan Lakshmanan]

Hi,

I did make the changes to use a list argument for the getqflist() function.
Then realized that with a list, you cannot specify the quickfix list number
(to pick a specific list in the stack). With a dict, you can modify a specific
quickfix list in the stack.

- Yegappan

[LCD 47]

After pondering about this for a while, I believe the stack pointer
is the only one that needs a value in both getqflist() and setqflist(),
so you could in principle encode it as simply a number. That is, a
number in the list would refer to the stack pointer, as opposed to the
other names that would be alphabetic. But that would be even worse than
having a dict with dummy values. So yes, this is probably a good reason
for using dicts.

/lcd

[Christian Brabandt]

On Mi, 27 Jul 2016, LCD 47 wrote:

> After pondering about this for a while, I believe the stack pointer
> is the only one that needs a value in both getqflist() and setqflist(),
> so you could in principle encode it as simply a number. That is, a
> number in the list would refer to the stack pointer, as opposed to the
> other names that would be alphabetic. But that would be even worse than
> having a dict with dummy values. So yes, this is probably a good reason
> for using dicts.

Can't we use an extra optional argument for the stack pointer? If not
given, it would always use the current list.

Best,
Christian
--
Aufhören können, das ist nicht eine Schwäche, das ist eine Stärke.
Die Geschichte lehrt dauernd, aber sie findet keine Schüler.
-- Ingeborg Bachmann

[Yegappan Lakshmanan]

Hi,

An updated patch is attached. The getqflist() and setqflist() functions take
a dict argument which specifies the things to get or set.

- Yegappan

[Yegappan Lakshmanan]

Hi,

On Wed, Jul 27, 2016 at 6:42 PM, Yegappan Lakshmanan
<yega...@gmail.com> wrote:
> Hi,
>
> On Wed, Jul 27, 2016 at 7:35 AM, LCD 47 <lcd...@gmail.com> wrote:
>>> >> > >
>>> >> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47 <lcd...@gmail.com> wrote:
>>> >> > > > On 24 July 2016, Yegappan Lakshmanan <yega...@gmail.com>
>>> >> > > > wrote:
>>> >> > > >> I am attaching a patch to enhance the getqflist/getloclist()
>>> >> > > >> functions to return the title string and the
>>> >> > > >> setqflist()/setloclist() functions to set the title string.
>>> >> > > >>
>>> >> > > >> After this patch is incorporated, it will be easy to add the
>>> >> > > >> additional items (e.g. context, items, number, stack, etc.).
>>> >> > > >>
>>>

>>> I did make the changes to use a list argument for the getqflist()
>>> function. Then realized that with a list, you cannot specify the
>>> quickfix list number (to pick a specific list in the stack). With a
>>> dict, you can modify a specific quickfix list in the stack.
>>
>> After pondering about this for a while, I believe the stack pointer
>> is the only one that needs a value in both getqflist() and setqflist(),
>> so you could in principle encode it as simply a number. That is, a
>> number in the list would refer to the stack pointer, as opposed to the
>> other names that would be alphabetic. But that would be even worse than
>> having a dict with dummy values. So yes, this is probably a good reason
>> for using dicts.
>>
>
> An updated patch is attached. The getqflist() and setqflist() functions take
> a dict argument which specifies the things to get or set.
>

I am attaching an updated patch. The previous patch used quickfix list
numbers starting from zero. This patch uses the quickfix list numbers
starting from 1.

- Yegappan