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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15797 in the body.
You can then email your comments to 15797 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Info: Mention cache-long-scans
Date: Mon, 04 Nov 2013 03:05:30 +0530

NEWS file seems to be lying wrt `cache-long-line-scans' or
`cache-long-scans'.  I see no entry for these in the manual.

Temporary note:
+++ indicates that all necessary updates to the manuals in doc/ are complete.


+++
** `cache-long-line-scans' has been renamed to `cache-long-scans'
because it affects caching of paragraph scanning results as well.

----------------------------------------------------------------

In GNU Emacs 24.3.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2013-10-30 on debian-6.05
Bzr revision: 114868 rgm <at> gnu.org-20131030102316-8vif7u6ecyo3yieg
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
System Description:	Debian GNU/Linux 6.0.5 (squeeze)

Message #14 received at 15797-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 15797-done <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Sun, 03 Nov 2013 19:36:21 -0500

cd doc
find . -name '*.texi' -exec grep 'cache-long.*scans' {} +

./lispref/display.texi:@code{cache-long-scans} to @code{t}.
./lispref/display.texi:@defvar cache-long-scans
./lispref/positions.texi:performance of your code.  @xref{Truncation, cache-long-scans}.

So: cache-long-scans is defined, and there are no references to the old
name cache-long-line-scans.

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: 15797 <at> debbugs.gnu.org
Cc: rgm <at> gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Mon, 04 Nov 2013 10:11:47 +0530

Why is this variable in lispref.  The variable deserves atleast a
mention in the main manual.

Glenn Morris <rgm <at> gnu.org> writes:

> cd doc
> find . -name '*.texi' -exec grep 'cache-long.*scans' {} +
>
> ./lispref/display.texi:@code{cache-long-scans} to @code{t}.
> ./lispref/display.texi:@defvar cache-long-scans
> ./lispref/positions.texi:performance of your code.  @xref{Truncation,
> cache-long-scans}.
>
> So: cache-long-scans is defined, and there are no references to the old
> name cache-long-line-scans.

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: help-debbugs <at> gnu.org (GNU bug Tracking System)
Cc: 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: closed (Re: bug#15797: 24.3.50;
 Info: Mention cache-long-scans)
Date: Mon, 04 Nov 2013 11:57:12 +0530

Glenn,

I will not agree that this bug is closed unless (atleast) a reference to
this variable is made available in the Emacs manual.

Please talk to the OP before closing the bug.  Anyways ...

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Mon, 04 Nov 2013 14:10:10 +0100

Jambunathan K <kjambunathan <at> gmail.com> writes:

> Why is this variable in lispref.  The variable deserves atleast a
> mention in the main manual.

A small note by a user: In my experience, line caching is a highly
experimental feature.

The first time I tried it - this was 2 or 3 years ago, Emacs crashed
reproducably few seconds after setting the variable to non-nil in any
buffer (bug 12196).  Presumably nobody using Emacs used it that time.

After this had been fixed, I tried to work with cache-long-line-scans
non-nil, and after some minutes I found that it breaks dired (bug 15148,
still not fixed).  Not sure how much other problems are to be
discovered.

So, it's probably better not to advertise it until it works ok.  I would
love to use it when it worked, btw.


Regards,

Michael.

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Mon, 04 Nov 2013 19:51:51 +0530

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> So, it's probably better not to advertise it until it works ok.

What comes first: Hen or the Egg?  Difficult to answer.

I happened to suggest this variable on Org-mode list.  Having long lines
(i.e., avoiding wrapped lines) has it's advantages.  It helps produce
sensible diffs.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Tue, 05 Nov 2013 18:32:22 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Mon, 04 Nov 2013 14:10:10 +0100
> Cc: 15797 <at> debbugs.gnu.org
> 
> A small note by a user: In my experience, line caching is a highly
> experimental feature.

I wonder if we should simply turn it on by default, and leave it
there.  That way, any bugs that it exposes will be flushed out very
quickly.  Stefan?

> After this had been fixed, I tried to work with cache-long-line-scans
> non-nil, and after some minutes I found that it breaks dired (bug 15148,
> still not fixed).

That bug is now fixed.  Sorry, it just seemed to fall through the
cracks.  The actual problem was very simple, and the fix is a
one-liner.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 15797 <at> debbugs.gnu.org,
 kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Tue, 05 Nov 2013 14:24:28 -0500

> I wonder if we should simply turn it on by default, and leave it
> there.  That way, any bugs that it exposes will be flushed out very
> quickly.  Stefan?

Let's try it.


        Stefan

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Wed, 06 Nov 2013 10:14:37 +0530

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Let's try it.

Please don't hide the variable in lispref.  

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

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

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

> > After this had been fixed, I tried to work with cache-long-line-scans
> > non-nil, and after some minutes I found that it breaks dired (bug 15148,
> > still not fixed).
>
> That bug is now fixed.  Sorry, it just seemed to fall through the
> cracks.  The actual problem was very simple, and the fix is a
> one-liner.

Thanks for fixing, Eli.  I'm using cache-long-scans t for 10 hours now
and didn't see any more problems.

BTW, when cache-long-scans t works now, is there any benefit in setting
it nil?  The manual says that the only downside is that it makes
processing of short lines slightly slower - which is presumably
negligible on modern hardware.


Regards,

Michael.

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

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

> 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.

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

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: Re: 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.

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

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: RE: 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.]

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

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

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: monnier <at> iro.umontreal.ca,  15797 <at> debbugs.gnu.org,  kjambunathan <at> gmail.com
> 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?

You are rushing forward too fast, IMO.  Just yesterday you said the
feature was highly experimental.  Let's have it on by default for a
while, before we decide; meanwhile people will at least have a fire
escape.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Wed, 06 Nov 2013 22:56:20 +0200

> Date: Wed, 6 Nov 2013 10:58:55 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
> 
> > > 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?

Always.

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

There's overhead of having it non-nil, but it is small, or so we
think.

> The variable is always buffer-local.  If it will be on by default,
> will it ever be turned off?

When the user does that.

> I assume I can turn it off explicitly in a given buffer, but what
> else might turn it off?

Nothing.

> 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?

Yes.

> Do they cache the result of scanning even short lines?

Yes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 12:28:53 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  kjambunathan <at> gmail.com,  15797 <at> debbugs.gnu.org
> Date: Tue, 05 Nov 2013 14:24:28 -0500
> 
> > I wonder if we should simply turn it on by default, and leave it
> > there.  That way, any bugs that it exposes will be flushed out very
> > quickly.  Stefan?
> 
> Let's try it.

Done as trunk revision 115033.  Let's see what becomes broken by this.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 12:29:57 +0200

> From: Jambunathan K <kjambunathan <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Michael Heerdegen <michael_heerdegen <at> web.de>,  15797 <at> debbugs.gnu.org
> Date: Wed, 06 Nov 2013 10:14:37 +0530
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> > Let's try it.
> 
> Please don't hide the variable in lispref.  

Given that the variable is now on by default, and I see no reason why
anyone would might want to turn it off, except fro debugging, does it
still make sense to have this advertised in the user manual?  If so,
why?

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 18:43:21 +0530

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

> Given that the variable is now on by default, and I see no reason why
> anyone would might want to turn it off, except fro debugging, does it
> still make sense to have this advertised in the user manual?  If so,
> why?

If you are super-confident, remove the variable :-).

Otherwise, re-open the bug and mark it as "wait-and-watch" for the
current release and "must-test" feature for the beta builds.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 09:02:17 -0500

> Otherwise, re-open the bug and mark it as "wait-and-watch" for the
> current release and "must-test" feature for the beta builds.

I think the variable belongs neither in the Emacs manual nor the
Lisp manual.  It's only useful for debugging performance problems.


        Stefan

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 19:38:58 +0530

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I think the variable belongs neither in the Emacs manual nor the
> Lisp manual.

or NEWS. 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 16:15:46 +0200

> From: Jambunathan K <kjambunathan <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  michael_heerdegen <at> web.de,  15797 <at> debbugs.gnu.org
> Date: Fri, 08 Nov 2013 18:43:21 +0530
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Given that the variable is now on by default, and I see no reason why
> > anyone would might want to turn it off, except fro debugging, does it
> > still make sense to have this advertised in the user manual?  If so,
> > why?
> 
> If you are super-confident, remove the variable :-).

I asked why it would make sense to have it in user manual if it is
_not_ removed, but is ON by default.

> Otherwise, re-open the bug

I didn't close it.

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

From: Jambunathan K <kjambunathan <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 20:03:07 +0530

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

> I asked why it would make sense to have it in user manual if it is
> _not_ removed, but is ON by default.

Both of us are argumentative.  We should stop before it gets worse :-).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 15797 <at> debbugs.gnu.org
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 17:16:45 +0200

> From: Jambunathan K <kjambunathan <at> gmail.com>
> Cc: 15797 <at> debbugs.gnu.org
> Date: Fri, 08 Nov 2013 20:03:07 +0530
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I asked why it would make sense to have it in user manual if it is
> > _not_ removed, but is ON by default.
> 
> Both of us are argumentative.

I'm not.  My question was real and serious.

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

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 14:07:44 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I wonder if we should simply turn it on by default, and leave it
>> there.  That way, any bugs that it exposes will be flushed out very
>> quickly.  Stefan?
>
> Let's try it.

Sorry I'm late to the party, but this broke linum and nlinum for me,
using the defaults.  Any time I insert a new line, the line numbers get
totally messed up--most of them don't even display any more.  And then
using motion commands sometimes results in really bizarre behavior
(apparently only with linum/nlinum so far), such as when I do
forwad-sexp and point goes to the end of some sexp other than the one at
point.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 15:57:25 -0500

> Sorry I'm late to the party, but this broke linum and nlinum for me,
> using the defaults.

I tried:

  src/emacs -Q src/xdisp.c -l .../nlinum.el -f nlinum-mode

and then moved about in the buffer, but I didn't notice any problem.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 23:18:54 +0200

> From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Michael Heerdegen <michael_heerdegen <at> web.de>,  15797 <at> debbugs.gnu.org,  kjambunathan <at> gmail.com
> Date: Fri, 08 Nov 2013 14:07:44 -0500
> 
> Sorry I'm late to the party, but this broke linum and nlinum for me,
> using the defaults.

Any breakage that this does means bugs somewhere in Emacs, because the
same function that invalidates the scan cache when a buffer is
modified also adjusts overlays and markers.  So turning this option on
does us a favor by exposing hidden bugs that are otherwise extremely
hard to reproduce.

> Any time I insert a new line, the line numbers get
> totally messed up--most of them don't even display any more.  And then
> using motion commands sometimes results in really bizarre behavior
> (apparently only with linum/nlinum so far), such as when I do
> forwad-sexp and point goes to the end of some sexp other than the one at
> point.

I cannot reproduce this, and neither can Stefan, so it seems.  Please
provide a recipe for reproducing these problems.

Thanks.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 15797 <at> debbugs.gnu.org
Cc: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 16:22:10 -0500

Eli Zaretskii wrote:

> I cannot reproduce this, and neither can Stefan, so it seems.  Please
> provide a recipe for reproducing these problems.

I suggest opening a new report for those issues.

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

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 15797 <at> debbugs.gnu.org, kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 16:36:50 -0500

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> I tried:
>
>   src/emacs -Q src/xdisp.c -l .../nlinum.el -f nlinum-mode
>
> and then moved about in the buffer, but I didn't notice any problem.

Try this with the attached file:

src/emacs -nw -Q foo.el

M-x linum-mode    (you may notice the problem already here)
M-x goto-line 10
C-o

The numbers in the margin get messed up.  I haven't figured out a
consistent way to screw up the motion commands yet.

[foo.el (application/emacs-lisp, attachment)]

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

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 15797 <at> debbugs.gnu.org,
 kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Fri, 08 Nov 2013 18:11:44 -0500

Nathan Trapuzzano <nbtrap <at> nbtrap.com> writes:

> I haven't figured out a consistent way to screw up the motion commands
> yet.

Here we go.  Visit the same file and do:

M-x linum-mode
C-o
C-n
C-e

Cursor moves almost to end of entire file.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15797 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 kjambunathan <at> gmail.com
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Sat, 09 Nov 2013 03:37:49 +0100

Nathan Trapuzzano <nbtrap <at> nbtrap.com> writes:

> Sorry I'm late to the party, but this broke linum and nlinum for me,
> using the defaults.  Any time I insert a new line, the line numbers get
> totally messed up--most of them don't even display any more.  And then
> using motion commands sometimes results in really bizarre behavior
> (apparently only with linum/nlinum so far), such as when I do
> forwad-sexp and point goes to the end of some sexp other than the one at
> point.

I see something probably related.  Sometimes, evaluating

  (line-number-at-pos)

at the end of my .emacs (10000 lines) needs over a second.  Doing

  (setq cache-long-scans nil)

immediately fixes this.  Dunno yet how to provoke the problem.


Regards,

Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: michael_heerdegen <at> web.de, 15797 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#15797: 24.3.50; Info: Mention cache-long-scans
Date: Sat, 09 Nov 2013 10:33:57 +0200

[Message part 1 (text/plain, inline)]

Redirecting to a new bug report.

> From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Michael Heerdegen <michael_heerdegen <at> web.de>,  15797 <at> debbugs.gnu.org,  kjambunathan <at> gmail.com
> Date: Fri, 08 Nov 2013 16:36:50 -0500
> 
> Try this with the attached file:
> 
> src/emacs -nw -Q foo.el
> 
> M-x linum-mode    (you may notice the problem already here)
> M-x goto-line 10
> C-o
> 
> The numbers in the margin get messed up.  I haven't figured out a
> consistent way to screw up the motion commands yet.

[foo.el (application/emacs-lisp, attachment)]

Previous Next

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