Re: Empty Overlay with before-string or after-string property still treated as empty

[M Jared Finder]

martin rudalics wrote:
>  > If you an overlay has equal endpoints, and a before-string or 
> after-string property set, the face
>  > property does not affect the before-string or after-string.  I found 
> this while modifying hl-line to
>  > properly handle the last line in a buffer.
>
> I'd rather not use zero length overlays with before- and after-strings,
> compare the thread "before- and after-string issues" starting with:
>
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00176.html
>
> I found additional problems since that but forgot about most of them.

Which requires user code that uses a before string or after string to 
always set the text property in the string.  Uhg.  If you're going to do 
that, you could at least hack the overlay-put function to handle this 
transparently:

> (defconst overlay-string-props '(before-string after-string)) ;; any others?
>
> (defun my-overlay-put (overlay prop value)
>   "Replacement for `overlay-put' that handles overlay strings
> transparently"
>   (overlay-put overlay prop value)
>   (when (member prop (cons 'face overlay-string-props))
>     (let ((face (overlay-get overlay 'face)))
>       (dolist (string (mapcan (lambda (prop)
>                                 (let ((value (overlay-get overlay prop)))
>                                   (if value (list value) nil)))
>                               overlay-string-props))
>         (if face
>             (put-text-property 0 (length string) 'face face string)
>           (remove-text-properties 0 (length string) '(face nil) string))))))

It's hacky, but it works, and you could always properly fix it later on.

>  > P.S.  It would also be nice if hl-line-mode was changed to properly 
> handle the last line in a
>  > buffer. ;)
>
> Might be caused by redisplay, compare
>
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-01/msg00347.html
>
> although I'm not sure whether our problems are related.

I don't think so.  The bug happens regardless of where the overlay is 
and doesn't get fixed if I run recenter (which force a redisplay).

  -- MJF