all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.



  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.