> Le 22 avr. 2019 à 10:19, Hans Åberg <[email protected]> a écrit : > >> On 22 Apr 2019, at 07:29, Akim Demaille <[email protected]> wrote: >> >>> The only safe way is to replace the visible characters in the quoted string >>> with spaces, and then use an initial portion of that. Then you can count >>> characters as you like, probably tabs as 1. >> >> What do you mean by "the only safe way"? Paul's proposal a la diff -T, >> or GCC9's approach both seem to work properly. > > In case somebody mixes tabs and spaces, like four space for tabs and mixed > with spaces?
Ah, you mean when tabs are not 8 spaces. Yes, you are right, in that case, it won't work. The GNU coding standards make it clear that tabs are 8 spaces. (https://www.gnu.org/prep/standards/standards.html#index-formatting-error-messages), and so far no-one complained about the handling of tabs in Bison (except me :-). Eventually, if there are complains, and if GCC9 also makes the choice to be independent of tab width by smashing them to spaces, I'll adjust Bison. >>> Does not work with Unicode, though. In your example >>>> input.y:15.4-17: warning: empty rule without %empty [-Wempty-rule] >>>> e: {∇⃗×𝐸⃗ = -∂𝐵⃗/∂t} >>>> ^~~~~~~~~~~~~~ >>> here, the U+20D7 COMBINING RIGHT ARROW ABOVE for the nabla combines, but >>> others do not. >> >> What do you mean? I see it perfectly: arrows are combined to E and B. >> It might be something on your mail reader side? > > Right, it depends on the renderer, so if you want a different line with > matching spacing, that is not really possible. Agreed. I assume that people use a fixed width font, or disable caret diagnostics. >> For some reason, in >> Apple's terminal, both nabla and B are correctly "accented", but not >> the E. All are correct in the mailer though. > > I use Mail on MacOS 10.13. Well, then they fixed that in 10.14(.4).
