all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 42307@debbugs.gnu.org
Subject: bug#42307: Feature request: Visual block attribute for overlays
Date: Fri, 10 Jul 2020 16:02:52 +0000	[thread overview]
Message-ID: <alpine.NEB.2.21.2007101748360394.11489@sdf.lonestar.org> (raw)
In-Reply-To: <21c81ecf-75d7-47d7-9b10-d2050769f6e3@default>


Thanks for your feedback!

>
> 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',
>

Actually it starts on the '(', the opening parenthesis is green if you 
look close enough.

>
> 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".

>
> 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.
>

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.

>
> 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

Gregory





  parent reply	other threads:[~2020-07-10 16:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10  8:24 bug#42307: Feature request: Visual block attribute for overlays Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-10 14:56 ` Drew Adams
2020-07-10 15:24   ` Drew Adams
2020-07-10 16:02   ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-07-10 16:42     ` Drew Adams
2020-07-10 18:57       ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-10 21:26     ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-11 23:50     ` Juri Linkov
2020-07-12  1:25       ` Drew Adams
2020-07-12  8:21         ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-12 23:59         ` Juri Linkov
2020-07-13  6:45           ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
  -- strict thread matches above, loose matches on Subject: below --
2020-07-08 17:19 bug#42347: " Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14  2:32 ` Eli Zaretskii
2020-07-14  7:38   ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14 14:55     ` Eli Zaretskii
2020-07-14 15:45       ` bug#42307: " Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14 16:34         ` Eli Zaretskii
2020-07-14 17:01           ` bug#42307: " Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14 17:10             ` Eli Zaretskii
2020-07-14 17:20               ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14  4:23 ` bug#42347: " Drew Adams
2020-07-14  7:49   ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-14 14:48     ` Drew Adams
2020-07-14 15:53       ` bug#42307: " Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.NEB.2.21.2007101748360394.11489@sdf.lonestar.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=42307@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=ghe@sdf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.