[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).
- Re: before- and after-string issues, (continued)
- Re: before- and after-string issues, Kim F. Storm, 2005/05/16
- Re: before- and after-string issues, Richard Stallman, 2005/05/18
- Re: before- and after-string issues, martin rudalics, 2005/05/18
- Re: before- and after-string issues, Kim F. Storm, 2005/05/18
- Re: before- and after-string issues, Richard Stallman, 2005/05/18
- Re: before- and after-string issues, martin rudalics, 2005/05/19
- Re: before- and after-string issues, Richard Stallman, 2005/05/20
- Re: before- and after-string issues, martin rudalics, 2005/05/23
- Re: before- and after-string issues, Richard Stallman, 2005/05/24
Re: before- and after-string issues,
martin rudalics <=