* bug#11756: 24.1.50; mode-line string and properties
@ 2012-06-21 0:27 Drew Adams
2012-06-21 1:20 ` Michael Heerdegen
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2012-06-21 0:27 UTC (permalink / raw)
To: 11756
Consider this snippet from Dired+:
(setq mode-name
`(,(format "Dired/%s"
(match-string 2 mode-name))
(:eval (let* ((dired-marker-char
(if (eq ?D dired-marker-char)
?* ; `dired-do-flagged-delete' binds it.
dired-marker-char))
(marked-regexp (dired-marker-regexp))
(nb-marked
(count-matches marked-regexp (point-min) (point-max))))
(if (not (> nb-marked 0))
""
(propertize
(format
" %s%d%c"
(save-excursion
(forward-line 0)
(if (looking-at (concat marked-regexp ".*"))
(format "%d/" (1+ (count-matches
marked-regexp (point-min)
(point))))
""))
nb-marked dired-marker-char)
'face 'diredp-mode-line-marked))))
(:eval (let* ((flagged-regexp (let ((dired-marker-char
dired-del-marker))
(dired-marker-regexp)))
(nb-flagged (count-matches
flagged-regexp (point-min)
(point-max))))
(if (not (> nb-flagged 0))
""
(propertize
(format " %s%dD"
(save-excursion
(forward-line 0)
(if (looking-at (concat flagged-regexp ".*"))
(format "%d/" (1+ (count-matches
flagged-regexp
(point-min) (point))))
""))
nb-flagged)
'face 'diredp-mode-line-flagged))))))
Here we set `mode-name' to a list of three items: a string and
two :eval constructs that each evaluate to a string.
The result in the mode line is that what _should_ act as a single unit,
the `mode-name', ends up acting like 3 separate units, duplicates
except for their strings: same mouseover tooltip, same popup menus.
This is not good.
What's the alternative? I tried using just one :eval construct that
produces a single string of the concatenated substrings. That solves
the problem just mentioned, but introduces a worse problem: The
propertized portions of the string are ignored.
Or if you use two constructs: the first string from above and a single
:eval that concatenates the other two strings, then you get two
mode-line units (two popups etc.) (so the first problem isn't really
solved), and the face of the last string is ignored - the face of the
middle string is used for the whole second unit.
In sum, we should be able to use a propertized string as the value of
something like `mode-name', and have different portions of the string be
propertized with different faces. You can define it that way, but what
you see in the code is not what you get in the mode line.
In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
of 2012-06-18 on MARVIN
Bzr revision: 108646 michael.albinus@gmx.de-20120617185439-jfcgwwbr97nbflkz
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --no-opt --enable-checking --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include
-ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
-ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11756: 24.1.50; mode-line string and properties
2012-06-21 0:27 bug#11756: 24.1.50; mode-line string and properties Drew Adams
@ 2012-06-21 1:20 ` Michael Heerdegen
2012-06-21 7:24 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Michael Heerdegen @ 2012-06-21 1:20 UTC (permalink / raw)
To: 11756
Hi,
to see with a short recipe that there is something wrong, try this in
emacs -Q:
(setq A-red_B-C
'(:eval (concat "A" (propertize "B" 'face 'font-lock-warning-face) "C"))
red_B
'(:eval (propertize "B" 'face 'font-lock-warning-face)))
(setq mode-name red_B) ;; works
(setq mode-name A-red_B-C) ;; doesn't work
(setq mode-line-format A-red_B-C) ;; works
Michael.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11756: 24.1.50; mode-line string and properties
2012-06-21 1:20 ` Michael Heerdegen
@ 2012-06-21 7:24 ` Andreas Schwab
2012-06-21 14:01 ` Drew Adams
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2012-06-21 7:24 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 11756
Michael Heerdegen <michael_heerdegen@web.de> writes:
> to see with a short recipe that there is something wrong, try this in
> emacs -Q:
>
> (setq A-red_B-C
> '(:eval (concat "A" (propertize "B" 'face 'font-lock-warning-face) "C"))
The property merging done by display_mode_element is very simple-minded.
Only the properties on the first character are used, and it is assumed
that they are placed over the whole string.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11756: 24.1.50; mode-line string and properties
2012-06-21 7:24 ` Andreas Schwab
@ 2012-06-21 14:01 ` Drew Adams
2021-08-23 15:00 ` Lars Ingebrigtsen
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2012-06-21 14:01 UTC (permalink / raw)
To: 'Andreas Schwab', 'Michael Heerdegen'; +Cc: 11756
> > to see with a short recipe that there is something wrong,
> > try this in emacs -Q:
> >
> > (setq A-red_B-C
> > '(:eval (concat "A" (propertize "B" 'face
> > 'font-lock-warning-face) "C"))
>
> The property merging done by display_mode_element is very
> simple-minded. Only the properties on the first character
> are used, and it is assumed that they are placed over the
> whole string.
So I guess that's what needs to be fixed then.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11756: 24.1.50; mode-line string and properties
2012-06-21 14:01 ` Drew Adams
@ 2021-08-23 15:00 ` Lars Ingebrigtsen
0 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-23 15:00 UTC (permalink / raw)
To: Drew Adams; +Cc: 'Michael Heerdegen', 11756, 'Andreas Schwab'
"Drew Adams" <drew.adams@oracle.com> writes:
>> The property merging done by display_mode_element is very
>> simple-minded. Only the properties on the first character
>> are used, and it is assumed that they are placed over the
>> whole string.
>
> So I guess that's what needs to be fixed then.
This wasn't documented before, but it's been made explicit recentlyish.
The reason for this is because we want to the mode lines to be very fast
(and create as little garbage as possible).
If you want to have different text properties over stretches of a
string, you have to chop the string up and use the :propertize mode line
construct.
So I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-08-23 15:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-21 0:27 bug#11756: 24.1.50; mode-line string and properties Drew Adams
2012-06-21 1:20 ` Michael Heerdegen
2012-06-21 7:24 ` Andreas Schwab
2012-06-21 14:01 ` Drew Adams
2021-08-23 15:00 ` Lars Ingebrigtsen
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).