martin rudalics <[EMAIL PROTECTED]> writes:
> However, the author of the fix forgot to handle the case of _two_ empty
> overlays at the same position where one has a before- and the other an
> after-string. Patching this would not break any existing code.
> `compare_overlay_entries' would simply have to consider the length of
> the overlays it has to compare. Invisible overlays are - unofficially -
> handled like empty overlays; according to `xdisp.c' their start and end
> positions are "indistinguishable". I believe their before- and
> after-strings are nevertheless sorted based on the actual length of the
> overlay. In any case, it might make sense to check this.
Can you suggest a patch for this?
>
> > Worse, the following paragraph seems to indicate that the priority is
> > not about ordering multiple after- and before-strings, but selecting
> > just ONE before- and/or after-string to show.
> >
> > @kindex priority @r{(overlay property)}
> > This property's value (which should be a nonnegative integer number)
> > determines the priority of the overlay. The priority matters when two
> > or more overlays cover the same character and both specify the same
> > property; the one whose @code{priority} value is larger takes priority
> > over the other. For the @code{face} property, the higher priority
> > value does not completely replace the other; instead, its face
> > attributes override the face attributes of the lower priority
> > @code{face} property.
> >
>
> I'd say that _all_ before- and after-strings are shown (at least once).
So the lispref is wrong.
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
