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

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <ghe <at> sdf.org>, 42307 <at> debbugs.gnu.org
Subject: bug#42307: Feature request: Visual block attribute for overlays
Date: Fri, 10 Jul 2020 07:56:25 -0700 (PDT)

> 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".  ...
>
> 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.
> 
> To give an example of what I mean, I attach three pictures, taken with
> (show-paren-mode) and (setq show-paren-style 'expression), showing
> respectively the earlier default, the current default, and the proposed
> "visualblock" feature.

Interesting.  Thanks for the images, in particular.
I agree that each of the 3 is useful, and they all
should be available.

Looking only at the images, I have this question about
your "visual block" coverage:

What if `overlay-start' were on the `u', instead of the
`i', of `if (consp ,funs))'?  Would the overlay cover
only from that `u' onward, or would it still cover from
the `i' of `if' onward?  IOW, does the left edge of the
highlighted area extend downward from `overlay-start',
or does it start from the first non-whitespace char in
the line?

What about a variant of your "visual block" that
extends the overlay so that all lines, from the first
line, which contains `overlay-start' to the last line,
which contains `overlay-end', are covered through the
same columns?  Coverage (highlighting) would then
always be a rectangle.  In your example, it would
the highlighting of the last line would be extended
to the same column as that of the other lines.

Your "visual block", and the variant just described,
just like the old behavior, cover both whitespace
chars and empty screen real estate (no chars), from
`overlay-start' to `overlay-end'.  The new behavior
is the only one that covers only _chars_ in that
span (whitespace or other chars).

In any case, whatever the choices we offer, Elisp
should make it simple to choose any of them.

Previous Next

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