bug#15899: 24.3.50; regression: `region' overlay is lower priority than default

[Drew Adams]

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