[Top][All Lists]

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

RE: Overlay before-string property

From: Drew Adams
Subject: RE: Overlay before-string property
Date: Sat, 30 Sep 2006 23:26:20 -0700

    > 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

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.

reply via email to

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