Re: Behavior of evaporate

[David Kastrup]

Masatake YAMATO <address@hidden> writes:

> > > > I was thinking of suggesting that but wasn't sure whether it'd work.
> > > > Does it ?  If it does, it's probably the simplest alternative, indeed.
> > > 
> > > `evaporate' doesn't work I expect. So I introduced suboverlays
> > > property to manage overlay deletion.
> > 
> > I'm not sure exactly what you're saying, but the overlay
> > `evaporate' feature definitely works (unless it's recently been
> > broken)...
> 
> (progn (setq xxx 1)
>        (setq o (make-overlay 0 0))
>        (overlay-put o 'modification-hooks (lambda (ov dummy b e l)
>                                           (setq xxx 0)))
>        (overlay-put o 'evaporate t)
>        xxx)
> => 1
> 
> Result I expected is 0.
> So I can know an overlay is dead.
> Do I misunderstand?

Yes.  From the manual:

`evaporate'
     If this property is non-`nil', the overlay is deleted automatically
     if it ever becomes empty (i.e., if it spans no characters).

But the overlay does not become empty in your example.  It _is_
already empty.

Setting the overlay borders explicitly is not what this property is
useful for catching.  It is there for the case that the overlay
becomes empty by side effect.  Try

(progn (setq xxx 1)
       (goto-char 1)
       (insert "x")
       (setq o (make-overlay 1 2))
       (overlay-put o 'modification-hooks (list (lambda (ov dummy b e
                                                   &optional l)
                                            (setq xxx 0))))
       (overlay-put o 'evaporate t)
       (delete-char 1)
       xxx)

And notice that modification-hooks takes a list of functions, not
just a single function.  And that the last argument of the function
is optional.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum