GNU bug report logs - #15797
24.3.50; Info: Mention cache-long-scans

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Wed, 6 Nov 2013 10:58:55 -0800 (PST)

> > BTW, when cache-long-scans t works now, is there any benefit in
> > setting it nil?
> 
> We will shortly turn it on by default, as you see from the rest of
> this discussion.

Only for visual-line-mode, or in general?  Only when there are
actually long lines in the buffer, or in general?

And the question was not just about the default behavior, but
whether there is (ever) any benefit in setting it to nil.

The variable is always buffer-local.  If it will be on by default,
will it ever be turned off?  If so, just what turns it off?  (I
assume I can turn it off explicitly in a given buffer, but what
else might turn it off?)

Also, I wonder about this part of the doc (I don't have the C
source code to check what it really does):

  "If `cache-long-scans' is non-nil, these motion functions cache
   the results of their scans"

That does not say that they cache only the result of scanning long
lines.  Is that correct?  Do they cache the result of scanning even
short lines?

[BTW, the doc speaks of both "the cache" (singular) and "the
caches", which is confusing.  Please pick one, or if there is some
reason for using both then please make it clear: why the difference,
etc.]

Previous Next

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