[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42307: Feature request: Visual block attribute for overlays
From: |
Drew Adams |
Subject: |
bug#42307: Feature request: Visual block attribute for overlays |
Date: |
Fri, 10 Jul 2020 09:42:32 -0700 (PDT) |
> > 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
- bug#42307: Feature request: Visual block attribute for overlays, Gregory Heytings, 2020/07/10
- bug#42307: Feature request: Visual block attribute for overlays, Drew Adams, 2020/07/10
- bug#42307: Feature request: Visual block attribute for overlays, Drew Adams, 2020/07/10
- bug#42307: Feature request: Visual block attribute for overlays, Gregory Heytings, 2020/07/10
- bug#42307: Feature request: Visual block attribute for overlays, Gregory Heytings, 2020/07/10
- bug#42307: Feature request: Visual block attribute for overlays, Juri Linkov, 2020/07/11
- bug#42307: Feature request: Visual block attribute for overlays, Drew Adams, 2020/07/11
- bug#42307: Feature request: Visual block attribute for overlays, Gregory Heytings, 2020/07/12
- bug#42307: Feature request: Visual block attribute for overlays, Juri Linkov, 2020/07/12
- bug#42307: Feature request: Visual block attribute for overlays, Gregory Heytings, 2020/07/13