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

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15797 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, kjambunathan <at> gmail.com
Subject: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Wed, 06 Nov 2013 19:50:03 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: Michael Heerdegen <michael_heerdegen <at> web.de>
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
> > Date: Wed, 06 Nov 2013 19:02:11 +0100
> > 
> > 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.

Sorry, you misunderstood.  What I meant was: do we (perspectively) need
a variable at all, when a nil value only has downsides?  Why should
anybody want to configure this variable to nil (the default value is t
now) when it has only disadvantages?  That's what I meant.

Michael.

Previous Next

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