Re: Strange problem with latest CVS

[peta]

Masatake YAMATO <address@hidden> wrote:
> Sorry to be late.
> 
> > >>>>> Matt Hodges writes:
> > 
> >  > > I think this is caused because the end of the buffer has this
> >  > > face, and VM reuses the buffer, clears it and fills it with the
> >  > > new message. Apparently the face is sticking with the empty
> >  > > buffer and is then inherited by the new text. Maybe this change
> >  > > is causing it:
> 
> >  > I think emacs-w3m hits the same problem. Overlays from 1 to 1 in
> >  > otherwise empty buffers span 1 to (point-max) after insertion of
> >  > text; previously (before the change you mention, I think) such
> >  > overlays still spanned 1 to 1 after insertion of text.
> > 
> > I think the same problem can be seen in Gnus (v5.10.6). If I do
> > gnus-summary-toggle-header, then an overlay including mouse-face
> > highlight spans all the headers.

I'd just like to add that mh-e also has this problem when displaying
mime buttons and parts.  It was fixed by setting the overlay 'evaporate
property to t.

Inserting at a zero length overlay is inherently ambiguous as to whether
the insertion is at the front or end the overlay.  The default behaviour
of (make-overlay) is different in these two cases -- at the front the
insertion will get the overlay properties while at the end it will not.

It looks like the modifications have changed the notion of whether
insertion is at the front or end of the overlay.  I dont know enough
about the original design specs to say if this new behaviour is right or
wrong.

In any case it seems like a change for the better.  Previously all the
gui-button faces would shrink to zero-length overlays and remain there,
invisible, when the buffer contents were deleted and new contents
inserted.  I now see that a lot of overlays accumulated after may reuses
of the same buffer.

> How do you think make evaporate overlay's property t by default(when
> make-overlay)?

On the face of it I think that overlays should evaporate by default.  I
can see that not evaporating is useful when an overlay in a region being
deleted completely spans that region (re-insertions take on the overlay
properties of the deletion), but it looks like the less frequent case.

What do the original designers of the overlay system say, and what will
it break if changed?

-- 
Peter Whaite (http://whaite.ca)