groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: input.cpp, read_size() error reporting


From: G. Branden Robinson
Subject: Re: input.cpp, read_size() error reporting
Date: Sun, 5 Apr 2020 02:44:41 +1000
User-agent: NeoMutt/20180716

Hi Ingo!

At 2020-04-04T18:21:55+0200, Ingo Schwarze wrote:
> Hi Branden,
> 
> G. Branden Robinson wrote on Thu, Apr 02, 2020 at 08:31:09AM +1100:
> 
> > These three cases have silent token discards
> > without diagnostic:
> > 
> > \sA
> > \s[+
> > \s[-
> 
> Now i'm confused.  I *think* i reproduced that issue recently,
> but now i wanted to investigate and can no longer reproduce,
> neither before nor after your message improvements (which are
> not expected to make a difference *in this respect* anyway).
[...]
> The response "missing number" is not very precise, but it no
> longer looks like a "silent token discard" to me...  :-o

I get the same results you do, both with groff 1.22.4 from Debian and
Git HEAD.

The above remark of mine was based on a misunderstanding of how the
parser works.  There's no token pushback or re-interpretation in the
enclosing context.  As you noted in a mail to which I haven't yet
replied, the latter could require significant re-engineering of the
parser.  (With a pushback method in the token class, however, it might
just amount to a bunch of one-liners.  Just speculating.)

Also, at the time I wrote that I didn't realize that "A" could be an
escape delimiter just like "'".

So, given my updated understanding of the parser, I don't think there's
anything to be alarmed about here.

> So, right now, i don't relish the pain, and i also prefer to
> polish other turds first, sorry...

That's okay.  It doesn't bother me to write them.

> > Did you notice I didn't use any bashisms in the last one?  :-P
> 
> Yes, i did, and i appreciated that.  :-)

One factor that may limit my future use of the <() <() Bashism is the
fact that it makes the output sensitive to changes in the wording of
diagnostic messages.  This element now looms larger in my awareness than
it used to.

With the proposed s39/s40 change, all I had to do was compare -Z output,
and no diagnostics were involved, so grep sufficed.  (One has to be
careful with grep, though--it can lead to false positives and
negatives.)

It's not much work to update test cases to reflect altered diagnostic
strings, but it makes the full-output comparisons feel a little more
costly than I previously regarded them.

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]