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

Previous Next

To reply to this bug, email your comments to 42347 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Gregory Heytings <ghe <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Feature request: Visual block attribute for overlays
Date: Wed, 8 Jul 2020 19:19:05 +0200 (CEST)

In Emacs 21 to 26, overlays between two points in the buffer on two 
different lines extend to the right border of the window.  This has 
changed in Emacs 27, and now the default is that overlays extend only one 
character position after the last character of the line.  The previous 
behavior can be obtained with the ":extend t" face attribute.  I agree 
that the earlier behavior was not optimal, but I think the current 
behavior with its staircase aspect is not optimal either.

I think a third way to display overlays would make sense, and would be 
better than the earlier and current defaults.  Let's name this attribute 
":visualblock".  It would produce the following result:

1. calculate the overlay it it would have been displayed by Emacs 21-26.

2. remove all pixel columns on the right *and on the left* of the overlay 
which have no "content" (that is, no characters on the right, and 
whitespace characters on the left).

With this, on overlay on, for example, a block of code between () or {} 
would be displayed on the screen as a block.  The above "algorithm" works 
with fixed and variable-width fonts, but could be made more efficient for 
fixed-width fonts.

Gregory

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: 42347 <at> debbugs.gnu.org
Subject: Re: bug#42347: Feature request: Visual block attribute for overlays
Date: Tue, 14 Jul 2020 05:32:41 +0300

> Date: Wed, 8 Jul 2020 19:19:05 +0200 (CEST)
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 1. calculate the overlay it it would have been displayed by Emacs 21-26.
> 
> 2. remove all pixel columns on the right *and on the left* of the overlay 
> which have no "content" (that is, no characters on the right, and 
> whitespace characters on the left).

What would be the definition of "whitespace" for this purpose?

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <ghe <at> sdf.org>, 42347 <at> debbugs.gnu.org
Subject: RE: bug#42347: Feature request: Visual block attribute for overlays
Date: Mon, 13 Jul 2020 21:23:59 -0700 (PDT)

> The previous behavior can be obtained with the ":extend t" face attribute.

Only on an individual basis, right?  If you want to
get the previous behavior everywhere, do you need
to change every overlay?

Or is there an option for that?  If not, why not?

And is there a way to get the previous behavior by
default, and something that does the opposite of
`:extend' for individual cases where you want the
new behavior?

If not, why not?

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

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

This should be merged with bug #42307.  (It was sent earlier, and for some 
reason stayed in the mail queue during a week.)

>
>> 1. calculate the overlay it it would have been displayed by Emacs 
>> 21-26.
>>
>> 2. remove all pixel columns on the right *and on the left* of the 
>> overlay which have no "content" (that is, no characters on the right, 
>> and whitespace characters on the left).
>
> What would be the definition of "whitespace" for this purpose?
>

I think the regexp "[ \t\r\n]*" would be appropriate.

Gregory

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

From: Gregory Heytings <ghe <at> sdf.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 42347 <at> debbugs.gnu.org
Subject: RE: bug#42347: Feature request: Visual block attribute for
 overlays
Date: Tue, 14 Jul 2020 07:49:34 +0000

>
>> The previous behavior can be obtained with the ":extend t" face 
>> attribute.
>
> Only on an individual basis, right?  If you want to get the previous 
> behavior everywhere, do you need to change every overlay?
>

AFAIK, yes.

>
> Or is there an option for that?  If not, why not?
>
> And is there a way to get the previous behavior by default, and 
> something that does the opposite of `:extend' for individual cases where 
> you want the new behavior?
>
> If not, why not?
>

I don't know, but I do not see this as a problem.  After all, if one wants 
the previous behavior, only a handful of faces need to be updated. 
Apparently the new behavior was considered better.  The NEWS item about 
this (in NEWS.27) states:  "This is to make Emacs behave more like other 
GUI applications with respect to displaying faces that cross line 
boundaries."

Gregory

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: 42347 <at> debbugs.gnu.org
Subject: RE: bug#42347: Feature request: Visual block attribute for overlays
Date: Tue, 14 Jul 2020 07:48:47 -0700 (PDT)

> >> The previous behavior can be obtained with the ":extend t" face
> >> attribute.
> >
> > Only on an individual basis, right?  If you want to get the previous
> > behavior everywhere, do you need to change every overlay?
> 
> AFAIK, yes.
> 
> > Or is there an option for that?  If not, why not?
> >
> > And is there a way to get the previous behavior by default, and
> > something that does the opposite of `:extend' for individual cases
> > where you want the new behavior?  If not, why not?
> >
> 
> I don't know, but I do not see this as a problem.  After all, if one
> wants the previous behavior, only a handful of faces need to be updated.

Really?  That's what people thought at the beginning
of this change.  Then more popped up, one by one.

Why should a user, and not necessarily a lisper, need
to find and fix each such face - handful or not - to
get back the previous behavior, if that's what s?he
prefers?

> Apparently the new behavior was considered better.  The NEWS item about
> this (in NEWS.27) states:  "This is to make Emacs behave more like
> other GUI applications with respect to displaying faces that cross line
> boundaries."

Yes, I know the rationale.  It doesn't follow that
all, or even most, users feel the same way.

There are lots of outside-Emacs behaviors that we
don't impose as the default - let alone the only -
behavior in Emacs.

I'm not making an argument that users shouldn't be
able to get the new behavior, or even that the new
behavior should not have been adopted immediately
as the default (well...).  My argument is to make
it simple for users to switch behaviors.  Why not?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: 42347 <at> debbugs.gnu.org
Subject: Re: bug#42347: Feature request: Visual block attribute for overlays
Date: Tue, 14 Jul 2020 17:55:13 +0300

> Date: Tue, 14 Jul 2020 07:38:38 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> >> 2. remove all pixel columns on the right *and on the left* of the 
> >> overlay which have no "content" (that is, no characters on the right, 
> >> and whitespace characters on the left).
> >
> > What would be the definition of "whitespace" for this purpose?
> >
> 
> I think the regexp "[ \t\r\n]*" would be appropriate.

Are you sure?

First, \r doesn't happen in Emacs buffers, and \n is the newline, so
it isn't on the same line.

Next, what about \f, and more generally about any other sequence of
characters that match [:blank:]?

And finally, what about stretches of whitespace generated by the
'space' display properties?

Previous Next

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