On 27 July 2016, Yegappan Lakshmanan <[email protected]> wrote:
> Hi,
>
> On Tue, Jul 26, 2016 at 10:15 PM, LCD 47 <[email protected]> wrote:
> > On 26 July 2016, Bram Moolenaar <[email protected]> wrote:
> >>
> >> Lcd wrote:
> >>
> >> > On 25 July 2016, Yegappan Lakshmanan <[email protected]> wrote:
> >> > > Hi,
> >> > >
> >> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47 <[email protected]> wrote:
> >> > > > On 24 July 2016, Yegappan Lakshmanan <[email protected]>
> >> > > > 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?
> >> > > >
> >> > >
> >> > > 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})
> >> >
> >> > 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).
> >>
> >> 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.
> >
> > 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?
> >
>
> 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.
/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 [email protected].
For more options, visit https://groups.google.com/d/optout.
