emacs-devel
[Top][All Lists]
Advanced

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

Overlay before-string property


From: Drew Adams
Subject: Overlay before-string property
Date: Sat, 30 Sep 2006 18:20:13 -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)))

I also propertize the text used for the minibuffer prompt. I pass a
propertized prompt string to completing-read, and I remove the face property
from minibuffer-prompt-properties. That highlights particular parts of the
prompt the way I want.

Unfortunately, the depth-indicator overlay picks up the face used for the
first character of the prompt string. I don't want that - I want it to have
its own face (e.g. the default).

So, I tried adding this at the end of the above code:

    (overlay-put minibuf-depth-overlay 'face 'default)

However, that puts the default face on the entire prompt string, for some
reason. I want the depth overlay to appear in the default face (no
highlighting), and the prompt string to appear the way I propertized it.

Suggestions? Is there something else I need to do to the overlay, so it
doesn't either 1) pick up the face of the first prompt character or 2)
pollute the prompt with its own face?

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.

Does a before-string overlay perhaps automatically pick up the face of the
string it precedes, unless it has its own? Does it spread its own face, if
present, to the string it precedes? If so, is such behavior a bug? What's a
good way to deal with this?





reply via email to

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