[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Samuel Thibault]

Nicolas Pitre, le mer. 15 avril 2026 14:42:56 -0400, a ecrit:
> On Wed, 15 Apr 2026, Samuel Thibault wrote:
> > Nicolas Pitre, le mer. 15 avril 2026 11:22:34 -0400, a ecrit:
> > > On Wed, 15 Apr 2026, Aura Kelloniemi wrote:
> > > > On 2026-04-15 at 01:47 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> > > >  > Nicolas Pitre, le jeu. 09 avril 2026 23:12:06 -0400, a ecrit:
> > > >  > > Done — the protocol now handles grapheme clusters with a three-layer 
> > > >  > > approach (single codepoint, continuation cells, overflow area) and the 
> > > >  > > cell width field covers the whole cluster. See the updated design 
> > > >  > > document attached.
> > > > 
> > > >  > I'm a bit afraid of the complexity of the dynamic allocation of the
> > > >  > overflow entry. I agree that adding a limitation to 8 combining
> > > >  > codepoints brings static limitation, but conversely there have been
> > > >  > vulnerabilities found due to unbound combining codepoints management,
> > > >  > and for easier adoption, the protocol should be quite simple.
> > > > 
> > > > IMHO, if there is a static limitation, it should be futureproof – i.e. insely
> > > > big – like 16 or 32. But of course bumping the protocol version sometimes
> > > > should be acceptable.
> > > 
> > > There are no static limitations,
> > 
> > But I'm saying that it'd be simpler for the code to introduce a
> > limitation so that we can use non-dynamic arrays etc.
> 
> Simpler doesn't mean better.

Yes, but it means more widely adopted.

Samuel