Re: [PATCH 04/11] vt: introduce gen_ucs_width.py to create ucs_width.c

[Nicolas Pitre]

On Mon, 14 Apr 2025, Jiri Slaby wrote:

> On 10. 04. 25, 3:13, Nicolas Pitre wrote:
> > From: Nicolas Pitre <npitre@xxxxxxxxxxxx>
> > 
> > The table in the current ucs_width.c is terribly out of date and
> > incomplete. We also need a second table to store zero-width code points.
> > Properly maintaining those tables manually is impossible. So here's a
> > script to automatically generate them.
> > 
> > Signed-off-by: Nicolas Pitre <npitre@xxxxxxxxxxxx>
> > ---
> >   drivers/tty/vt/gen_ucs_width.py | 264 ++++++++++++++++++++++++++++++++
> >   1 file changed, 264 insertions(+)
> >   create mode 100755 drivers/tty/vt/gen_ucs_width.py
> > 
> > diff --git a/drivers/tty/vt/gen_ucs_width.py
> > b/drivers/tty/vt/gen_ucs_width.py
> > new file mode 100755
> > index 0000000000..41997fe001
> > --- /dev/null
> > +++ b/drivers/tty/vt/gen_ucs_width.py
[...]
> > +    # Mark these emoji modifiers as zero-width
> > +    for start, end in emoji_zero_width:
> > +        for cp in range(start, end + 1):
> > +            try:
> > +                width_map[cp] = 0
> > +            except (ValueError, OverflowError):
> 
> When can this happen and why is it not fatal?

This is some bogus leftovers. That doesn't fail.

Those scripts have been significantly cleaned up.

> > +    with open(c_file, 'w') as f:
> > +        f.write(f"""\
> 
> Why this backslash?

To inhibit the implied \n otherwise the file would start with an empty 
line. Same reason elsewhere: to prevent spurious empty lines.

> I wonder, if you could generate only zero_width_ranges[] to some generated.c
> and "maintain" the C functions in the kernel the standard way -- including
> that generated.c. I.e. not having C functions in a py script.

Yes, I did that. Easier to maintain in the end.


Nicolas