colorizing empty space

colorizing empty space

[Ted Zlatanov]

Say you have a buffer with this text (showing newlines as \n)

Hello\n
there\n
everyone\n

and you want to colorize the text background.  You'd end up with a
ragged appearance on the right, because the text ends at the newlines,
or (if you choose to colorize the newlines) the background would extend
to the right margin of the buffer, which looks awful when rendering
readable text in very wide buffers.

I wonder if there's a way to give all the lines max(paragraph lines)+1
width using "visual" space, so at least one "visual" space is added on
the right (shown with x):

Helloxxxx\n
therexxxx\n
everyonex\n

which can then be colorized with the proper background.  I'd like this
to happen without actually modifying the text (so if copied it will
retain the original content), so I was wondering if font-lock or some
other Emacs wizardry could be used to create this "visual" space effect.

Thanks
Ted

Re: colorizing empty space

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I wonder if there's a way to give all the lines max(paragraph lines)+1
> width using "visual" space, so at least one "visual" space is added on
> the right (shown with x):
>
> Helloxxxx\n
> therexxxx\n
> everyonex\n
>
> which can then be colorized with the proper background.  I'd like this
> to happen without actually modifying the text (so if copied it will
> retain the original content), so I was wondering if font-lock or some
> other Emacs wizardry could be used to create this "visual" space effect.

You could make the "xxxx\n" a display string on top of the newline
character.

Re: colorizing empty space

[Ted Zlatanov]

On Mon, 20 Dec 2010 18:50:13 +0800 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I wonder if there's a way to give all the lines max(paragraph lines)+1
>> width using "visual" space, so at least one "visual" space is added on
>> the right (shown with x):
>> 
>> Helloxxxx\n
>> therexxxx\n
>> everyonex\n
>> 
>> which can then be colorized with the proper background.  I'd like this
>> to happen without actually modifying the text (so if copied it will
>> retain the original content), so I was wondering if font-lock or some
>> other Emacs wizardry could be used to create this "visual" space effect.

CY> You could make the "xxxx\n" a display string on top of the newline
CY> character.

That sounds reasonable.  Thank you for the hint.  We'll try it in Gnus.

Ted

Re: colorizing empty space

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> CY> You could make the "xxxx\n" a display string on top of the newline
> CY> character.
>
> That sounds reasonable.  Thank you for the hint.  We'll try it in Gnus.

A display string?  How does that work?

Oh, putting a `display' property on the newlines that has a lot of
spaces in it?  Neat.  I'll try to have shr do that and see how that
looks. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: colorizing empty space

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, putting a `display' property on the newlines that has a lot of
> spaces in it?  Neat.  I'll try to have shr do that and see how that
> looks. 

Uhm.  But then we'd have to put the background colour on the newline
character anyway, so that won't help?

Or perhaps putting the display property on the last character on the
line would do the trick?  (And we'd have to add the character itself,
then, to the property.)

But what about completely blank lines?

Uhm...  or perhaps Emacs respects text with properties as the display
property...  yeah...  I'll try that, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: colorizing empty space

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Uhm...  or perhaps Emacs respects text with properties as the display
> property...  yeah...  I'll try that, then.

That works.  Here's my test case:


[-- Attachment #2: Type: text/html, Size: 132 bytes --]

[-- Attachment #3: Type: text/plain, Size: 554 bytes --]


The problem is, though, that this doesn't really solve anything.
Whether you put a `display' property on the text, or you pad it with
spaces, the result is much the same: If you kill'n'yank the text to a
different buffer, and want to use it there, you still have to deal with
the pesky extra padding.  With the `display' hack it's even worse,
because there's not obvious way to get rid of the padding.

So I think this approach isn't quite workable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: colorizing empty space

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I think this approach isn't quite workable.

It was suggested to use overlays and `before-string', and that seems to
work perfectly with kill'n'yank.

The current implementation doesn't handle all cases (nested boxes where
the outer one is bigger than the inner), but that should be a SMOP.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: colorizing empty space

[Daniel Colascione]

2010/12/16 Ted Zlatanov <tzz@lifelogs.com>:
> I wonder if there's a way to give all the lines max(paragraph lines)+1
> width using "visual" space, so at least one "visual" space is added on
> the right (shown with x):

On another note, I've been looking for a way to colorize the area of a
window after EOB. I have a compile mode hook that turns the window
background red on error. Using text properties, the best I can do is
change the color of the text itself. The region between the end of the
text and the bottom of the window is still the frame's default color.
If the window is in its own frame, I can just change the frame
background color, but I'd like to be able to achieve this effect for
normal windows. Adding extra newlines will work, but that distorts the
scroll bar position, M-> handling, and so on. Any ideas?

Re: colorizing empty space

[Lennart Borgman]

On Tue, Jan 25, 2011 at 9:24 AM, Daniel Colascione
<dan.colascione@gmail.com> wrote:
> 2010/12/16 Ted Zlatanov <tzz@lifelogs.com>:
>> I wonder if there's a way to give all the lines max(paragraph lines)+1
>> width using "visual" space, so at least one "visual" space is added on
>> the right (shown with x):
>
> On another note, I've been looking for a way to colorize the area of a
> window after EOB. I have a compile mode hook that turns the window
> background red on error. Using text properties, the best I can do is
> change the color of the text itself. The region between the end of the
> text and the bottom of the window is still the frame's default color.
> If the window is in its own frame, I can just change the frame
> background color, but I'd like to be able to achieve this effect for
> normal windows. Adding extra newlines will work, but that distorts the
> scroll bar position, M-> handling, and so on. Any ideas?

There is no way to do it. A change in Emacs display code is needed.

Re: colorizing empty space

[Daniel Colascione]

On Tue, Jan 25, 2011 at 2:17 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Tue, Jan 25, 2011 at 9:24 AM, Daniel Colascione
> <dan.colascione@gmail.com> wrote:
>> 2010/12/16 Ted Zlatanov <tzz@lifelogs.com>:
>>> I wonder if there's a way to give all the lines max(paragraph lines)+1
>>> width using "visual" space, so at least one "visual" space is added on
>>> the right (shown with x):
>>
>> On another note, I've been looking for a way to colorize the area of a
>> window after EOB. I have a compile mode hook that turns the window
>> background red on error. Using text properties, the best I can do is
>> change the color of the text itself. The region between the end of the
>> text and the bottom of the window is still the frame's default color.
>> If the window is in its own frame, I can just change the frame
>> background color, but I'd like to be able to achieve this effect for
>> normal windows. Adding extra newlines will work, but that distorts the
>> scroll bar position, M-> handling, and so on. Any ideas?
>
> There is no way to do it. A change in Emacs display code is needed.

Is it too late to ask for specifiers? :-)

Re: colorizing empty space

[Stephen J. Turnbull]

Daniel Colascione writes:

 > > There is no way to do it. A change in Emacs display code is needed.
 > 
 > Is it too late to ask for specifiers? :-)

That wouldn't help unless the display code was taught to respect
them.  That would be a big change, and Emacs Lisp (vs. XEmacs Lisp)
seems to be moving in the opposite direction with at least an informal
deprecation of frame-local variables.

Re: colorizing empty space

[Stefan Monnier]

>> > There is no way to do it. A change in Emacs display code is needed.
>> Is it too late to ask for specifiers? :-)
> That wouldn't help unless the display code was taught to respect
> them.  That would be a big change, and Emacs Lisp (vs. XEmacs Lisp)
> seems to be moving in the opposite direction with at least an informal
> deprecation of frame-local variables.

OTOH with face-remapping-alist you should be able to do just what you
want: remap the `default' face to something with
a different background.  It works for text-scale-increase.


        Stefan

Re: colorizing empty space

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> OTOH with face-remapping-alist you should be able to do just what you
> want: remap the `default' face to something with
> a different background.  It works for text-scale-increase.

Using face-remapping-alist with `default' doesn't do the proper thing
after EOB though.  I think this is because the area after EOB is handled
specially in various ways, instead of by the general redisplay code
path.

It's a bug (I tried for a while to fix it, but got too confused by the
redisplay code), but I suppose doesn't show up for typical uses of
face-remapping-alist, which tend to only modify font attributes that
affect the text itself.

[You can see it even with text-scale-increase though:  make the text
size really big, and notice that although the blinking cursor is
appropriately sized when in the middle of the text, it has the wrong
size when positioned at EOB...]

-Miles

-- 
On a bad day, I see brewers still talking as though all beer were
consumed in the pub, by the pint -- by insatiably thirsty Yorkshire
steelworkers who have in reality long ago sought work as striptease
artists.  [Michael Jackson]

Re: colorizing empty space

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> System-Type: x86_64-unknown-linux-gnu
> Date: Wed, 26 Jan 2011 13:46:12 +0900
> Cc: Daniel Colascione <dan.colascione@gmail.com>,
> 	"Stephen J. Turnbull" <stephen@xemacs.org>,
> 	Lennart Borgman <lennart.borgman@gmail.com>,
> 	Ted Zlatanov <tzz@lifelogs.com>, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > OTOH with face-remapping-alist you should be able to do just what you
> > want: remap the `default' face to something with
> > a different background.  It works for text-scale-increase.
> 
> Using face-remapping-alist with `default' doesn't do the proper thing
> after EOB though.  I think this is because the area after EOB is handled
> specially in various ways, instead of by the general redisplay code
> path.
> 
> It's a bug (I tried for a while to fix it, but got too confused by the
> redisplay code), but I suppose doesn't show up for typical uses of
> face-remapping-alist, which tend to only modify font attributes that
> affect the text itself.

Would adding a call to extend_face_to_end_of_line in a couple of more
places solve this?  Does face-remapping work on a tty in this case?

Anyway, if someone can post a spec for the feature that is being
requested, I'll try to see how hard is it to implement that.

Re: colorizing empty space

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> > OTOH with face-remapping-alist you should be able to do just what you
>> > want: remap the `default' face to something with
>> > a different background.  It works for text-scale-increase.
>> 
>> Using face-remapping-alist with `default' doesn't do the proper thing
>> after EOB though.  I think this is because the area after EOB is handled
>> specially in various ways, instead of by the general redisplay code
>> path.
>> 
>> It's a bug (I tried for a while to fix it, but got too confused by the
>> redisplay code), but I suppose doesn't show up for typical uses of
>> face-remapping-alist, which tend to only modify font attributes that
>> affect the text itself.
>
> Would adding a call to extend_face_to_end_of_line in a couple of more
> places solve this?

I don't know.
n
> Does face-remapping work on a tty in this case?

Nope.

> Anyway, if someone can post a spec for the feature that is being
> requested, I'll try to see how hard is it to implement that.

I think they just want a way to set a per-buffer window-background
color, in a way that affects the area after EOB as well as the buffer
text.

This should be achievable by doing something like:

   (face-remap-add-relative 'default :background "blue")

... as the `default' face is supposed to be used for everything
including the EOB area, but this doesn't work properly because of the
above-mentioned bug.

-Miles

-- 
Run away!  Run away!

Re: colorizing empty space

[Daniel Colascione]

On Tue, Jan 25, 2011 at 10:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Anyway, if someone can post a spec for the feature that is being
> requested, I'll try to see how hard is it to implement that.

The display engine should paint the after-EOB area of a window W,
which is in frame F and is displaying buffer B, using the background
color specified by `default' face in B after applying any remappings
specified by possibly buffer- and frame-local bindings of
face-remapping-alist in B and F, respectively.

(Fixing the text size problem mentioned above would help too.)