unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 12872@debbugs.gnu.org
Subject: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Mon, 12 Nov 2012 14:17:38 -0800	[thread overview]
Message-ID: <B412B48440D7470ABD5C394A8CF8CEED@us.oracle.com> (raw)
In-Reply-To: <831ufywqnh.fsf@gnu.org>

> > > 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	other threads:[~2012-11-12 22:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-12 18:27 bug#12872: 24.2; Provide a feature to trigger mode-line redisplay Eli Zaretskii
2012-11-12 19:46 ` Eli Zaretskii
2012-11-12 22:17   ` Drew Adams [this message]
2012-11-13  3:57     ` Eli Zaretskii
2012-11-13 15:38       ` Drew Adams
2021-12-04  4:46 ` Lars Ingebrigtsen
2021-12-04  7:54   ` Eli Zaretskii
2021-12-04 18:55     ` Lars Ingebrigtsen
2021-12-04 19:26       ` Eli Zaretskii
2021-12-04 19:40         ` Lars Ingebrigtsen
2021-12-04 19:43           ` Eli Zaretskii
2021-12-04 22:04             ` Lars Ingebrigtsen
2021-12-05  7:02               ` Eli Zaretskii
2021-12-05 20:05                 ` Lars Ingebrigtsen
2021-12-05 20:14                   ` Eli Zaretskii
2021-12-06  6:00                     ` Lars Ingebrigtsen
2021-12-06 13:02                       ` Eli Zaretskii
2021-12-07 20:49                         ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B412B48440D7470ABD5C394A8CF8CEED@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=12872@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).