bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12872: 24.2; Provide a feature to trigger mode-line redisplay


From: Drew Adams
Subject: 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' ;-).]






reply via email to

[Prev in Thread] Current Thread [Next in Thread]