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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <ghe <at> sdf.org>

Date: Tue, 14 Jul 2020 00:52:01 UTC

Severity: wishlist

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 00:52:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gregory Heytings <ghe <at> sdf.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 14 Jul 2020 00:52:01 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 02:33:02 GMT) Full text and rfc822 format available.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 04:25:02 GMT) Full text and rfc822 format available.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 07:39:02 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 07:50:01 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 14:50:01 GMT) Full text and rfc822 format available.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42347; Package emacs. (Tue, 14 Jul 2020 14:56:02 GMT) Full text and rfc822 format available.

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?




This bug report was last modified 3 years and 258 days ago.

Previous Next


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