[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: before- and after-string issues

From: martin rudalics
Subject: Re: before- and after-string issues
Date: Wed, 18 May 2005 11:09:16 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> /* Compare two overlay_entry structures E1 and E2.  Used as a
>    comparison function for qsort in load_overlay_strings.  Overlay
>    strings for the same position are sorted so that
>    1. All after-strings come in front of before-strings, except
>    when they come from the same overlay.

> I don't know why it is this way, but changing this may break existing
> code.  And I cannot find anything in the lisp reference which document
> this behaviour.

It's this way because it was simple and efficient to code it this way.
And it works well for non-empty overlays: The after-string of an overlay
A located at a lower buffer-position than overlay B thus automatically
precedes any before-string of B.  This approach does not work when an
empty overlay has a before- and after-string - hence the "except ..."
in 1.  The fix has `compare_overlay_entries' simply check whether the
strings come from the same overlay.

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.

> 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]