GNU bug report logs - #11068
24.0.94; Face-remapped background does not extend to end of window

Previous Next

Full log

Message #55 received at 11068 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: darthandrus <at> gmail.com, 11068 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#11068: 24.0.94;
	Face-remapped background does not extend to end of window
Date: Sun, 25 Mar 2012 14:20:57 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Here I disagree: I think we should confine the internal details of
> face remapping to lookup_basic_face, instead of spilling our knowledge
> about that all over.  As you just said above, if face-remapping-alist
> is nil, that function returns immediately, so there's nothing lost
> here for the "usual" use-case.

I don't know how making use of the return value from a previous call to
lookup_basic_face (when default_face was assigned) is "spilling our
knowledge", but whatever; it's not a important point.

> OK, but to be absolutely fair, I must point out that, while the patch
> is very simple, it has one non-trivial consequence: when the default
> face _is_ remapped, the empty space to the right of any L2R line and
> the empty lines beyond EOB are filled with stretch glyphs of a
> suitably computed width.  Before the patch, there were no glyphs in
> those places.  So, from the POV of the content of the glyph matrices,
> the change introduced by these patches is quite prominent.  In
> particular, this could potentially affect any code that examines the
> glyphs of a glyph matrix; previously, such stretch glyphs were only
> present at the left side of R2L glyph rows.

Hmm, you're right, that is a non-trivial change.  The implications of
that are not obvious to me.  Maybe we should delay this for post-24.1
then.

Previous Next

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