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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12872 in the body.
You can then email your comments to 12872 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2; Provide a feature to trigger mode-line redisplay
Date: Mon, 12 Nov 2012 20:27:49 +0200

This is a feature request: provide a way to trigger mode-line
redisplay when the current line changes.  This is so the mode line
could display information about the current line.

See the discussion of bug #12867 for more context.


In GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600)
 of 2012-09-17 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  shell-dirtrack-mode: t
  flyspell-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> C-w <backspace> <C-home> C-c C-s <switch-frame> 
d d d C-c C-n r C-c C-y C-x C-x C-SPC <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <C-end> C-w <return> I 
S-SPC a s k e d SPC R i v c h a r d <left> <left> <left> 
<left> <left> <backspace> <M-right> SPC t o SPC s e 
e SPC w h a t SPC c a n SPC b e SPC d o n e . <return> 
<C-home> C-c C-s <switch-frame> d d SPC d d d d d d 
t <next> <next> t C-x C-s <switch-frame> <switch-frame> 
M-1 g <up> <return> C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z <switch-frame> <help-echo> <help-echo> <help-echo> 
<switch-frame> <switch-frame> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z <down> <down> <down> <down> <down> <down> <down> 
<down> <down> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z <down> <down> <down> <down> <down> <down> <down> 
<down> C-z C-z C-z C-z C-z C-z C-z <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z 
C-z n d d d d d p <switch-frame> <help-echo> <switch-frame> 
<switch-frame> M-x r e p o r t - e m a c s - b u g 
<return>

Recent messages:
No following nondeleted message
Saving file d:/usr/eli/rmail/INBOX...
Wrote d:/usr/eli/rmail/INBOX [2 times]
Getting mail from d:/usr/eli/data/mail.new...
Counting new messages...done (6)
Saving file d:/usr/eli/rmail/INBOX...
Wrote d:/usr/eli/rmail/INBOX [2 times]
Computing summary lines...done
6 new messages read
No following nondeleted message

Load-path shadows:
None found.

Features:
(shadow emacsbug autoconf autoconf-mode skeleton dired-aux pp
descr-text iso-transl etags shell mailcap texinfo utf-7 tar-mode
thai-util thai-word mule-util ebuff-menu electric bug-reference
add-log misearch multi-isearch help-mode view network-stream starttls
tls smtpmail auth-source eieio assoc gnus-util password-cache dabbrev
mailalias sendmail rmailout tcl nxml-uchnm rng-xsd xsd-regexp
rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse
rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln
nxml-rap nxml-util nxml-glyph nxml-enc xmltok sgml-mode conf-mode
parse-time generic sh-script executable dired-x dired vc-cvs
face-remap flyspell org-wl org-w3m org-vm org-rmail org-mhe org-mew
org-irc org-jsinfo org-infojs org-html org-exp ob-exp org-exp-blocks
find-func org-agenda org-info org-gnus org-docview org-bibtex bibtex
org-bbdb org byte-opt warnings bytecomp byte-compile cconv macroexp
advice help-fns advice-preload ob-emacs-lisp ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint ob-keys ob ob-eval
org-pcomplete pcomplete comint ansi-color ring org-list org-faces
org-compat org-entities org-macs noutline outline cal-menu calendar
cal-loaddefs arc-mode archive-mode make-mode autorevert jka-compr
smerge-mode newcomment diff-mode easy-mmode info vc-bzr cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt rmailsum qp rmailmm message format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils desktop server filecache mairix cus-edit
easymenu cus-start cus-load wid-edit saveplace midnight ispell
generic-x paren battery time time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)

Message #8 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#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 11:07:11 -0800

[from bug #12867]

> I mean a new option, an enhancement.
> 
> > > But we should first formulate the conditions under which this
> > > redisplay will be performed.
> > 
> > If we're talking about my use case then it is each time the 
> > current line changes.
> 
> 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.

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.

Perhaps the option could handle both cases: the general point-change case and
the more particular line-change case, depending on the option value?

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.

I guess you want users to be able to turn off such triggering?  That is
something different from turning off redisplay caused by such triggering (of
course, inhibiting the triggering turns off its resulting redisplay also).

Anyway, I don't have much to say about what should be done for this enhancement.

> Done: bug #12872.  Let's continue there.

Thank you.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Mon, 12 Nov 2012 21:46:26 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12872 <at> debbugs.gnu.org>
> Date: Mon, 12 Nov 2012 11:07:11 -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?  If you need it
today, you are probably already calling something like what-line,
because the mode line itself doesn't give you the line number back,
right?  You are aware that under certain conditions, the mode line can
be redisplayed although point didn't move at all?

> 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.

> 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.

Message #14 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: 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
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 05:57:59 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12872 <at> debbugs.gnu.org>
> Date: Mon, 12 Nov 2012 14:17:38 -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.

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' ;-).]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Sat, 04 Dec 2021 05:46:57 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> This is a feature request: provide a way to trigger mode-line
> redisplay when the current line changes.  This is so the mode line
> could display information about the current line.
>
> See the discussion of bug #12867 for more context.

I've skimmed both these bug reports, but I'm still not sure I understand
the problem.  `force-mode-line-update' has existed since forever, I
think?  Doesn't it do what it's supposed to?  (And it can be run from
post-command-hook if that's what Drew wants.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Sat, 04 Dec 2021 09:54:38 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Sat, 04 Dec 2021 05:46:57 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This is a feature request: provide a way to trigger mode-line
> > redisplay when the current line changes.  This is so the mode line
> > could display information about the current line.
> >
> > See the discussion of bug #12867 for more context.
> 
> I've skimmed both these bug reports, but I'm still not sure I understand
> the problem.  `force-mode-line-update' has existed since forever, I
> think?  Doesn't it do what it's supposed to?  (And it can be run from
> post-command-hook if that's what Drew wants.)

force-mode-line-update is a blunt weapon, and causes a much more
thorough redisplay than its name says.  And post-command-hook is not
the best method of achieving the desired goal, since it runs after
_every_ command, not just a command that changes the line of point.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Sat, 04 Dec 2021 19:55:09 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> force-mode-line-update is a blunt weapon, and causes a much more
> thorough redisplay than its name says.  And post-command-hook is not
> the best method of achieving the desired goal, since it runs after
> _every_ command, not just a command that changes the line of point.

Perhaps this should be mentioned in the doc string of that function?

This function could grow a `mode-line-only' parameter (or value of ALL),
I guess.  Hm...  following the logic here isn't trivial.  Would setting
a new flag in the window object that'll make redisplay call
redisplay_mode_lines be a way to implement this?

Or just call it directly from (force-mode-line-update 'mode-line-only)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Sat, 04 Dec 2021 21:26:59 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Sat, 04 Dec 2021 19:55:09 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > force-mode-line-update is a blunt weapon, and causes a much more
> > thorough redisplay than its name says.  And post-command-hook is not
> > the best method of achieving the desired goal, since it runs after
> > _every_ command, not just a command that changes the line of point.
> 
> Perhaps this should be mentioned in the doc string of that function?

It already hints on that.  I don't object to saying that more clearly
and explicitly.

But I don't think that's the issue here.

> This function could grow a `mode-line-only' parameter (or value of ALL),
> I guess.  Hm...  following the logic here isn't trivial.  Would setting
> a new flag in the window object that'll make redisplay call
> redisplay_mode_lines be a way to implement this?

We already have the flag.  The problem is how to set it only when the
current line changes.  I think that's the crux of this issue.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Sat, 04 Dec 2021 20:40:40 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This function could grow a `mode-line-only' parameter (or value of ALL),
>> I guess.  Hm...  following the logic here isn't trivial.  Would setting
>> a new flag in the window object that'll make redisplay call
>> redisplay_mode_lines be a way to implement this?
>
> We already have the flag.

What flag is that?

> The problem is how to set it only when the current line changes.  I
> think that's the crux of this issue.

I must admit I didn't understand what was meant by "when the current
line changes".  😐

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Sat, 04 Dec 2021 21:43:14 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Sat, 04 Dec 2021 20:40:40 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> This function could grow a `mode-line-only' parameter (or value of ALL),
> >> I guess.  Hm...  following the logic here isn't trivial.  Would setting
> >> a new flag in the window object that'll make redisplay call
> >> redisplay_mode_lines be a way to implement this?
> >
> > We already have the flag.
> 
> What flag is that?

w->update_mode_line

> > The problem is how to set it only when the current line changes.  I
> > think that's the crux of this issue.
> 
> I must admit I didn't understand what was meant by "when the current
> line changes".  😐

It means point moves from one physical line to another.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Sat, 04 Dec 2021 23:04:11 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> What flag is that?
>
> w->update_mode_line

Oh, I didn't realise that the update_mode_line variable and that field
were separate things...

>> > The problem is how to set it only when the current line changes.  I
>> > think that's the crux of this issue.
>> 
>> I must admit I didn't understand what was meant by "when the current
>> line changes".  😐
>
> It means point moves from one physical line to another.

Then it doesn't sound difficult to implement that in an efficient
manner?  Whatever function Drew is using could just put itself in
post-command-hook and check?  Isn't there a line number cache somewhere?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Sun, 05 Dec 2021 09:02:43 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Sat, 04 Dec 2021 23:04:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> What flag is that?
> >
> > w->update_mode_line
> 
> Oh, I didn't realise that the update_mode_line variable and that field
> were separate things...

update_mode_line is global, affecting all windows.

> >> > The problem is how to set it only when the current line changes.  I
> >> > think that's the crux of this issue.
> >> 
> >> I must admit I didn't understand what was meant by "when the current
> >> line changes".  😐
> >
> > It means point moves from one physical line to another.
> 
> Then it doesn't sound difficult to implement that in an efficient
> manner?  Whatever function Drew is using could just put itself in
> post-command-hook and check?  Isn't there a line number cache somewhere?

It can be solved that way, yes.  But the bug is about allowing to
solve it in a less expensive way.  post-command-hook makes Emacs
sluggish, and line-number cache cannot be trusted in Lisp programs
(and is not exposed to Lisp, I think?).

But if we don't want to add such a feature, we can close the bug as
wontfix.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Sun, 05 Dec 2021 21:05:46 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> But if we don't want to add such a feature, we can close the bug as
> wontfix.

I don't quite see the use case, but we could fix force-mode-line-update
in any case.  That is, add a parameter to only set w->update_mode_line?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Sun, 05 Dec 2021 22:14:34 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Sun, 05 Dec 2021 21:05:46 +0100
> 
> I don't quite see the use case, but we could fix force-mode-line-update
> in any case.  That is, add a parameter to only set w->update_mode_line?

How would that be different from what force-mode-line-update does now?
It sets the update_mode_line flag for the window's buffer, not just
for the window, and it also sets a flag to prevent redisplay
optimizations that could get in the way of the mode-line update.  What
do you suggest to do instead, and why would that be useful?

The problem with the update_mode_line flags is that they are
indiscriminate: the mode line shows a lot of data, each one of it
changes at different frequencies and due to different triggers.  If we
want a finer resolution there, we need to make these flags not just
simple booleans, but enumerations with several values, or maybe
bitmaps.  Then redisplay_window could be smarter about redrawing parts
of the mode line.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Mon, 06 Dec 2021 07:00:39 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> How would that be different from what force-mode-line-update does now?
> It sets the update_mode_line flag for the window's buffer, not just
> for the window, and it also sets a flag to prevent redisplay
> optimizations that could get in the way of the mode-line update.  What
> do you suggest to do instead, and why would that be useful?

Somebody said earlier:

> force-mode-line-update is a blunt weapon, and causes a much more
> thorough redisplay than its name says.

If this isn't accurate, then I guess there's nothing to do here.

> The problem with the update_mode_line flags is that they are
> indiscriminate: the mode line shows a lot of data, each one of it
> changes at different frequencies and due to different triggers.  If we
> want a finer resolution there, we need to make these flags not just
> simple booleans, but enumerations with several values, or maybe
> bitmaps.  Then redisplay_window could be smarter about redrawing parts
> of the mode line.

I think redrawing parts of the mode line would be more work than it's
worth.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12872 <at> debbugs.gnu.org
Subject: Re: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay
Date: Mon, 06 Dec 2021 15:02:23 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 12872 <at> debbugs.gnu.org
> Date: Mon, 06 Dec 2021 07:00:39 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How would that be different from what force-mode-line-update does now?
> > It sets the update_mode_line flag for the window's buffer, not just
> > for the window, and it also sets a flag to prevent redisplay
> > optimizations that could get in the way of the mode-line update.  What
> > do you suggest to do instead, and why would that be useful?
> 
> Somebody said earlier:
> 
> > force-mode-line-update is a blunt weapon, and causes a much more
> > thorough redisplay than its name says.
> 
> If this isn't accurate, then I guess there's nothing to do here.

Somebody else explained earlier the "blunt" part:

> > The problem with the update_mode_line flags is that they are
> > indiscriminate: the mode line shows a lot of data, each one of it
> > changes at different frequencies and due to different triggers.  If we
> > want a finer resolution there, we need to make these flags not just
> > simple booleans, but enumerations with several values, or maybe
> > bitmaps.  Then redisplay_window could be smarter about redrawing parts
> > of the mode line.
> 
> I think redrawing parts of the mode line would be more work than it's
> worth.

Then I guess we should close this as wontfix.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
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, 07 Dec 2021 21:49:29 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Then I guess we should close this as wontfix.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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