RE: Overlay before-string property

[Drew Adams]

    > I use this, from Miles Bader's minibuf-depth.el (or whatever
    > it's called now):
    >
    > ;; This function goes on minibuffer-setup-hook
    > (defun minibuf-depth-setup-minibuffer ()
    >   "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
    > The prompt should already have been inserted."
    >   (when (> (minibuffer-depth) 1)
    >     (setq minibuf-depth-overlay
    >           (make-overlay (point-min) (1+ (point-min))))
    >     (overlay-put minibuf-depth-overlay 'before-string
    >                (format "%d) " (minibuffer-depth)))
    >     (overlay-put minibuf-depth-overlay 'evaporate t)))
    >
    > Does this have something to do with text-property stickiness? I have
    > not knowingly changed any sticky properties, and the manual seems to
    > say that text is, by default, only rear sticky. The behavior seems
    > to be as if the prompt-string text were front-sticky and the overlay
    > were rear-sticky, IIUC.

    You could read the DOC string of make-overlay.  It has optional
    arguments.

Thanks, but I don't see how that helps. Perhaps I'm misreading it or the
text has changed since July (my build), however. It speaks of FRONT-ADVANCE
and REAR-ADVANCE, but I don't see how that would be related to property
stickiness. The manual says about the same thing as the doc string.

Stefan provided a solution, but it requires rewriting the (soon-to-be)
standard function (Miles's code). I'd like to control this without rewriting
that function, if possible. I'd also like to understand what's happening,
and why (if intentional) it is written that way. (Or perhaps it should not
be written that way?) I don't understand it yet.