Yegappan wrote:

> On Thu, Aug 31, 2017 at 11:58 AM, Bram Moolenaar <[email protected]> wrote:
> >
> > Lcd47 wrote:
> >
> >> On 27 August 2017, Bram Moolenaar <[email protected]> wrote:
> >> >
> >> > Patch 8.0.1006
> >> > Problem:    Cannot parse text with 'erroformat' without changing a 
> >> > quickfix
> >> >             list.
> >> > Solution:   Add the "text" argument to getqflist(). (Yegappan Lakshmanan)
> >> > Files:      runtime/doc/eval.txt, src/evalfunc.c, src/proto/quickfix.pro,
> >> >             src/quickfix.c, src/testdir/test_quickfix.vim
> >>
> >>     It's awesome that this feature has been added, however the interface
> >> is confusing:
> >>
> >> [...]
> >> > +                   text    use 'errorformat' to extract items from the
> >> > +                           text and return the resulting entries. The
> >> > +                           value can be a string with one line or a list
> >> > +                           with multiple lines. The current quickfix 
> >> > list
> >> > +                           is not modified.
> >> [...]
> >> > +           When 'text' is specified, all the other items are ignored. 
> >> > The
> >> > +           returned dictionary contains the entry 'items' with the list
> >> > +           of entries.
> >> >             In case of error processing {what}, an empty dictionary is
> >> >             returned.
> >> [...]
> >>
> >>     What is the point in reusing getqflist() for this instead of writing
> >> a new function?  It makes no sense: when "text" is used the other
> >> arguments are silently ignored, and the {"items": ...} around the qflist
> >> is useless.  Why not a function getexpr(list), that returns a list?
> >
> > As Yegappan mentioned, using a separate function means a lot of the
> > arguments need to be duplicated.  It's not idea, but considering these
> > functions will be used in scripts and won't be typed it's not that
> > important.
> >
> >
> >>     Finally, there's also a confusion about "text" being a key on
> >> input, and also a key with a completely different meaning on output.
> >
> > "text" is indeed very generic.  We could always require passing a list
> > (one item would be the same as passing a string), and then the item
> > could be called "lines".  Would that work better?
> >
> 
> I am attaching a patch to change 'text' to 'lines' and to accept only
> List values.

Thanks!

-- 
Don't read everything you believe.

 /// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui