Re: document new features of parse.error

[Akim Demaille]

Adrian,

> Le 29 janv. 2020 à 11:01, Adrian Vogelsgesang <address@hidden> a écrit :
> 
> Hi Akim
> 
>> When a true alternative is offered, then we might deprecate verbose.
> makes sense. For now, we could at least put some note in the documentation 
> that recommends using
> “detailed” instead of “verbose” for new projects. If I would be a new-comer 
> looking into the bison
> docs for the first time, I would probably be confused if I should choose 
> detailed or verbose.

That's why I wrote

> @item @code{detailed}
> Error messages report the unexpected token, and possibly the expected ones.
> However, this report can often be incorrect when LAC is not enabled
> (@pxref{LAC}).  Token name internationalization is supported.
> 
> @item @code{verbose}
> Similar (but inferior) to @code{detailed}.
> 
> Error messages report the unexpected token, and possibly the expected ones.
> However, this report can often be incorrect when LAC is not enabled
> (@pxref{LAC}).
> 
> Does not support token internationalization.  Using non-ASCII characters in
> token aliases is not portable.

I don't want to come too hard too fast on verbose just yet.  As a matter of
fact today I had my first PR in PHP, and it was about moving from
YYERROR_VERBOSE to 'parse.error verbose' :)


>> I have proposed […] to generate a CSV file with facts about the tokens […], 
>> but received no answer
> As I have no experience with auto-generated scanners, I can’t provide you any 
> good feedback on this
> idea, though. In general the CSV file sounds reasonable to me, too (although 
> escaping in CSV can be a
> huge time sink. There are a lot of quirks re escaping in various 
> implementations such as Python
> libraries, Excel, OpenOffice, … Not sure how bad it is on the “emitting CSV 
> side”, I only know the parsing
> side of CSV)

I'm not too afraid about this.  But anyway, so far there's no demand.


>> Do you plan to port these features to lalr1.cc?<http://lalr1.cc?>
> Yes, I do.

Great!

> However, I currently don’t have time for it, and depending on your timeline 
> and how critical
> the C++ implementation is for you, it might be faster if you do it yourself.
> I would probably need a few weeks before I can look into it

I'll see how I progress in the other skeletons.  Thanks!