> Le 29 juin 2020 à 10:29, Rowan Tommins <rowan.coll...@gmail.com> a écrit : > > > 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.
At this point, I don’t feel strongly, because currently, when I see “unexpected '''' (T_CONSTANT_ENCAPSED_STRING)”, my automatism is not looking for a string with specific quote style (which is not evident by looking at four consecutive quotes), but for a missing or misplaced punctuation mark, because, by experience, it is most of the time the root cause of an error message containing that specific token name. Another way to give the programmer the appropriate information, is replacing “quoted string” with “single-quoted string” and “double-quoted string”. And while I am thinking about it: a case that tends to cause divergent squint is: unexpected '"', which you changed into: unexpected token """. In that specific case, it would be nice if it the common name of the offending token was spelt out, something like: unexpected double quotation mark. —Claude
