GNU bug report logs -
#44664
28.0.50; troubles with some chars in term
Previous Next
Full log
View this message in rfc822 format
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
> Date: Thu, 26 Nov 2020 10:50:57 +0100
>
> Eli Zaretskii <eliz <at> 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.
This bug report was last modified 3 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.