Re: font-lock performance [was ...using Oort...]
Matt Tucker <tuck(a)whistlingfish.net> writes:
Russ Allbery wrote:
> I'm likely to just switch back to 21.1.12 for right now since
21.4.6
> also has an annoying performance regression when deleting text out of
> a font-lock buffer, but I'm curious whether anyone else is seeing
> this one or if it's something peculiar to my configuration.
Is it possible to provide any further details on this? Can you
generate
a -vanilla recipe for reproducing it? I haven't seen anything like this
and I'd love to get all these issues fixed.
Figured this out, with the help of a working elp. Turned out to not have
anything to do with font-lock whatsoever; sorry about that false alarm.
It was the new settings of interprogram-cut-function; I frequently use a
remote X display and it was taking 0.3 seconds each time it updated the
clipboard selection. The following:
;; XEmacs 21.4 introduced this to set the X clipboard selection to the
;; most recently cut text and reads text to yank from the clipboard. It's
;; *painfully* slow; turn it off.
(setq interprogram-cut-function nil)
(setq interprogram-paste-function nil)
restores the performance of older versions of XEmacs. Since the new
documented behavior doesn't sound good anyway (I frequently separately use
the kill ring and the clipboard for different purposes at the same time),
that's a perfect solution for me other than the fact that it's both not
the default and not documented in the user manual (but it is in lispref,
which is how I figured it out after reading the definition of kill-new in
simple.el).
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>