Re: errorformat/cexpr bug?

Thanks for the reply. I find this "multiignore" flag very fishy because none of the documentation I have read would imply the existence of such a flag. (Why wouldn't "multi" and "ignore" be orthogonal notions?)

Interestingly, in trying to further reverse-engineer meaning by testing behavior, I stumbled on conclusive evidence that something here is clearly broken and not simply difficult to understand. Below you can see that the interpretation of errorformat string g:efm0 is inconsistent. For all I know, it's meaning might depend on the time of day...but more likely, it has something to do with the intervening use of other errorformat strings.


:let g:efm0 = '%+C%.%#,%EXXX:%m,%-IYYY:%m'
:let g:efm1 = '%+C%.%#,%EXXX:%m,%+IYYY:%m'
:let g:efm2 = '%+C%.%#,%EXXX:%m,%-GYYY:%m'

:let &efm = g:efm1
:cgetexpr ['YYY:one', 'XXX:two']
:echomsg string(getqflist()[0].text)

'YYY:one^@XXX:two'

:let &efm = g:efm0
:cgetexpr ['YYY:one', 'XXX:two']
:echomsg string(getqflist()[0].text)

'YYY:one^@XXX:two'

:let &efm = g:efm2
:cgetexpr ['YYY:one', 'XXX:two']
:echomsg string(getqflist()[0].text)

'two'

:let &efm = g:efm0
:cgetexpr ['YYY:one', 'XXX:two']
:echomsg string(getqflist()[0].text)

'two'


I'm afraid that the issues I'm seeing here are just the tip of an iceberg of ill-defined behavior because (a) these are not overly-contrived purely-hypothetical corner cases (they were distilled from simple real-world use cases) and (b) I don't even have any intuition any more about what I think *should* be happening.

For quite some time, I have been arguing to my coworkers that the 'efm' setting is more than an ugly hack and is the easiest way to (reliably) process error messages (especially ones that are not context-sensitive). Now it's looking like I'm going to have to eat my words.

...Aaron

On Thursday, February 20, 2014 8:06:53 AM UTC-5, LCD 47 wrote:
> On 19 February 2014, Aaron Bohannon <aaron678@gmail.com> wrote:
>
> > Over the years, I have wasted many hours of my life on trying to write
>
> > errorformat patterns -- and many times having to give up in defeat.
>
> > Now, finally, I've managed to trace down a behavior that could explain
>
> > all those hours of frustration.
>
> >
>
> > The meaning of the errorformat option is so arcane, though, that
>
> > I cannot know for sure whether this is actually a bug in the
>
> > implementation or simply the intended behavior. If it's intentional,
>
> > can someone *please* explain to me why it works like this?
>
> >
>
> > :echo string(&efm)
>
> >
>
> > '%+CXXX,%+EERROR,%+IINFO,%-GYYY'
>
> >
>
> > :cgetexpr ['INFO', 'ERROR', 'XXX']
>
> > :echomsg string(getqflist()[0].text) string(getqflist()[1].text)
>
> >
>
> > 'INFO' 'ERROR^@XXX'
>
> >
>
> > :cgetexpr ['INFO', 'YYY', 'ERROR', 'XXX']
>
> > :echomsg string(getqflist()[0].text) string(getqflist()[1].text)
>
> >
>
> > 'INFO' 'ERROR'
>
>
>
> Yeah, this one looks like a bug. What seems o be going on here is
>
> that 'YYY' matches '%-GYYY', which sets the multiignore flag, which
>
> doesn't get reset until 'XXX' is seen. Which basically means 'XXX' is
>
> matched as '%-CXXX', thus ignored.
>
>
>
> > :cgetexpr ['INFO', 'YYY', 'ZZZ', 'ERROR', 'XXX']
>
> > :echomsg string(getqflist()[0].text) string(getqflist()[1].text) string(getqflist()[2].text)
>
> >
>
> > 'INFO' 'ZZZ' 'ERROR^@XXX'
>
>
>
> In this case multiignore gets set at 'YYY', but then gets reset
>
> when 'ZZZ' is seen. Thus the subsequent 'XXX' is correctly matched as
>
> '%+CXXX'.
>
>
>
> The patch below seems to fix the problem for this particular case,
>
> but the context is pretty involved. F.i. what about O/P/Q? It would be
>
> a good idea to have more pairs of eyes look at it.
>
>
>
> /lcd
>
>
>
>
>
> diff -r 7ea91c82839f src/quickfix.c
>
> --- a/src/quickfix.c Sat Feb 15 19:47:51 2014 +0100
>
> +++ b/src/quickfix.c Thu Feb 20 14:52:05 2014 +0200
>
> @@ -751,7 +751,10 @@
>
> fmt_start = fmt_ptr;
>
>
>
> if (vim_strchr((char_u *)"AEWI", idx) != NULL)
>
> + {
>
> multiline = TRUE; /* start of a multi-line message */
>
> + multiignore = FALSE; /* reset continuation */
>
> + }
>
> else if (vim_strchr((char_u *)"CZ", idx) != NULL)
>
> { /* continuation of multi-line msg */
>
> if (qfprev == NULL)

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.