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