[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: merge emacs-bidi into the main tree
- To: Eli Zaretskii <eliz at elta dot co dot il>
- Subject: Re: merge emacs-bidi into the main tree
- From: gerd dot moellmann at t-online dot de (Gerd Moellmann)
- Date: 10 Aug 2003 12:42:37 +0200
- Cc: emacs-bidi at gnu dot org
- Cc: alex at emacswiki dot org
- Cc: rms at gnu dot org
- Cc: developer at arabeyes dot org
- Cc: emacs-devel at gnu dot org
- User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Eli Zaretskii <eliz at elta dot co dot il> writes:
> However, it doesn't seem right to me to have an Emacs that cannot
> scroll fast enough just because I've set such a flag, assuming that
> Gerd's intuition is correct.
One way to see how working with disabled redisplay optimizations feels
might be to intentionally disable the optimizations in the source
code.
(Which is, BTW, where my intuition comes from, only that I didn't
disable any optimizations, but implement one after the other until the
result was "fast enough", for me anyway. And, another BTW, redisplay
optimization was _the_ major time sink and _the_ primary source of
complexity, when rewriting redisplay, esp. under the ancillary
condition of being compatible with Emacs 19's redisplay. I'm
mentioning that only in case that r2l redisplay optimization will
prove necessary.)
In any case, I think it might be worth the experiment. Computers got
noticeable faster, maybe the picture is different now than it was in
the late '90s.