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.
> The return value is inconsistent: getqflist("text": []) returns {}
> rather than {"items": []}, which is indistinguishable from an error.
>
> The fact that unknown keys in the input dictionary are silently
> ignored means among other things that there is no way to test for the
> new feature. Compare to:
>
> if exists("*getexpr")
> let qflist = getexpr(['some input'])
> else
> " do it the old way
> endif
>
> or
>
> try
> let qflist = getexpr(['some input'])
> catch /\m^Vim\%((\a\+)\)\=:E117/
> " do it the old way
> endif
You can come up with a call that would return a known result, if it
instead returns an empty list you know it doesn't work. You won't have
another way to get the functionality, thus you would probably throw an
error then.
> 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?
> Seriously: did anybody actually stop to think for 5 minutes about
> the user interface of this function?
The patch has been open for comments for quite a while.
--
It is hard to understand how a cemetery raised its burial
cost and blamed it on the cost of living.
/// 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.
