bug#42307: Feature request: Visual block attribute for overlays

[Drew Adams]

> > What if `overlay-start' were on the `u', instead of the `i',
> 
> Actually it starts on the '(', the opening parenthesis is green if you
> look close enough.

Yes, that's what I meant and should have said.

> > 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?
> 
> If you take the algorithm, it would start on the "u", extend to the
> place it extends on the picture on the right, and on the next lines
> two whitespace characters on the left would not be displayed as
> green anymore (that is, the green area would start under the "f" of
> "(if".

Why is that? That starting position of the second line's
highlight doesn't correspond to anything "natural", does
it?  I would expect either that it starts as it does now,
directly under the `(' of the first line, or directly
under the `u' that started the overlay.

> > 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, the
> > highlighting of the last line would be extended to the same
> > column as that of the other lines.
> >
> 
> That's a possible variant, indeed.  Let's name this one
> "visualrectangle".  But from a programmer's point of view it
> makes (IMHO) less sense.

Neither makes sense from a coding point of view, I think.
At least not what you describe above, where the second
line's highlighting starts under the `f' of the first
line's `if'.  What does that position even correspond to?

In any case, overlays, and highlighting, are not just for
code.

> > 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).
> >
> 
> Indeed.  Yet another possibility would be cover only
> non-whitespace chars. Let's name this one "visiblechars".
> 
> > In any case, whatever the choices we offer, Elisp should
> > make it simple to choose any of them.
> >
> 
> Yes ;-)  My personal preference order among the possible choices is:
> 
> 1. visualblock
> 2. the previous default
> 3. visiblechars
> 4. the current default
> 5. visualrectangle