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: Mon, 12 Nov 2012 14:17:38 -0800

> > > Would it be good enough to redisplay whenever point moves, and let
> > > your code you run from :eval decide whether the text on 
> > > the mode line needs to be changed?  I think this will be a more
> > > general solution.
> > 
> > Yes, it would be good enough.
> > 
> > But the advantage that I'm supposing %l has is that the 
> > line-counting is done in C, as part of the display engine.
> 
> What do you need the line number for, in your code?

Sorry, I misspoke.  I didn't mean line-counting, I meant determining whether the
current line has changed.  I don't need the line number.

> You are aware that under certain conditions, the mode line can
> be redisplayed although point didn't move at all?

Yes, of course.

> > If my code had to check whether the line has changed then 
> > it would do that in Lisp.  Not saying that's a big deal.
> > But it still looks to me like the %l triggering is convenient.
> 
> Yes, but you want to be independent of it, i.e. even when %l is not in
> the mode line format.

Yes, that was my suggestion: separate (a) triggering mode-line redisplay upon
current-line change from (b) what to display in that case.  %l ties the two
together, displaying the current line number when the line # changes.
 
> > Perhaps the option could handle both cases: the general 
> > point-change case and the more particular line-change case,
> > depending on the option value?
> 
> We could do that, yes.
> 
> > BTW, why would this be a user option, rather than just a 
> > variable that code can bind?  The use case for users is not
> > too clear to me.
> 
> Yes, a variable sounds better.
> 
> > Anyway, I don't have much to say about what should be done 
> > for this enhancement.
> 
> Some wizardry with flags that control which redisplay optimizations
> can be used.

Sounds good.


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.

They would be in addition to the existing %-constructs that either (a) simply
provide particular data and format it or (b) combine such data+formatting with a
triggering condition.

An example of (a) is %b.  An example of (b) is %l (it displays the line number
and triggers redisplay when the line # changes).

An example of what I'm suggesting would be to add, say, %d for triggering
redisplay whenever point changes and, say, %L for triggering redisplay whenever
the current line changes.  (Just picked %d and %L arbitrarily.)

With the addition of such redisplay-triggering %-constructs, type (b)
combinations would no longer be strictly needed, but could be kept for
convenience and compatibility.

If more than one triggering %-construct applied at any time, they would each be
used.  E.g., if we had a construct that triggered redisplay when the buffer size
changed (just to give an example), say %B, then if the mode line contained both
%B and %L then its redisplay would be triggered whenever the current line
changed and whenever the buffer size changed.

Just throwing this out.  No idea whether it makes any sense at all.  If it makes
no or little sense, no need to point out particulars of why (unless you want
to), - I trust your judgment on that.







reply via email to

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