GNU bug report logs - #12872
24.2; Provide a feature to trigger mode-line redisplay

Previous Next

Full log

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: RE: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Tue, 13 Nov 2012 07:38:45 -0800

> > I wonder (without being very familiar with the mode-line 
> > %-constructs, so maybe speaking nonsense) whether it might be
> > useful to add specific %-constructs (or variables?) that say
> > when (i.e., in what contexts) to trigger mode-line redisplay.
> 
> What would be the advantages of such a feature?  Since the mode line
> format is not even consulted in order to decide whether or not to
> redisplay the mode line (because its processing is very non-trivial,
> what with all the propertize stuff and Lisp expressions going on there
> even in the standard value), we will need internal variables to shadow
> these constructs anyway.
> 
> Having variables or maybe a plist of the mode line format allows
> easier access to this information, and is IMO more Lispy than hiding
> the information in some % magic.

I agree that (local) variables make more sense than %-constructs.  That was part
of my suggestion.  I don't know much about how these things work.

Even from my point of view, ignoring what I didn't know, including the reasons
you gave, variables make more sense, because we are not replacing the
%-construct with anything, in context - IOW, the positions of the new
%-constructs in `mode-line-format' would be irrelevant.

Consider my suggestion to be just to have some easy way to specify mode-line
redisplay triggering conditions, so users can easily separate triggering from
the mode-line format/content.

So for the case that motivated this, you would be able to separate the two %l
effects: triggering and line-# content.

Having different variables (or plist keywords) to specify different triggering
contexts would be one way.

[Someone else might prefer that we come up with a single monster variable a la
`buffer-display-alist' ;-).]

Previous Next

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