Hi Claude, On Mon, 29 Jun 2020 at 07:27, Claude Pache <claude.pa...@gmail.com> wrote:
> > > > As a special-case, quoted strings show the string's *content* in double > quotes, e.g. 'unexpected quoted string "foo" ...' rather than 'unexpected > quoted string ""foo"" ...' or 'unexpected quoted string "'foo'" ...'. > > For me, in this case, you have dropped the wrong pair of quotes. That is, > I prefer to see the quotes used in the source text (“unexpected string > 'foo' ...” or “unexpected string "foo" ...”), over the quotes that make > error messages consistent with other error messages. This is because I like > to have hints that help me to visually identify the offending string in the > source text when it is of length 0 or 1, but on other hand I don’t care > about consistency across error messages. > I did actually have strings matching the quote marks used in an earlier version of the patch, but dropped it partly to simplify the implementation - because it sometimes truncates strings, it can't just use the real quotes, but has to strip and re-add them. The consistency should aid anyone trying to parse the error message, since the pattern /unexpected ([^"]+) "(.*?)"/ will always give you a token name (even if just 'token') and its content. I can re-visit that part if you feel strongly, though. Regards, -- Rowan Tommins [IMSoP]
