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

[Drew Adams <drew.adams@oracle.com>]

> > 1. I meant that the change to the behavior of the region not
> >    appearing "on top of" other highlighting (except isearch)
> >    needs to be reverted (undone).
> 
> You cannot revert behavior, only the code.

I added "(undone)", to be clear.  And no, code is not the only
thing that can be reverted.  When you revert a buffer using
`g', you are reverting behavior/effects, not reverting code.

Revert just means to go back to a previous state.

> If the new implementation has unwanted side effects, those side
> effects need to be fixed by further changes.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No, that is not the need.  The need is to remove the unwanted side
effects - sure.  But that does not imply keeping the culprit code
and then trying to make "further changes" to make things right.

That is only one possible approach.  It is not _necessary_ to
follow that approach -there is no such "need".

Another approach is to (1) revert the code changes that brought
about the regression and then (2) fix the bug those changes were
intended to fix in some other way.

That is, assuming there really was a bug to be fixed.  Can you
say what it was?  If so, can you also say why keeping the changes
made so far and applying (unknown) "further changes" is the best
way to go?

> > 4. If it was in fact a bug, it's not clear why the fix for it
> > needed to involve changing region highlighting to use an
> > overlay.  Not clear to me anyway.
> 
> It doesn't have to be clear.

I assume you mean that it does not have to be clear to me.
Hopefully you agree that it has to be clear to someone.

Is it clear to you?  If so, do tell, pray.

> The fact that region highlighting now uses an overlay is an
> implementation detail.

No, it is not.  Why?  Because Emacs _users_ do things with buffer
text, and with text properties, and with overlays.  These are not
simply implementation artifacts.  They are first class Emacs
thingies that can be and are manipulated by Emacs users.

Some users might not care whether some particular highlighting is
via a text property or an overlay.  Other users might care.
Depends on what they are doing.  Users interact with Emacs in
lots of ways besides interactive use of `emacs -Q' commands and
menus.  They add text properties, examine them, change them,
search their text, change their text,...

This is a passably big change for Emacs Users.  Emacs has used
text property `face' to "implement" region highlighting ever
since such highlighting has existed.  Why no proposal for such
a change?  No discussion?

> Bug reports should generally remain on the level of behavior,
> i.e. requirements, they should not normally go to the
> implementation level.

What is the _behavioral requirement_ that obliges the use of an
overlay for the region?  Can you answer that?  I've seen nothing
so far.

Talk about text properties vs overlays is on the user level, as
well as the developer level.  It is mistaken to think that it is
something hidden to users inside some "implementation level".

> The implementors should have freedom to implement the
> required behavior as they see fit, as long as the results are
> reasonable.

Sure they should.  But just what is the required behavior here?
And how relative is that "freedom"?  And what is the community
of "implementors" that should enjoy this freedom?

"The implementors" are not a separate breed from Emacs users.
We are in this together.

("The educator himself must be educated." - Theses on Feuerbach)

> > My suggestion is to first revert the code change and then
> > discuss what the bug is that it was intended to fix.  If
> > there is really a bug that needs fixing, then let's please
> > try to find some other, non-shotgun fix for it.
> 
> Again, please stay on the level of required behavior, and
> leave the implementation out of this discussion.

Something wrong with discussing implementation among
"implementors"?  Among users too?  Not at all.

> As long as there's no evidence that the new implementation
                     ^^^^^^^^^^^
> cannot possibly accommodate the required behavior, the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> implementation can stay.

Setting the bar a bit high, aren't you?

Balderdash.  As long as there is no evidence that the _old_
implementation "cannot possibly accommodate" other changes that
fix the bug, the old implementation can stay.

You are being simplistic here.  The new implementation is not
the One Tried & True that cannot be questioned.  It is not
arguments against the new implementation that need to be proved
beyond a reasonable doubt.  That's backwards.

What should be demonstrated is why we should choose a new
region implementation.  This change has not even been released
yet - why on Earth put up a wall of "as long as there is no
evidence that it cannot possibly accommodate"?  As if it were
enshrined in unquestionable tradition.

It's bad enough to defend a longstanding and proven status quo
dogmatically.  It's downright ridiculous to do so for a change
that is only a few days old and has not yet seen the Light of
User Day.

Is there even any "evidence" that there was a bug to be fixed?
Again, can you say what the bug is, clearly and not referring
to implementation?

IOW:

  This is the _requirement_, in terms of behavior: _____

  And this is why it is better to fix the remaining problems
  caused by the recent "fix" than it is to start over with a
  different fix: _______