GNU bug report logs - #17837
24.4.50; Search very slow

Previous Next

Package: emacs;

Reported by: rms <at> gnu.org

Date: Mon, 23 Jun 2014 15:28:02 UTC

Severity: normal

Tags: unreproducible

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 17837 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: monnier <at> iro.umontreal.ca, 17837 <at> debbugs.gnu.org
Subject: Re: bug#17837: 24.4.50; Search very slow
Date: Tue, 24 Jun 2014 18:59:41 +0300
> Date: Tue, 24 Jun 2014 11:42:13 -0400
> From: Richard Stallman <rms <at> gnu.org>
> CC: monnier <at> iro.umontreal.ca, 17837 <at> debbugs.gnu.org
> 
>     Anyway, you may wish to experiment with setting jit-lock-defer-time to
>     a non-nil value.  E.g., try setting it to 0.25 or 0.5 sec, and see if
>     that gives good results.
> 
> I tried setting that to .1, and here's what happened.
> 
> I typed C-s C-s (which searched for "honor").  It found the first
> occurrence and displayed it without fontifying that area.
> 
> Then I typed C-f and got no response.  I suspect it had already
> started to highlight the other matches, and was fontifying the
> regions where they occur.
> 
> The C-f was executed after 30 seconds or more.

Does anything change if you set redisplay-dont-pause to nil?

Stefan, isn't jit-lock supposed to stop and relinquish control if
input is available?  I thought it did, but I cannot find any code to
that effect.  What am I missing?




This bug report was last modified 3 years and 248 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.