Re: animate incredibly slow compared to 21.3

[Kim F. Storm]

Miles Bader <address@hidden> writes:

> On Sun, 13 Mar 2005 02:15:22 +0100, Kim F. Storm <address@hidden> wrote:
>> I still fail to see why sit-for is so bad in line-move -- most of the
>> time it simply means that redisplay happens a little sooner than it
>> would otherwise do.
>
> Because `sit-for' means something completely different -- it means
> "Hey I want the user to see this, please flush any pending redisplay
> so he can see it" [modulo details about about buffer input etc.]. 
> What you're talking about is "hey, let me calculate some stuff more
> accurately."

I don't disagree with this -- and we should eventually find a better
way to do this.

However, for the release, I think we should accept the current
code, as it works well enough for practical, everyday usage.

> It's quite reasonable to want to do the latter in code that shouldn't
> be displaying anything.  Conflating the two notions is ugly and
> pointless.  _Even if_ the current most practical workaround for some
> problem is to use `sit-for' when you really want to do the other
> thing, it would make a lot of sense to at least call it something
> else, and have that something else use sit-for.

That is exactly what we were discussing...

> If I do something requiring up-to-date display calculations, and then
> record it in a keyboard macro and execute it with a repeat-count of
> 10,000, I certainly don't want to see it redisplay 10,000 times -- I
> want it to sit there silently until it's done, and then redisplay.

That is a good point.

Actually, I think we should NOT do partial vscrolling when executing a
macro.  E.g. if a user creates a macro like

C-a C-t C-n

and repeats it 10000 times, he would expect it to work the same on
FULL and PARTIAL lines.  With partial scrolling, the number of C-t's
performed on partial lines would depend on how tall the line is.

Likewise for non-interactive use.

I will install a fix.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk