GNU bug report logs - #42307
Feature request: Visual block attribute for overlays

Previous Next

Full log

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

From: Gregory Heytings <ghe <at> sdf.org>
To: 42307 <at> debbugs.gnu.org
Subject: Re: bug#42307: Feature request: Visual block attribute for
 overlays
Date: Tue, 14 Jul 2020 17:01:43 +0000

>>> and \n is the newline, so it isn't on the same line.
>>>
>>
>> It is, but it's the last character of the line.  With the current 
>> default behavior it is displayed, there is one more blank character 
>> after each line, just type C-x = on that character.
>
> My point is that \n cannot be "leading space" of a line.  It is the end 
> of the previous line.
>

Yes, now I see what you mean.  So the regexp for "blank" on the left would 
be "[ \t]*", and the regexp for "blank" on the right would be "\n%*", 
where "%" denotes "no character".

>
>>> And finally, what about stretches of whitespace generated by the 
>>> 'space' display properties?
>>
>> I don't know, and I'm not sure I fully understand the question.
>
> The point is that the result of displaying these properties is exactly 
> the same as tabs and spaces.  So excluding them would surprise users.
>

Okay.  So... let's include them ;-)

In fact, I'm not entirerly sure that explaining (or implementing) that 
behavior with regexpes or character is the best thing to do.  It's a 
matter of visual representation.  Perhaps the following explanation is 
clearer (or more precise): draw the overlay with :extend t, and remove 
pixel columns on the left and on the right that are displayed in the same 
way as a whitespace character would have been displayed.

Gregory

Previous Next

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