Overlay before-string property

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)))

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?

Re: Overlay before-string property

[Stefan Monnier]

> 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)

Put the face property on the before-string string.


        Stefan

RE: Overlay before-string property

[Drew Adams]

    > 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)

    Put the face property on the before-string string.

OK, that makes sense (and it works). Thanks.

However, I'd like to be able to just use the existing code as is, without
redefining it. That is, I'd prefer to do something simple after loading the
file minibuf-depth.el, rather than rewriting part of it.

Can you explain what is going on here, so I can understand it? Is this a
quality of the `before-string' property, in general, or does it result from
something else?

And should Miles' code (presumably to be added to Emacs after the release)
not result in this stickiness, or is it intended (does it have some
benefit)?

Re: Overlay before-string property

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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.

Re: Overlay before-string property

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>     > 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.

It is related to stickiness, but your description indeed made me do a
wrong guess.  This has nothing to do with stickiness, it simply has to
do with the overlay _covering_ the character in question.  Use
(make-overlay (point-min) (point-min))
instead.  It may be necessary to ise the 'display instead of the
'before-string property for this to work; I don't remember the
details.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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.

    It is related to stickiness, but your description indeed made me do a
    wrong guess.  This has nothing to do with stickiness, it simply has to
    do with the overlay _covering_ the character in question.  Use
    (make-overlay (point-min) (point-min))
    instead.  It may be necessary to ise the 'display instead of the
    'before-string property for this to work; I don't remember the
    details.

OK, so it seems that is another way to change Miles's code to not get the
face bleeding (or overlay covering or whatever you want to call it, since it
is apparently not stickiness).

The questions I posed are these:

1) Should such a change be made to the Emacs code (Miles's code, which is
likely to be added to Emacs), to prevent this face bleeding? Or is there a
good reason why it is written that way?

2) If that code should remain as it is, is there another way to get the
effect I want (no bleeding), without changing the function definition? IOW,
how can a user prevent the bleeding, without rewriting the function (either
as you suggested or as Stefan suggested)?

Re: Overlay before-string property

[martin rudalics]

> 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?

I listed a number of problems with these but I don't know whether they
are still virulent, compare:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00176.html

RE: Overlay before-string property

[Drew Adams]

    > 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?

    I listed a number of problems with these but I don't know whether they
    are still virulent, compare:

    http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg0
    0176.html

Very good; thanks, Martin. Perhaps some of that info should be added to the
doc, assuming that the behavior will not be changed.

Reading that, and having heard nothing back about why the minibuf-depth.el
code should do what it does in this regard, I'm getting the impression that
the code should be modified not to let the face-bleed occur.

If others agree, then the question would be, what face should be used for
the minibuffer-depth overlay? Choices include: 1) default face, 2) same face
as the text that follows (current approach), or 3) some other face. #1 and
#3 would be OK by me. For #3, there is the further choice of reusing an
existing face or adding a new one.

Re: Overlay before-string property

[Richard Stallman]

    I listed a number of problems with these but I don't know whether they
    are still virulent, compare:

    http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00176.html

Could you see if any of these bugs is still present?

Re: Overlay before-string property

[martin rudalics]

> Could you see if any of these bugs is still present?

I can't reproduce the redisplay related bugs mentioned there,
likely Kim has fixed them in the meantime. :-)

I'll resubmit a list of the remaining bugs after the release.