Re: [Emacs-diffs] master 29c360e: Ensure redisplay after "C-x C-e"

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 06 Nov 2015 16:47:58 -0500
> 
> >> - 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.
> 
> We agree in general, of course.  But it's always been the case that some
> changes require a call to force-mode-line-update.  Notice that 
> 
> > 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?
> 
> I explain it saying that this variable value is only taken into account
> if something is redisplayed.  And the user moves on very happy.

Not this user.  And so I don't want to explain this away like that.

> E.g. note how in bug#21835, the lack of redisplay is not a cause for
> reporting a bug.  It's just a minor surprise worthy of a "Note" in
> passing to the actual problem of how the cursor is displayed.

True for the person who reported that bug.  Not true for me.  Any
change in display when you press M-x is a subtle redisplay bug that
needs to be fixed.  It means some redisplay optimization was used
when it shouldn't have been.

> If you don't like this answer, how 'bout I return the question:
> 
>    How do you explain to the user that when he used C-x C-e the display
>    was immediately updated, but when I put that same code into his
>    hand-made interactive function, it stopped working and started to
>    only take effect after something like M-x?

Well, I was bothered by that as well, so the follow-up commit fixed
that, I hope.  Do you like it better?

> I really can't see why we should hide this weakness of our
> redisplay system in the case of C-x C-e.  Either this weakness exists
> and the Elisp coder will have to know about it sooner or later, or we
> fix it for real.

I hope I've now fixed it for real.

> > This is not the only such variable, there are others.  Adding ad-hoc
> > code for each one sounds _really_ hacky.
> 
> Agreed.

The changes I made in 19e09cf are hopefully less hacky.

> > I cannot take the other possibilities seriously, and I don't think you
> > do, either.
> 
> A `set-line-spacing' function, no, but a write-barrier, yes.
> We've already had discussions on emacs-devel to add such a generic
> feature cheaply, even with patches submitted.

Please point to those patches, I don't think I have a clear idea what
you allude to here.

> >> > Why should we care about performance of "C-x C-e"?
> >> Why not?
> > Because it's not performance-critical, and cannot be, ever.
> 
> Of course it can be performance critical in keyboard-macros.

Redisplay happens only once after the macro finishes, no?  Or did you
have some very specific macro in mind?

> >> 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.
> 
> "grep force-mode-line-update" shows it's still needed at tons of
> other places.  Adding it in C-x C-e won't help them.

It wasn't supposed to help them.  Or maybe I completely misunderstand
what you wanted to say here.