bug#9642: move-overlay creates an empty overlay with the evaporate property

[Eli Zaretskii]

> Date: Sat, 01 Oct 2011 22:38:24 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: monnier@iro.umontreal.ca, 9642@debbugs.gnu.org
> 
> On 10/01/11 01:22, Eli Zaretskii wrote:
> > doing this invokes undefined behavior
> 
> No, everywhere else the overlay code consistently defines
> the behavior: out-of-range values are treated as if they were
> the nearest in-range values.

That is your interpretation of what Emacs does.  But this seemingly
"consistent" behavior is nothing more than one possible undefined
behavior.  That it looks to you "consistent" is just an accident.

> This behavior is a longstanding Emacs tradition

Sorry, but I submit that we should start treating these references to
"tradition" as bogus.  Upholding such "traditional" misbehavior causes
all kinds of unexpected quirks in the code that are very hard to
maintain and downright impossible to take into account when designing
significant changes.

IOW, an attempt to treat such undefined behavior consistently bears
grave maintenance costs and in fact stands in the way of any
significant progress, because it makes it impossible to produce
elegant and simple design of new features that is based on assumptions
such as "buffer positions are always between (point-min) and
(point-max)."  One thinks this must be the case and writes the code
based on that, and then the code crashes because some Lisp expected
zero to be "traditionally" treated as one.

That way lies madness.

I say we should fix any code that "traditionally" relies on any such
behavior, and stop heeding to requests of fixing undefined behavior.
There should be no need for any code to put an overlay starting at
position zero nor go to such a position, because these positions
simply do not exist.

> I suppose it might make sense for the overlay code to consistently treat
> out-of-range values as errors, and throw exceptions instead.

I didn't say we should throw errors.  Undefined behavior is just
that--you can expect anything.  Including treating 0 as 1 in some
cases, but not others.

> But what doesn't make sense is for the overlay behavior to be inconsistent

It is consistently undefined, from my POV.  And that is the only sense
I can possibly find in code which does this.