Re: UTF-8 in grout and a performance regression (was: synchronous and asynchronous grout)

[onf]

Hi Branden,

On Thu Dec 19, 2024 at 8:43 PM CET, G. Branden Robinson wrote:
> At 2024-12-19T20:23:56+0100, onf wrote:
> > Although looking up Unicode codepoint numbers is arguably better
> > than seeing gibberish, neither is a particularly good form to work
> > with. Your reasoning sounds like "making it perfect for most people
> > would make it horrible for a small minority, so let's rather keep it
> > bad for everyone".
>
> I think you're exhibiting a form of the base rate fallacy here.
>
> The number of people who read GNU troff output ("grout"), whether with
> their eyeballs or with a program they've written, is *tiny*.

If that's the case, I wonder why you're concerned about a tiny fraction
of a tiny fraction of people not being able to display those characters..?

> I think a lot of people, even when troubleshooting, fail to consider
> grout as an inspection site in the first place.  They try to reason from
> groff input to whatever is emitted by the output driver.  And that
> works, often enough.

That's true, but it can come in handy. I did examine the intermediate
output when trying to understand .ne's behavior, for example.

> I therefore consider your claim overstated.

Well, likewise I guess.

> One of the people who _does_ examine grout, though, is Deri, which is
> why I said, in a part of my message you didn't quote:
>
> >> It could be a setting in the DESC file so you don't need to change
> >> output drivers in one go.
> >
> > I'd be fine with that, for the same reason I mused about a "caveman
> > mode" where the "tcommand" DESC directive is ignored and we fall back
> > to fully synchronous 'c', 'C', and 'h' sequences.
>
> ...and which happens to also be responsive to one of your subsequent
> points:
>
> > I understand that groff cannot treat it this way on input due to
> > composing/decomposing characters etc., but I feel like it would've
> > been possible on output if groff hadn't abandoned the c & h commands,
> > no?

Yeah, I realized you responded to that only after I sent the message.

> ...where this "abandonment" would not only be configurable (as it always
> has been via "DESC" file editing), but I conceived of it as dynamically
> alterable (via troff(1) command-line option or an environment variable).
>
> > I prefer the approach of most other Unix tools which treat UTF-8
> > transparently as "data".
>
> When you elide my conciliatory remarks and points of agreement to make
> me appear argumentative, I am pressured to draw the same conclusion of
> you, and with better evidence.

It wasn't my intention to make you appear argumentative, I simply failed
to understand part of what you were trying to say. I feel like you are
ascribing unreasonable amount of animosity to me.

I just felt like the argument that emitting \[u...] is preferrable due
to some tiny number of people who don't have Unicode-compliant terminals
was fairly weak, and it would be cool if the output was more readable
than this:
  tv
  Cu0065_030C
  h5444
  tt
  Cvs
  h4313
  C'i

(that's "větší")

By the way, when you said that some terminals' fonts might be missing
the relevant glyphs... I have the opposite problem, my groff fonts
support only a fraction of what my terminal can display.

~ onf