* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
@ 2021-01-29 17:58 Clemens
2021-01-29 18:37 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clemens @ 2021-01-29 17:58 UTC (permalink / raw)
To: 46177
When using an overlay with an `after-string` which uses `display`
the prompt background bleeds into the after string:
(set-face-attribute 'minibuffer-prompt nil :background "purple")
(minibuffer-with-setup-hook
(lambda ()
(overlay-put
(make-overlay (point-max) (point-max) nil t t)
'after-string (propertize " world"
'display
" minibuffer")))
(read-string "Hello"))
While I would expect it to be displayed like when using:
(minibuffer-with-setup-hook
(lambda ()
(overlay-put
(make-overlay (point-max) (point-max) nil t t)
'after-string " minibuffer"))
(read-string "Hello"))
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-29 17:58 bug#46177: 27.1; Display problem with minibuffer overlay when using display property Clemens
@ 2021-01-29 18:37 ` Eli Zaretskii
2021-01-29 20:26 ` Clemens
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-01-29 18:37 UTC (permalink / raw)
To: Clemens; +Cc: 46177
> From: Clemens <clemens.radermacher@posteo.de>
> Date: Fri, 29 Jan 2021 18:58:46 +0100
>
> When using an overlay with an `after-string` which uses `display`
> the prompt background bleeds into the after string:
That's a feature: Emacs treats display strings and overlay strings
differently for the purposes of face merging.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-29 18:37 ` Eli Zaretskii
@ 2021-01-29 20:26 ` Clemens
2021-01-30 8:26 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clemens @ 2021-01-29 20:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 46177
> That's a feature: Emacs treats display strings and overlay strings
> differently for the purposes of face merging.
Okay, thanks. I have a problem with this when displaying completion
candidates in the minibuffer. The candidates are displayed via
`after-string` overlay. The candidates are provided by the caller and
can contain the `display` property. Right now I "inline" any parts of
the string that use `display` to avoid this:
(defun selectrum--display-string (str)
"Return display string of STR."
(let ((len (length str))
(display "")
(start 0)
(end 0))
(while (not (eq len end))
(setq end (next-single-property-change start 'display str len))
(let ((val (get-text-property start 'display str)))
(if (and val (stringp val))
(setq display (concat display val))
(setq display (concat display (substring str start end)))))
(setq start end))
display))
Is there a better way?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-29 20:26 ` Clemens
@ 2021-01-30 8:26 ` Eli Zaretskii
2021-01-30 9:30 ` Clemens
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-01-30 8:26 UTC (permalink / raw)
To: Clemens; +Cc: 46177
> Cc: 46177@debbugs.gnu.org
> From: Clemens <clemens.radermacher@posteo.de>
> Date: Fri, 29 Jan 2021 21:26:26 +0100
>
> > That's a feature: Emacs treats display strings and overlay strings
> > differently for the purposes of face merging.
>
> Okay, thanks. I have a problem with this when displaying completion
> candidates in the minibuffer. The candidates are displayed via
> `after-string` overlay. The candidates are provided by the caller and
> can contain the `display` property. Right now I "inline" any parts of
> the string that use `display` to avoid this:
>
>
> (defun selectrum--display-string (str)
> "Return display string of STR."
> (let ((len (length str))
> (display "")
> (start 0)
> (end 0))
> (while (not (eq len end))
> (setq end (next-single-property-change start 'display str len))
> (let ((val (get-text-property start 'display str)))
> (if (and val (stringp val))
> (setq display (concat display val))
> (setq display (concat display (substring str start end)))))
> (setq start end))
> display))
>
>
> Is there a better way?
Better in what sense?
If you mean a way that prevents the background of the prompt from
being applied to the text you display via the overlay, I think the
best/only way is for the overlay string or display string to specify
the background color.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-30 8:26 ` Eli Zaretskii
@ 2021-01-30 9:30 ` Clemens
2021-01-30 10:46 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clemens @ 2021-01-30 9:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 46177
> Better in what sense?
>
> If you mean a way that prevents the background of the prompt from
> being applied to the text you display via the overlay, I think the
> best/only way is for the overlay string or display string to specify
> the background color.
Yes, I meant to avoid the issue that the minibuffer prompt face gets
applied to strings defined in the display property. The code I posted
simply removes any strings in the display spec and inlines them, which
seems to work well, too. The problem is not only the background color it
seems, I would need to completely undo the effects of the minibuffer
prompt face and I don't know how to do that. But what I'm doing now
works and if there isn't a better solution I'm fine with using it.
I don't understand the reasons for the current behaviour but please
check out the following which seems not appropriate to me:
(set-face-attribute 'minibuffer-prompt nil :foreground "purple")
(minibuffer-with-setup-hook
(lambda ()
(overlay-put
(make-overlay (point-max) (point-max) nil t t)
'after-string
(concat " from"
(propertize " world"
'display
" minibuffer"))))
(read-string "Hello"))
Even with the " from" string between the string defined in the display
property gets the prompt face applied.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-30 9:30 ` Clemens
@ 2021-01-30 10:46 ` Eli Zaretskii
2021-01-30 11:09 ` Clemens
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-01-30 10:46 UTC (permalink / raw)
To: Clemens; +Cc: 46177
> Cc: 46177@debbugs.gnu.org
> From: Clemens <clemens.radermacher@posteo.de>
> Date: Sat, 30 Jan 2021 10:30:21 +0100
>
> The problem is not only the background color it seems, I would need
> to completely undo the effects of the minibuffer prompt face and I
> don't know how to do that.
Use a face which explicitly overrides every attribute of minibuffer
prompt face, I guess?
> (set-face-attribute 'minibuffer-prompt nil :foreground "purple")
> (minibuffer-with-setup-hook
> (lambda ()
> (overlay-put
> (make-overlay (point-max) (point-max) nil t t)
> 'after-string
> (concat " from"
> (propertize " world"
> 'display
> " minibuffer"))))
> (read-string "Hello"))
>
>
> Even with the " from" string between the string defined in the display
> property gets the prompt face applied.
Because " minibuffer" is a display string, and its buffer position is
still EOB. That it has the " from " string in the overlay property
before it doesn't change the buffer position whose face affects the
display string.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-30 10:46 ` Eli Zaretskii
@ 2021-01-30 11:09 ` Clemens
2021-01-30 12:06 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clemens @ 2021-01-30 11:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 46177
> Use a face which explicitly overrides every attribute of minibuffer
> prompt face, I guess?
As far as I understand I would have to loop through the overlay string,
too and apply those face adjustments to every of those display property
strings. I think then I can also just inline them like in my shown
example which avoid this issue in the first place.
>
>> (set-face-attribute 'minibuffer-prompt nil :foreground "purple")
>> (minibuffer-with-setup-hook
>> (lambda ()
>> (overlay-put
>> (make-overlay (point-max) (point-max) nil t t)
>> 'after-string
>> (concat " from"
>> (propertize " world"
>> 'display
>> " minibuffer"))))
>> (read-string "Hello"))
>>
>>
>> Even with the " from" string between the string defined in the display
>> property gets the prompt face applied.
>
> Because " minibuffer" is a display string, and its buffer position is
> still EOB. That it has the " from " string in the overlay property
> before it doesn't change the buffer position whose face affects the
> display string.
Because the " minibuffer" string follows the non affected " from" string
this is unexpected from a caller/UI viewpoint IMO. I don't understand
the underlying reasoning for this but if you don't think there is
something to fix here, I will accept that and continue using my workaround.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-30 11:09 ` Clemens
@ 2021-01-30 12:06 ` Eli Zaretskii
2021-01-30 12:10 ` Clemens
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2021-01-30 12:06 UTC (permalink / raw)
To: Clemens; +Cc: 46177
> Cc: 46177@debbugs.gnu.org
> From: Clemens <clemens.radermacher@posteo.de>
> Date: Sat, 30 Jan 2021 12:09:57 +0100
>
> Because the " minibuffer" string follows the non affected " from" string
> this is unexpected from a caller/UI viewpoint IMO.
Once Emacs is about to display a 'display' property string, the rules
for which faces are relevant change.
> I don't understand the underlying reasoning for this but if you
> don't think there is something to fix here, I will accept that and
> continue using my workaround.
It's just how Emacs worked since v21, so I think it's too late to
change now.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#46177: 27.1; Display problem with minibuffer overlay when using display property
2021-01-30 12:06 ` Eli Zaretskii
@ 2021-01-30 12:10 ` Clemens
0 siblings, 0 replies; 9+ messages in thread
From: Clemens @ 2021-01-30 12:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 46177-done
> It's just how Emacs worked since v21, so I think it's too late to
> change now.
I see, thanks for your discussion and help, I will close this then.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-01-30 12:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-29 17:58 bug#46177: 27.1; Display problem with minibuffer overlay when using display property Clemens
2021-01-29 18:37 ` Eli Zaretskii
2021-01-29 20:26 ` Clemens
2021-01-30 8:26 ` Eli Zaretskii
2021-01-30 9:30 ` Clemens
2021-01-30 10:46 ` Eli Zaretskii
2021-01-30 11:09 ` Clemens
2021-01-30 12:06 ` Eli Zaretskii
2021-01-30 12:10 ` Clemens
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).