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

Previous Next

Package: emacs;

Reported by: Ivan Andrus <darthandrus <at> gmail.com>

Date: Thu, 22 Mar 2012 21:21:02 UTC

Severity: wishlist

Found in version 24.0.94

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

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: darthandrus <at> gmail.com, cyd <at> stupidchicken.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 21:19:43 +0200
> Correct.  But only for lines that end before EOB.  The line that ends
> _at_ EOB and all the subsequent lines don't have this stretch glyph.
> The changes I did introduce such stretch glyphs for _all_ lines in the
> window than don't already have them.

So you do use an established mechanism but for the fact that these lines
exist only virtually.  Or am I missing something?

>> And it takes the face property not from the return character but
>> from the remapped default face.
>
> No, the return character has no face,

But when drawing the stretch glyph at a non-EOB line end the display
engine does use the face of the return character.  In my
`font-lock-fontify-syntactically-region' function I strip all face
properties from the return character and the rest of the line has the
default background.

> and in fact it has no glyphs.
> The original code would reset the face to the (un-remapped) default
> face when it hits the line at EOB, and would not draw past EOB at all,
> instead relying on the display-specific code that clears the rest of
> the window with the default color.

Couldn't we "clear" using the remapped default color as well?  Does
"clearing" care about character heights, for example?

>> As an aside I earlier tried to achieve the effect of your patch by
>> adding an overlay with an after-string containing an appropriate number
>> of return characters to the last character of each buffer.  It didn't
>> work and I still consider that a bug.
>
> If you show me the code, I will see if it's a bug or something else.

If you do, for example,

(let ((overlay (make-overlay (point-max) (point-max))))
  (overlay-put overlay 'after-string "\n\n\n\n"))

you can't move to the position before the overlay which makes the whole
thing worthless.

martin




This bug report was last modified 13 years and 54 days ago.

Previous Next


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