* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay @ 2012-11-12 18:27 Eli Zaretskii 2012-11-12 19:46 ` Eli Zaretskii 2021-12-04 4:46 ` Lars Ingebrigtsen 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2012-11-12 18:27 UTC (permalink / raw) To: 12872 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 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 2021-12-04 4:46 ` Lars Ingebrigtsen 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2012-11-12 19:46 UTC (permalink / raw) To: Drew Adams; +Cc: 12872 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <12872@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2012-11-12 19:46 ` Eli Zaretskii @ 2012-11-12 22:17 ` Drew Adams 2012-11-13 3:57 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Drew Adams @ 2012-11-12 22:17 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 12872 > > > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2012-11-12 22:17 ` Drew Adams @ 2012-11-13 3:57 ` Eli Zaretskii 2012-11-13 15:38 ` Drew Adams 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2012-11-13 3:57 UTC (permalink / raw) To: Drew Adams; +Cc: 12872 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <12872@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2012-11-13 3:57 ` Eli Zaretskii @ 2012-11-13 15:38 ` Drew Adams 0 siblings, 0 replies; 18+ messages in thread From: Drew Adams @ 2012-11-13 15:38 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 12872 > > 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' ;-).] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 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 @ 2021-12-04 4:46 ` Lars Ingebrigtsen 2021-12-04 7:54 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-04 4:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 4:46 ` Lars Ingebrigtsen @ 2021-12-04 7:54 ` Eli Zaretskii 2021-12-04 18:55 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-04 7:54 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@debbugs.gnu.org > Date: Sat, 04 Dec 2021 05:46:57 +0100 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 7:54 ` Eli Zaretskii @ 2021-12-04 18:55 ` Lars Ingebrigtsen 2021-12-04 19:26 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-04 18:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 18:55 ` Lars Ingebrigtsen @ 2021-12-04 19:26 ` Eli Zaretskii 2021-12-04 19:40 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-04 19:26 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@debbugs.gnu.org > Date: Sat, 04 Dec 2021 19:55:09 +0100 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 19:26 ` Eli Zaretskii @ 2021-12-04 19:40 ` Lars Ingebrigtsen 2021-12-04 19:43 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-04 19:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 19:40 ` Lars Ingebrigtsen @ 2021-12-04 19:43 ` Eli Zaretskii 2021-12-04 22:04 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-04 19:43 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@debbugs.gnu.org > Date: Sat, 04 Dec 2021 20:40:40 +0100 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 19:43 ` Eli Zaretskii @ 2021-12-04 22:04 ` Lars Ingebrigtsen 2021-12-05 7:02 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-04 22:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-04 22:04 ` Lars Ingebrigtsen @ 2021-12-05 7:02 ` Eli Zaretskii 2021-12-05 20:05 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-05 7:02 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@debbugs.gnu.org > Date: Sat, 04 Dec 2021 23:04:11 +0100 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-05 7:02 ` Eli Zaretskii @ 2021-12-05 20:05 ` Lars Ingebrigtsen 2021-12-05 20:14 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-05 20:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-05 20:05 ` Lars Ingebrigtsen @ 2021-12-05 20:14 ` Eli Zaretskii 2021-12-06 6:00 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-05 20:14 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-05 20:14 ` Eli Zaretskii @ 2021-12-06 6:00 ` Lars Ingebrigtsen 2021-12-06 13:02 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-06 6:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-06 6:00 ` Lars Ingebrigtsen @ 2021-12-06 13:02 ` Eli Zaretskii 2021-12-07 20:49 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2021-12-06 13:02 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 12872 > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: 12872@debbugs.gnu.org > Date: Mon, 06 Dec 2021 07:00:39 +0100 > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#12872: 24.2; Provide a feature to trigger mode-line redisplay 2021-12-06 13:02 ` Eli Zaretskii @ 2021-12-07 20:49 ` Lars Ingebrigtsen 0 siblings, 0 replies; 18+ messages in thread From: Lars Ingebrigtsen @ 2021-12-07 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12872 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-12-07 20:49 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.