Re: none
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
Grimly I point out that if we ignored recording changes until
redisplay was called and then compared old state to new state it
would make little difference what lazy-lock did.
That is what the code has been doing since a few days. It works quite
well (i.e. lisp updates a copy of the tab widgets and redisplay copies
that if that and the displayed version no longer match). Of course, no
matter what lisp is doing, XEmacs shouldn't crash.
This is not about the displayed state being update to match lisp. This
about running lisp code that needs to track the state of the selected
window. It must be run also inside a save-window-configuration because
the code would very well be
(save-window-configuration
(select-window w)
(recursive-edit)..)
However it turns out everybody and his dog is using the
(save-window-configuration
(select-window w)
idiom.. This is suggests two things...
1. record-buffer-hook is called way to often to do expensive things.
The solution is standard. Change the hook to simply set a flag and
then put the real update function at some other point that is less
expensive (pre-idle-hook? There isn't a pre-redisplay-hook that I
can see).[1]
2. save-window-configuration is expensive. If so much code needs to do
it there is probably something missing in the api. Some functions
need window arguments?
Footnotes:
[1] It could be you meant this in the first place. But then I
disagree with the statement that is as is always been for lisp,
because the appropriate hooks seem to be missing.