From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 29c360e: Ensure redisplay after "C-x C-e"
Date: Fri, 06 Nov 2015 17:47:49 +0200 [thread overview]
Message-ID: <83oaf7qgd6.fsf@gnu.org> (raw)
In-Reply-To: <jwvtwozf9bv.fsf-monnier+emacsdiffs@gnu.org>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 06 Nov 2015 10:30:51 -0500
>
> >> That's always been the case for setting line-spacing.
> > No, it worked correctly before Emacs 24.4, according to my testing.
>
> Yes, but that was an accident. I think what you did is add an arbitrary
> hack to paper over this, and I think it'd be better to do it either of:
> - live with the apparent regression, telling users that they should
> simply be happy to have enjoyed this accident in the past.
I don't like this alternative. Redisplay should be correct before it
is fast. Users rightfully expect changes to such variables to have
effect immediately, so not doing that looks like a bug. How do you
explain that, after evaluating (setq line-spacing 1.0) nothing
happens, but as soon as you type "M-x", the new setting takes effect?
> - fix it "right". E.g. add ad-hoc code to redisplay_internal that tries
> to detect changes to this variable, or add a "write barrier" on that
> variable, or deprecated the `line-spacing' variable in favor of
> a `set-line-spacing' function (thus providing the write-barrier), ...
This is not the only such variable, there are others. Adding ad-hoc
code for each one sounds _really_ hacky.
I cannot take the other possibilities seriously, and I don't think you
do, either.
> If you fix this case in the way you did, then I see no reason not to
> go further down that road and just always redisplay all mode-lines, on
> the off-chance that the user set line-spacing, or toggled a minor mode
> variable without calling something like force-mode-line-update, set
> a variable `toto' which happens to be used by one of the (:eval...)
> nodes of the mode-line-format of some of the displayed buffers, ...
I see no reason to go down that road. I don't think there are any
problems to fix there, and simply redisplaying all mode lines all the
time will have no effect except slowing down Emacs.
> > Why should we care about performance of "C-x C-e"?
>
> Why not?
Because it's not performance-critical, and cannot be, ever.
> I just think your addition of force-mode-line-update will be wasted
> work in 99.9% of the cases, and it will only cover very few of the
> cases where a force-mode-line-update is needed.
Please show at least a couple of other cases. Then maybe I will
change my mind.
> PS: I even several times found that the "lucky accident" which causes
> the mode-line to be recomputed after things like M-: is a mis-feature
> because it doesn't let me know when a call to force-mode-line-update
> is needed.
I see no way around that, as long as going to minibuffer causes
changes in display, like the menu bar, the tool bar, etc.
next prev parent reply other threads:[~2015-11-06 15:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151106093011.17282.48378@vcs.savannah.gnu.org>
[not found] ` <E1ZudLX-0004XR-KP@vcs.savannah.gnu.org>
2015-11-06 14:18 ` [Emacs-diffs] master 29c360e: Ensure redisplay after "C-x C-e" Stefan Monnier
2015-11-06 14:31 ` Eli Zaretskii
2015-11-06 14:53 ` Artur Malabarba
2015-11-06 15:30 ` Eli Zaretskii
2015-11-06 16:11 ` Artur Malabarba
2015-11-06 16:30 ` Eli Zaretskii
2015-11-06 19:25 ` Eli Zaretskii
2015-11-07 23:41 ` Stefan Monnier
2015-11-08 3:36 ` Eli Zaretskii
2015-11-08 9:23 ` David Kastrup
2015-11-08 15:54 ` Eli Zaretskii
2015-11-08 15:55 ` Drew Adams
2015-11-08 16:07 ` David Kastrup
2015-11-08 22:25 ` Stefan Monnier
2015-11-09 3:32 ` Eli Zaretskii
2015-11-06 15:33 ` Stefan Monnier
2015-11-06 15:30 ` Stefan Monnier
2015-11-06 15:47 ` Eli Zaretskii [this message]
2015-11-06 15:54 ` Eli Zaretskii
2015-11-06 21:47 ` Stefan Monnier
2015-11-07 9:07 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83oaf7qgd6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 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.