Re: Better handling of wide glyphs (ask the terminal, not wcwidth)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 7,  2:09am, Daniel Hahler wrote:
}
} Where would I have to look / poke to do this for the prompt and ZLE only?

Mostly in Src/prompt.c, surprisingly enough.  There are a couple of
routines in Src/utils.c and the code in Src/Zle/complist.c has its
own variants for output with color controls.

} There it should be mostly about chars that are about to be displayed,
} and in this case the "painting in an innocuous spot" is not required at
} all (given that those chars are displayed one by one).

The problem there is that the prompt formatting code needs to be able
to calculate the width before it begins printing, so that it can stop
before printing something that won't fit.  Otherwise you run into all
sorts of auto-margin issues that are already bad enough.

And then there's the code used by e.g. zsh-syntax-highlighting which
also needs to compute widths in advance in order to populate the array
of positions where terminal attributes change.

} > a utility to generate such a configuration from the terminal
} 
} How would that work then?  Based on the method described above?

Yes, basically the way zkbd works except it wouldn't need to be
interactive.

} Then it would be a pre-generated cache basically?!

Yes.

} It might be hard to predict what glyphs are being used in the future
} though, and it is probably rather big.

Yes; if you tried to store them all it'd probably be about the size of
the terminfo database multiplied by the number of fonts.  But it could
omit any glyphs that are only 1 column wide, and you'd just need to
generate the tables for the presumably manageable combination of fonts
and terminals that a particular user is commonly using.

} It's also basically a custom wcwidth(3) implementation then, isn't it?

Yes again; but if you can supply the table of glyphs separately then
you don't need to update the linked library every time new glyphs or
fonts are introduced.  (I would not be surprised to find a standards
body working on something like this already.)