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>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> linux-m68k.org, bugs <at> gnu.support, 44664 <at> debbugs.gnu.org
Subject: bug#44664: 28.0.50; troubles with some chars in term
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?  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.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.