[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9642: move-overlay creates an empty overlay with the evaporate prope
From: |
Paul Eggert |
Subject: |
bug#9642: move-overlay creates an empty overlay with the evaporate property |
Date: |
Sat, 01 Oct 2011 22:38:24 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 |
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. For example,
(make-overlay 0 (1+ (point-max)))
is treated exactly as if it were
(make-overlay 1 (point-max))
This is almost always true for move-overlay, too: for example,
in a nonempty buffer:
(move-overlay foo 0 (1+ (point-max)))
is exactly equivalent to
(move-overlay foo 1 (point-max))
This behavior is a longstanding Emacs tradition, in many functions,
e.g., (goto-char 0) is exactly equivalent to (goto-char 1).
I suppose it might make sense for the overlay code to consistently treat
out-of-range values as errors, and throw exceptions instead.
But what doesn't make sense is for the overlay behavior to be inconsistent,
where all the primitives follow goto-char's lead
except that in some (but not all) cases move-overlay screws up
and silently returns a bogus zero-length evaporating overlay.