bug#44664: 28.0.50; troubles with some chars in term

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: schwab@linux-m68k.org,  bugs@gnu.support,  44664@debbugs.gnu.org
> Date: Thu, 26 Nov 2020 10:50:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe.  We can do that as well, btw.  We already do something like
> > that with fonts that declare too large height for its character
> > glyphs: we override that with a reasonable value.  We could do
> > something similar for the width, conditioned on some buffer-local
> > variable.  The relative complexity of this wrt what terminal emulators
> > do is that terminal emulators can do that always, whereas Emacs cannot
> > do that by default, it must be an opt-in feature requested by the
> > likes of term.el.
> 
> Yes.
> 
> Hm...  actually, that sounds like a pretty good feature in general for
> all modes that expect columnar output, doesn't it?

Any feature that displays text in a tabular form, or otherwise needs
arbitrary text to align, yes.

> That is, being able to snap all glyphs to an integer multiple of the
> standard character width?  That is, add padding if the width is more
> than 0.5 wider than the standard width and narrow the glyph if it's
> less?  (Whether to only narrow could also be an option.)

I think ideally we should make each character as wide as char-width
says it should be, because a well-behaved text-mode application is
supposed to arrange text according to that.  It should be easy to do
that, but I'm afraid we will bump into characters whose char-width is
1, but which are much wider on display.  I don't know what to do in
that case.