On Tue, Dec 03, 2024 at 07:47:53PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 3, 2024 at 6:16 PM Uwe Kleine-König
> <u.kleine-koenig@xxxxxxxxxxxx> wrote:
> > On Tue, Dec 03, 2024 at 03:10:30PM +0200, Andy Shevchenko wrote:
> > > On Tue, Dec 3, 2024 at 1:01 PM Uwe Kleine-König
> > > <u.kleine-koenig@xxxxxxxxxxxx> wrote:
> > > >
> > > > It can happen if a previous conversion was aborted the ADC pulls down
> > > > the ̅R̅D̅Y line but the event wasn't handled before. In that case enabling
> > >
> > > Interesting use of Unicode, but I suggest to avoid it when it can be
> > > avoided, i.e.
> > > using the notation of #RDY_N might be appropriate as that is how
> > > usually the HW people refer to the active low signals.
> >
> > Usage of ̅R̅D̅Y has the advantage to match the reference manual and data
> > sheet. So I tend to keep it.
>
> Not sure it's strictly the same. The above has two dashes on top
> (actually misaligned a bit) of two letters out of three, this is quite
> confusing (as to me to an electrical engineer) and I hardly believe
> it's the same in the datasheet (however nowadays everything is
> possible with (ab)use of Unicode).
I think this is "only" a misrepresentation on your end. Sometimes it
happens for me, too. A forced redraw helps then. I think that's a bug in
the unicode render engine. In gitk it looks completely wrong.
Syntactically it's correct however, the sequence is:
\xcc\x85R\xcc\x85D\xcc\x85Y, where "\xcc\x85" is the UTF-8
representation of the "combining overline" code point (0x305).
That makes me remember the times when having a non-ASCII char in your
name was a problem:
$ git log v6.13-rc1 | grep -P -o 'Kleine-K.*?nig' | sort | uniq -c
8 Kleine-König
1 Kleine-K=C3=B6nig
1 Kleine-K=F6nig
1 Kleine-K?nig
10 Kleine-Knig
156 Kleine-Koenig
8 Kleine-Konig
12862 Kleine-König
1 Kleine-K <u.kleine-koenig
If we don't start using these, it will never be repaired ...
Best regards
Uwe
Attachment:
signature.asc
Description: PGP signature
