GNU bug report logs - #20592
the `display' property messes the `face' properties after `concat'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20592 in the body.
You can then email your comments to 20592 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexander Shukaev <haroogan <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: the `display' property messes the `face' properties after `concat'
Date: Sun, 17 May 2015 01:58:29 +0200

[Message part 1 (text/plain, inline)]

Following the "Minibuffer tray to display current time and date"
discussion, it seems that a bug with the `display' property.  Consider the
following code:

  (setq-default minibuffer-line-format
                '((:eval (propertize (format-time-string "%Y.%m.%d")
                                     'face
                                     'minibuffer-line-date))
                  " "
                  (:eval (propertize (format-time-string "%A")
                                     'face
                                     'minibuffer-line-weekday))
                  " "
                  (:eval (propertize (format-time-string "%R")
                                     'face
                                     'minibuffer-line-time))))

It works as expected.

Consider another piece of code:

  (setq-default minibuffer-line-format
                `((:eval
                   (let ((string (concat
                                  (propertize (format-time-string
"%Y.%m.%d")
                                              'face
                                              'minibuffer-line-date)
                                  " "
                                  (propertize (format-time-string "%A")
                                              'face
                                              'minibuffer-line-weekday)
                                  " "
                                  (propertize (format-time-string "%R")
                                              'face
                                              'minibuffer-line-time))))
                     (concat (propertize " "
                                         'display
                                         `((space :align-to
                                                  (- right
                                                     right-fringe
                                                     ,(length string)))))
                             string)))))

Alignment works as expected, but faces are messed up.  In fact, the default
face is used everywhere (which comes from the `display' property), like if
subsequent propertizings of date, weekday, and time have never been there.

[Message part 2 (text/html, inline)]

Message #8 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Shukaev <haroogan <at> gmail.com>
Cc: 20592 <at> debbugs.gnu.org
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after	`concat'
Date: Sun, 17 May 2015 17:39:12 +0300

> Date: Sun, 17 May 2015 01:58:29 +0200
> From: Alexander Shukaev <haroogan <at> gmail.com>
> 
> Consider another piece of code:
> 
> (setq-default minibuffer-line-format
> 	      `((:eval
> 		 (let ((string (concat
> 				(propertize (format-time-string "%Y.%m.%d")
> 					    'face
> 					    'minibuffer-line-date)
> 				" "
> 				(propertize (format-time-string "%A")
> 					    'face
> 					    'minibuffer-line-weekday)
> 				" "
> 				(propertize (format-time-string "%R")
> 					    'face
> 					    'minibuffer-line-time))))
> 		   (concat (propertize " "
> 				       'display
> 				       `((space :align-to
> 						(- right
> 						   right-fringe
> 						   ,(length string)))))
> 			   string)))))

> Alignment works as expected, but faces are messed up.  In fact, the default face is used everywhere (which comes from the `display' property), like if subsequent propertizings of date, weekday, and time have never been there.

(To complete the bug report, the 3 minibuffer-line-* faces need to be
defined, and the minibuffer-line package from ELPA loaded and then
minibuffer-line-mode turned on.)

The behavior you observe is because the ':eval' construct expects to
produce a single string with either the same common face spec on all
of its characters, or no faces at all.  You cannot use ':eval' to
produce a string that has more than one face spec on its different
characters; if you do, only the face spec of the first character of
the string will be honored.

'minibuffer-line-mode' is implemented via the function
'format-mode-line'.  While I can understand this design decision, the
downside is that you get to face some of the idiosyncrasies of
formatting the mode line.  (E.g., did you ask yourself why you get an
extra column of white space after the string?)

The upshot of this is that you need to generate each substring that
has a unique face with its own ':eval'.  For example, the following
abomination works as you expect:

  (setq-default minibuffer-line-format
		'((:eval
		   (propertize " "
			       'display
			       `((space :align-to
					(- right
					   right-fringe
					   ,(length
					     (concat
					      (format-time-string "%Y.%m.%d")
					      " "
					      (format-time-string "%A")
					      " "
					      (format-time-string "%R"))))))))
		  (:eval (propertize (format-time-string "%Y.%m.%d")
				     'face
				     'minibuffer-line-date))
		  " "
		  (:eval (propertize (format-time-string "%A")
				     'face
				     'minibuffer-line-weekday))
		  " "
		  (:eval (propertize (format-time-string "%R")
				     'face
				     'minibuffer-line-time))))

Message #11 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20592 <at> debbugs.gnu.org, Alexander Shukaev <haroogan <at> gmail.com>
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after	`concat'
Date: Mon, 18 May 2015 21:20:05 -0400

> The behavior you observe is because the ':eval' construct expects to
> produce a single string with either the same common face spec on all
> of its characters, or no faces at all.  You cannot use ':eval' to
> produce a string that has more than one face spec on its different
> characters; if you do, only the face spec of the first character of
> the string will be honored.

IIUC, this is the bug that needs to be fixed.
Or is there a reason to consider this as a feature?


        Stefan

Message #14 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20592 <at> debbugs.gnu.org, haroogan <at> gmail.com
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after	`concat'
Date: Tue, 19 May 2015 18:31:23 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Alexander Shukaev <haroogan <at> gmail.com>,  20592 <at> debbugs.gnu.org
> Date: Mon, 18 May 2015 21:20:05 -0400
> 
> > The behavior you observe is because the ':eval' construct expects to
> > produce a single string with either the same common face spec on all
> > of its characters, or no faces at all.  You cannot use ':eval' to
> > produce a string that has more than one face spec on its different
> > characters; if you do, only the face spec of the first character of
> > the string will be honored.
> 
> IIUC, this is the bug that needs to be fixed.
> Or is there a reason to consider this as a feature?

I think the reason for this implementation was to keep the code simple
and efficient.  After all, ':eval' is part of the standard mode line,
in several places, so this code runs each time we update the mode
line, which we do a lot.

I agree that the limitation is counter-intuitive, and barely
documented, but given that using a separate ':eval' is such an easy
solution, perhaps we should simply document this.  Fixing this doesn't
sound as high priority to me.

Message #17 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Alexander Shukaev <haroogan <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20592 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after `concat'
Date: Thu, 25 Jun 2015 21:16:41 +0200

[Message part 1 (text/plain, inline)]

Not sure how this complies with what Eli said:

The behavior you observe is because the ':eval' construct expects to
> produce a single string with either the same common face spec on all
> of its characters, or no faces at all.  You cannot use ':eval' to
> produce a string that has more than one face spec on its different
> characters; if you do, only the face spec of the first character of
> the string will be honored.


but I've still managed to work it out in the following way:

  (setq-default minibuffer-line-format
                '((:eval
                   (let* ((date-string
                           (propertize (format-time-string "%Y.%m.%d")
                                       'face
                                       'minibuffer-line-date))
                          (weekday-string
                           (propertize (format-time-string "%A")
                                       'face
                                       'minibuffer-line-weekday))
                          (time-string
                           (propertize (format-time-string "%R")
                                       'face
                                       'minibuffer-line-time))
                          (right-string-list
                           (list date-string
                                 " "
                                 weekday-string
                                 " "
                                 time-string))
                          (right-string
                           (apply #'concat right-string-list))
                          (pad-string
                           (propertize " "
                                       'display
                                       `((space :align-to
                                                (- right
                                                   right-fringe
                                                   ,(length
right-string)))))))
                     (list pad-string
                           right-string-list)))))

[Message part 2 (text/html, inline)]

Message #20 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Shukaev <haroogan <at> gmail.com>
Cc: 20592 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after `concat'
Date: Thu, 25 Jun 2015 22:42:15 +0300

> Date: Thu, 25 Jun 2015 21:16:41 +0200
> From: Alexander Shukaev <haroogan <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 20592 <at> debbugs.gnu.org
> 
> Not sure how this complies with what Eli said:
> 
>     The behavior you observe is because the ':eval' construct expects to
>     produce a single string with either the same common face spec on all
>     of its characters, or no faces at all. You cannot use ':eval' to
>     produce a string that has more than one face spec on its different
>     characters; if you do, only the face spec of the first character of
>     the string will be honored.
> 
> but I've still managed to work it out in the following way:

It does comply, AFAIU: you produced a list, not a string.  Each string
in the list still needs to have a single face on all of its
characters.

Message #23 received at 20592 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20592 <at> debbugs.gnu.org, Alexander Shukaev <haroogan <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#20592: the `display' property messes the `face' properties
 after `concat'
Date: Thu, 02 Dec 2021 11:00:54 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> It does comply, AFAIU: you produced a list, not a string.  Each string
> in the list still needs to have a single face on all of its
> characters.

So I don't think there's anything to fix here -- the text property
limitation on mode line strings wasn't documented before, but it's
documented in Emacs 28.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.