bison-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 0/4] Fix caret errors


From: Hans Åberg
Subject: Re: [PATCH 0/4] Fix caret errors
Date: Mon, 22 Apr 2019 17:59:43 +0200

> On 22 Apr 2019, at 15:57, Akim Demaille <address@hidden> wrote:
> 
>> Le 22 avr. 2019 à 10:19, Hans Åberg <address@hidden> a écrit :
>> 
>>> On 22 Apr 2019, at 07:29, Akim Demaille <address@hidden> 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),

Yes, but otherwise there is no such conversion rule in Unicode (or ASCII). As 
you said, best is to avoid tabs altogether, does not work with makefiles, 
though.

>  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.

Probably not a big deal, as the error messages are generally readable anyway.

>>>> 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.

There is no such font yet for Unicode, though they mentioned a project for that 
on the ConTeXt list.

Also, no single font can cover all of Unicode, since the former is limited to 
65536 characters, and Unicode has more. It gets more complicated when combining 
fonts for different ranges, because the font metrics can be of a variable width 
font even though the characters are monospace, and then columns using spaces do 
no work.

>>> 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).

They probably just call some API, same for Mail and Safari, maybe Terminal as 
well.





reply via email to

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