all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 15899@debbugs.gnu.org
Subject: bug#15899: 24.3.50; regression: `region' overlay is lower priority than default
Date: Fri, 15 Nov 2013 19:47:37 -0800 (PST)	[thread overview]
Message-ID: <ae5c4a92-222a-4316-a951-d3fe0d84fdcc@default> (raw)
In-Reply-To: <jwvsiuxp26p.fsf-monnier+emacsbugs@gnu.org>

> > The fact that face `region' highlights "on top of" other
> > highlighting is _on purpose_, i.e., by design.
> 
> No, it was the result of the implementation technique, no
> of design.

You "accidentally" cut off that first line, where I said
_what_ was by design.  I've put it back, to restore the
message honestly.

How do you know that Emacs Dev did not _intend_ for the
region display to appear "on top of" other highlighting
(with the exception of isearch)?

I don't believe for a second that this was by accident or
just a result of an "implementation technique".  Not until
you can show some supporting evidence for that claim.

Without contrary evidence, I am persuaded that Emacs, like
every other app that uses selection, chose this behavior for
its _user-level_ effect: The point is to show users just what
is selected.  There is no better reason to make such a choice.  
Result of an "implementation technique", indeed!

And there were already lots of other UIs that showed
selection highlighting, before Emacs added its own.  Just as
for menus, tooltips, mouse-face highlighting, links, text
attributes, and much of the rest of the Emacs UI, these things
were developed first outside Emacs and only later (sometimes
much later) emulated by and added to Emacs.  Emacs got its
selection highlighting design from others, not as a result
of some Emacs "implementation technique".

Users everywhere expect a selection highlight to show them
clearly what they've selected.  That, and not some unspoken
"implementation technique", is the reason that Emacs Dev
showed the region face clearly throughout the region selected.
Up until this regression, that is.

If what is now the behavior remains, then Emacs will be the
only UI I'm aware of that does not have selection
highlighting override other highlighting in appearance - the
only one where _you cannot know what you've selected_ based
on highlighting.  Can you name another UI that does that?

This is really, really silly.  Usability out the window - poof.

Users will have no idea what they are selecting.  Except in
lucky cases.  And even then they will have to remain unsure,
because there is no way to tell whether what they are seeing
highlighted as selected is really everything that is selected
or just some of it.

> Usually the context makes it pretty clear,

"Usually" there is no other highlighting of the same text.
So what?  This usual case is not what the bug is about.

> and if the user is surprised at some point, that surprise
> will most likely not last very long

Wrong.  They will need to remain unsure - there is no way
to know whether something unhighlighted with face `region' is
in fact selected.

And even if you were right that user confusion would "most
likely not last very long" (based on what?), there is _no
reason_ that users have to be confused about selection
coverage at all.  This-won't-hurt-long is no consolation,
because there is no need to inflict pain in the first place.

No reason not to show them the region highlighted normally.





  reply	other threads:[~2013-11-16  3:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-14 22:57 bug#15899: 24.3.50; regression: `region' overlay is lower priority than default Drew Adams
2013-11-15  7:41 ` Eli Zaretskii
2013-11-15 13:54   ` Stefan Monnier
2013-11-15 14:40     ` Eli Zaretskii
2013-11-15 15:32       ` Dmitry Gutov
2013-11-15 16:40         ` Eli Zaretskii
2013-11-15 22:35           ` Dmitry Gutov
2013-11-16  8:49             ` Eli Zaretskii
2013-11-16  9:51               ` Jarek Czekalski
2013-11-16 10:42                 ` Eli Zaretskii
2013-11-16 14:43                   ` Jarek Czekalski
     [not found]                 ` <<83ppq0hbln.fsf@gnu.org>
2013-11-16 16:23                   ` Drew Adams
2013-11-16 16:52                     ` Eli Zaretskii
2013-11-16 22:01                     ` Stefan Monnier
2013-11-16 22:42                       ` Drew Adams
2013-11-16 10:25               ` Dmitry Gutov
2013-11-16 11:24                 ` Eli Zaretskii
2013-11-16 13:49                   ` Dmitry Gutov
2013-11-16 16:30                     ` Drew Adams
2013-11-16 16:20                 ` Drew Adams
     [not found]                 ` <<83ob5kh9nb.fsf@gnu.org>
2013-11-16 16:24                   ` Drew Adams
2013-11-16  1:25       ` Stefan Monnier
2013-11-16  9:06         ` Eli Zaretskii
2013-11-16 17:45           ` Stefan Monnier
2013-11-16 18:01             ` Drew Adams
2013-11-16 22:00               ` Stefan Monnier
2013-11-17 12:25             ` Daniel Colascione
2013-11-17 15:42               ` Stefan Monnier
2014-02-10  4:14         ` Lars Ingebrigtsen
2013-11-15 15:51     ` Drew Adams
2013-11-16  1:26       ` Stefan Monnier
2013-11-16  3:47         ` Drew Adams [this message]
2013-11-15 16:53 ` Barry OReilly
     [not found] <<"<20137354-f982-4314-9c09-21a5fbc36557"@default>
     [not found] ` <<"<jwvsiux4vrn.fsf-monnier+emacsbugs"@gnu.org>
     [not found]   ` <<"<87mwl58yvc.fsf"@yandex.ru>
     [not found]     ` <<834n7dipnq.fsf@gnu.org>
     [not found]       ` <<"<83wqk8hgtf.fsf"@gnu.org>
     [not found]         ` <<7031ba1e-2f47-4dd0-908a-938c26016e12@default>
     [not found]           ` <<83k3g8gug7.fsf@gnu.org>
2013-11-16 17:47             ` Drew Adams
     [not found] <<78b8713a-e96f-4b4d-990a-3af59ebdf942@default>
     [not found] ` <<83zjp5h33w.fsf@gnu.org>
2013-11-15 21:21   ` Drew Adams
     [not found] <<00aa91d2-10a2-4a78-bb95-042d1596a41c@default>
     [not found] ` <<8338mxipix.fsf@gnu.org>
2013-11-15 17:14   ` Drew Adams
2013-11-15 19:33     ` Eli Zaretskii
     [not found] <<20137354-f982-4314-9c09-21a5fbc36557@default>
     [not found] ` <<83ob5mi02j.fsf@gnu.org>
     [not found]   ` <<jwvsiux4vrn.fsf-monnier+emacsbugs@gnu.org>
     [not found]     ` <<83bo1liv80.fsf@gnu.org>
2013-11-15 15:55       ` Drew Adams
2013-11-15 16:43         ` Eli Zaretskii
     [not found] <"<20137354-f982-4314-9c09-21a5fbc36557"@default>
     [not found] ` <"<jwvsiux4vrn.fsf-monnier+emacsbugs"@gnu.org>

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=ae5c4a92-222a-4316-a951-d3fe0d84fdcc@default \
    --to=drew.adams@oracle.com \
    --cc=15899@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.