[christopher.ian.moore@gmail.com: Emacs very slow opening file]

[christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Richard M. Stallman]

Would someone please investigate this bug report,
and then ack?

------- Start of forwarded message -------
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type;
	b=BbQBU7hQnkHsJVFn6VhCSrNC2dyzadU7GLMDMCbc598sLEWeoBACv7YhB62SrnbZ0qebAjXOQw7Efq9nmryBFFMb/fzqaEcyQUF4eS7rMtj6TdCpo1KBDIAgBBUijSCWmjZAs6UtSHoLVZNY+ORc3PjxXzz5swbhGu9bckHbJuM=
Date: Tue, 27 Sep 2005 22:58:41 +0200
From: Chris Moore <christopher.ian.moore@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: Emacs very slow opening file
Reply-To: Chris Moore <christopher.ian.moore@gmail.com>
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP 
	autolearn=no version=2.63

- --===============0462481672==
Content-Type: multipart/alternative; 
	boundary="----=_Part_9647_19084108.1127854721715"

- ------=_Part_9647_19084108.1127854721715
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I tried opening a debian 'patch' file in Emacs. The Emacs process
appeared to hang, using all my CPU. It wouldn't respond to C-g.

After chopping down my .emacs to see what triggered the problem, it
turns out that just using a minimal .emacs file like this triggers it:

;; -------
(custom-set-variables '(global-font-lock-mode t nil (font-lock)))
(find-file "bigfile")
;; -------

"bigfile" is the patch file, which I've cut down to a reasonable size
(1.3 Mb), and uploaded here:

http://s89213869.onlinehome.us/bigfile

It takes the latest CVS Emacs on my 2.2GHz P4 PC 15 seconds to open that
file.

If I change the .emacs to say the following, then the file opens
almost immediately:

;; -------
(custom-set-variables '(global-font-lock-mode t nil (font-lock)))
(defun y-or-n-p (prompt) (message "Not asking '%s'" prompt))
(find-file "bigfile")
;; -------

So it seems to be some kind of interaction between y-or-n-p and
font-lock perhaps?

Note that the patch file is adding Emacs "file local variables" to a
whole bunch of files, which is probably confusing Emacs and causing
the problem. Still, it would be good if Emacs could handle this more
elegantly.

Chris.


In GNU Emacs 22.0.50.13 <http://22.0.50.13> (i686-pc-linux-gnu, GTK+ Versio=
n
2.8.3)
of 2005-09-27 on chrislap
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-gtk' '--with-xpm' '--with-jpeg'
'--with-png' '--with-gif''

Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t

- ------=_Part_9647_19084108.1127854721715
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I tried opening a debian 'patch' file in Emacs.&nbsp; The Emacs process<br>=
appeared to hang, using all my CPU.&nbsp; It wouldn't respond to C-g.<br><b=
r>After chopping down my .emacs to see what triggered the problem, it<br>tu=
rns out that just using a minimal .emacs file like this triggers it:
<br><br>&nbsp; ;; -------<br>&nbsp; (custom-set-variables '(global-font-loc=
k-mode t nil (font-lock)))<br>&nbsp; (find-file &quot;bigfile&quot;)<br>&nb=
sp; ;; -------<br><br>&quot;bigfile&quot; is the patch file, which I've cut=
 down to a reasonable size
<br>(1.3 Mb), and uploaded here:<br><br>&nbsp; <a href=3D"http://s89213869.=
onlinehome.us/bigfile">http://s89213869.onlinehome.us/bigfile</a><br><br>It=
 takes the latest CVS Emacs on my 2.2GHz P4 PC 15 seconds to open that file=
.<br>
<br>If I change the .emacs to say the following, then the file opens<br>alm=
ost immediately:<br><br>&nbsp; ;; -------<br>&nbsp; (custom-set-variables '=
(global-font-lock-mode t nil (font-lock)))<br>&nbsp; (defun y-or-n-p (promp=
t) (message &quot;Not asking '%s'&quot; prompt))
<br>&nbsp; (find-file &quot;bigfile&quot;)<br>&nbsp; ;; -------<br><br>So i=
t seems to be some kind of interaction between y-or-n-p and<br>font-lock pe=
rhaps?<br><br>Note that the patch file is adding Emacs &quot;file local var=
iables&quot; to a
<br>whole bunch of files, which is probably confusing Emacs and causing<br>=
the problem.&nbsp; Still, it would be good if Emacs could handle this more<=
br>elegantly.<br><br>Chris.<br><br><br>In GNU Emacs <a href=3D"http://22.0.=
50.13">
22.0.50.13</a> (i686-pc-linux-gnu, GTK+ Version 2.8.3)<br>&nbsp;of 2005-09-=
27 on chrislap<br>X server distributor `The X.Org Foundation', version 11.0=
.60802000<br>configured using `configure '--with-gtk' '--with-xpm' '--with-=
jpeg' '--with-png' '--with-gif''
<br><br>Important settings:<br>&nbsp; value of $LC_ALL: nil<br>&nbsp; value=
 of $LC_COLLATE: nil<br>&nbsp; value of $LC_CTYPE: nil<br>&nbsp; value of $=
LC_MESSAGES: nil<br>&nbsp; value of $LC_MONETARY: nil<br>&nbsp; value of $L=
C_NUMERIC: nil<br>&nbsp; value of $LC_TIME: nil
<br>&nbsp; value of $LANG: en_GB<br>&nbsp; locale-coding-system: iso-latin-=
1<br>&nbsp; default-enable-multibyte-characters: t<br><br>

- ------=_Part_9647_19084108.1127854721715--



- --===============0462481672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

- --===============0462481672==--
------- End of forwarded message -------

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 2389 bytes --]

On Wed, Sep 28, 2005 at 01:11:10PM -0400, Richard M. Stallman wrote:
> Would someone please investigate this bug report,
> and then ack?
[...]
> I tried opening a debian 'patch' file in Emacs. The Emacs process
> appeared to hang, using all my CPU. It wouldn't respond to C-g.
> 
> After chopping down my .emacs to see what triggered the problem, it
> turns out that just using a minimal .emacs file like this triggers it:
> 
> ;; -------
> (custom-set-variables '(global-font-lock-mode t nil (font-lock)))
> (find-file "bigfile")
> ;; -------
> 
> "bigfile" is the patch file, which I've cut down to a reasonable size
> (1.3 Mb), and uploaded here:
> 
> http://s89213869.onlinehome.us/bigfile
> 
> It takes the latest CVS Emacs on my 2.2GHz P4 PC 15 seconds to open that
> file.

I can confirm, that it takes more than 10 seconds to open the given
file, using the latest emacs from cvs.

After short investigation I found the following:
What takes so long is a combination of c-mode fontification and
interpretation of file-local variables.

What happens is that: 

- running through the file emacs finds the last valid "Local
  Variables:" block starting on line 42634,

- in the first line of this block the mode gets switched to c-mode.

- After that emacs finds an "eval:" in the next line of the block, and
  wants to ask the user whether to process it, 

- so the part of the file with the eval: variable in question is
  displayed -- this is starting with line 42635(!)

- fontification is enabled, and the c-mode fontification rules seem to 
  do lots of parsing on the whole file preceding the displayed part
  _that_ is what takes so long.

To verify my theory, simply change line 42635 from
-/* mode:c */
to
-/* mode:diff */
(or fundamental or lisp or simply anything, which does less expensive
fontification).

So, I would conclude, that there is no bug at all.  Emacs can't
possibly know, that the "Local Variables:" block isn't meant to be
interpreted in the diff file.  

And I wouldn't consider the fact, that c-mode fontification takes so
long on a big file, which isn't valid c-code at all, a bug.

Workaround: turn of global-font-lock-mode or set
enable-local-variables to nil, before opening a file like that.

cheers
sascha
-- 
Sascha Wilde
"C++ : an octopus made by nailing extra legs onto a dog"

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Kenichi Handa]

In article <20050929095157.GA6233@kenny.sha-bang.local>, Sascha Wilde <wilde@sha-bang.de> writes:

> So, I would conclude, that there is no bug at all.  Emacs can't
> possibly know, that the "Local Variables:" block isn't meant to be
> interpreted in the diff file.  

> And I wouldn't consider the fact, that c-mode fontification takes so
> long on a big file, which isn't valid c-code at all, a bug.

> Workaround: turn of global-font-lock-mode or set
> enable-local-variables to nil, before opening a file like that.

Perhaps, Emacs has to detect that the file is a patch before
checking "-*- ... -*-" and "Local Variables".

---
Kenichi Handa
handa@m17n.org

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 701 bytes --]

On Thu, Sep 29, 2005 at 09:24:43PM +0900, Kenichi Handa wrote:
> In article <20050929095157.GA6233@kenny.sha-bang.local>, Sascha Wilde <wilde@sha-bang.de> writes:
> 
> > So, I would conclude, that there is no bug at all.  Emacs can't
> > possibly know, that the "Local Variables:" block isn't meant to be
> > interpreted in the diff file.  
[...]
> Perhaps, Emacs has to detect that the file is a patch before
> checking "-*- ... -*-" and "Local Variables".

I don't think that any magical file-type recognition mechanism should
overwrite explicitly stated modes.

cheers
sascha
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Stefan Monnier]

>> > So, I would conclude, that there is no bug at all.  Emacs can't
>> > possibly know, that the "Local Variables:" block isn't meant to be
>> > interpreted in the diff file.  
> [...]
>> Perhaps, Emacs has to detect that the file is a patch before
>> checking "-*- ... -*-" and "Local Variables".

> I don't think that any magical file-type recognition mechanism should
> overwrite explicitly stated modes.

I completely agree with that, but I do think that the rule for "what is
a Local-Variables section" is not strict enough.  It'd be good to tighten
them, or at least make it possible to tighten them.

E.g. major modes could set a "local-variables-prefix-regexp" which the text
leading to the "Local Variables" should match.  E.g. c-mode could set it to
"\\`[ \t]*\\(//\\|/?\\*)[ \t]*\\'"  Problem is: in order for
this to be useful for the OP, the test should be done *after* using the
Local-Variables's section (i.e. after switching to C mode).  Still, it
doesn't sound unfeasible, and would help reduce the likelihood of mistakenly
using a Local-Variables section.


        Stefan

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Juri Linkov]

> E.g. major modes could set a "local-variables-prefix-regexp" which
> the text leading to the "Local Variables" should match.  E.g. c-mode
> could set it to "\\`[ \t]*\\(//\\|/?\\*)[ \t]*\\'" Problem is:
> in order for this to be useful for the OP, the test should be done
> *after* using the Local-Variables's section (i.e. after switching to
> C mode).  Still, it doesn't sound unfeasible, and would help reduce
> the likelihood of mistakenly using a Local-Variables section.

Recently I ran into the problem when Emacs tried to interpret the
Local Variables section in the "htmlized" file.  I suggested to the
author of htmlize.el to replace `Local Variables:' in the output by
its HTML equivalent `Local Variables:' that Emacs doesn't recognize.

With a new special variable HTML mode could set it to a value that
matches the Local Variables section only inside HTML comments, and such
problems of mistakenly using a Local Variables section wouldn't occur
in packages that convert files to other representations.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Richard M. Stallman]

    Recently I ran into the problem when Emacs tried to interpret the
    Local Variables section in the "htmlized" file.  I suggested to the
    author of htmlize.el to replace `Local Variables:' in the output by
    its HTML equivalent `Local Variables:' that Emacs doesn't recognize.

This method, to change the program that produces the file,
is applicable in some cases.  But I don't think it is applicable to diff.

    With a new special variable HTML mode could set it to a value that
    matches the Local Variables section only inside HTML comments, and such
    problems of mistakenly using a Local Variables section wouldn't occur
    in packages that convert files to other representations.

Yes, that could work--if the variable gets set before Emacs looks for
the local variable list.  However, I am not sure a regexp is powerful enough
to do the job for diff files.

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Andreas Schwab]

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

> E.g. major modes could set a "local-variables-prefix-regexp" which the text
> leading to the "Local Variables" should match.  E.g. c-mode could set it to
> "\\`[ \t]*\\(//\\|/?\\*)[ \t]*\\'"  Problem is: in order for
> this to be useful for the OP, the test should be done *after* using the
> Local-Variables's section (i.e. after switching to C mode). 

Another problem is that this example will enforce a comment style that
many people may disagree with.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Richard M. Stallman]

    So, I would conclude, that there is no bug at all.  Emacs can't
    possibly know, that the "Local Variables:" block isn't meant to be
    interpreted in the diff file. =20

Hmm.  It still feels like a bug to me, and I want to find a way to fix
it.

One idea is to restrict what strings can be used as the "prefix"
in a local variables list, so that local variables lists in diff output
are not obeyed.

Meanwhile, I think it is also a bug that Font-Lock in C mode parses
most of the file, even when given data that isn't really C.

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     So, I would conclude, that there is no bug at all.  Emacs can't
>     possibly know, that the "Local Variables:" block isn't meant to be
>     interpreted in the diff file. =20
>
> Hmm.  It still feels like a bug to me, and I want to find a way to fix
> it.

When Emacs is running diff itself, it could start the output off with
an appropriate -*- type string overriding a possible local variables
block.  Or it could append a solitary ^L to the output (which is the
normal way of telling Emacs not to look further backward for a local
variables section).

> One idea is to restrict what strings can be used as the "prefix" in
> a local variables list, so that local variables lists in diff output
> are not obeyed.
>
> Meanwhile, I think it is also a bug that Font-Lock in C mode parses
> most of the file, even when given data that isn't really C.

Well, one would need a "give up" heuristic then.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 1086 bytes --]

On Fri, Sep 30, 2005 at 08:39:40AM +0200, David Kastrup wrote:
> "Richard M. Stallman" <rms@gnu.org> writes:
> 
> >     So, I would conclude, that there is no bug at all.  Emacs can't
> >     possibly know, that the "Local Variables:" block isn't meant to be
> >     interpreted in the diff file. =20
> >
> > Hmm.  It still feels like a bug to me, and I want to find a way to fix
> > it.
> 
> When Emacs is running diff itself, it could start the output off with
> an appropriate -*- type string overriding a possible local variables
> block.  

I like that idea.  To make it work the behavior of emacs would have to
be changed so that a -*- line takes precedence over following local
variables lists, which isn't the case at the moment.

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Richard M. Stallman]

    When Emacs is running diff itself, it could start the output off with
    an appropriate -*- type string overriding a possible local variables
    block.  Or it could append a solitary ^L to the output (which is the
    normal way of telling Emacs not to look further backward for a local
    variables section).

That would work.  However, if the other idea can work--recognize that
the Local Variables list is inside a diff hunk--that would work more
generally.

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Stefan Monnier]

>     When Emacs is running diff itself, it could start the output off with
>     an appropriate -*- type string overriding a possible local variables
>     block.  Or it could append a solitary ^L to the output (which is the
>     normal way of telling Emacs not to look further backward for a local
>     variables section).

> That would work.

Except that most diff/patch files are not generated by Emacs.


        Stefan

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Sascha Wilde]

[-- Attachment #1.1: Type: text/plain, Size: 1651 bytes --]

On Thu, Sep 29, 2005 at 07:31:04PM -0400, Richard M. Stallman wrote:
>     So, I would conclude, that there is no bug at all.  Emacs can't
>     possibly know, that the "Local Variables:" block isn't meant to be
>     interpreted in the diff file. =20
> 
> Hmm.  It still feels like a bug to me, and I want to find a way to
> fix it.

I agree, that it would be nice, if it could be fixed -- still wouldn't
call it a bug.  Emacs acts exactly as one would expect from the
documentation.
 
> One idea is to restrict what strings can be used as the "prefix"
> in a local variables list, so that local variables lists in diff output
> are not obeyed.

I'm afraid it won't be that easy.  Typical prefix chars in diffs are
"-", "+" and "!" most (all?) of them are used for comments in some
languages (eg. Ada, Postscript).  Even worse: context lines aren't
prefixed at all.

I think that emacs would need to know, what type of file it processes,
to use a sensible set of allowed prefix chars -- but how?  

The given example "bigfile" had no suffix in the file name, the first
line wasn't starting with "diff" or something else saying "hey look,
I'm a diff file" and the local variables list, which normally is a way
to tell emacs "don't guess, just use FOO mode" is not meant to be
interpreted...

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Juri Linkov]

>> One idea is to restrict what strings can be used as the "prefix"
>> in a local variables list, so that local variables lists in diff output
>> are not obeyed.
>
> I'm afraid it won't be that easy.  Typical prefix chars in diffs are
> "-", "+" and "!" most (all?) of them are used for comments in some
> languages (eg. Ada, Postscript).  Even worse: context lines aren't
> prefixed at all.

One quite reliable solution is to store the original values of
prefix/suffix strings in the Local Variables section by adding new
variables `local-variables-prefix' and `local-variables-suffix', e.g.:

-/* Local Variables: */
-/* local-variables-prefix:"/* " */
-/* local-variables-suffix:" */" */
-/* mode:c */
-/* eval:(load-library "time-stamp") */
-/* eval:(make-local-variable 'write-file-hooks) */
-/* eval:(add-hook 'write-file-hooks 'time-stamp) */
-/* End: */

That way `hack-local-variables' could treat these variables specially:
by extracting their values from the Local Variables section, and testing
if they match the real prefix and suffix around the `Local Variables:'.

So the Local Variables section in the example above wouldn't be
interpreted, because the value of `local-variables-prefix' ("/* ")
is not the same as the prefix "-/* " in the diff file.

Of course, this wouldn't work with existing Local-Variables sections,
but for new sections adding these special variables would be easy
with a new command (from etc/TODO) that will make a local variables
section and write the values of `local-variables-prefix' and
`local-variables-suffix' automatically.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [christopher.ian.moore@gmail.com: Emacs very slow opening file]

[Richard M. Stallman]

    One quite reliable solution is to store the original values of
    prefix/suffix strings in the Local Variables section by adding new
    variables `local-variables-prefix' and `local-variables-suffix', e.g.:

    -/* Local Variables: */
    -/* local-variables-prefix:"/* " */
    -/* local-variables-suffix:" */" */
    -/* mode:c */

It is a good idea in principle, but adopting it would require
an annoying change for the users' files.

    Of course, this wouldn't work with existing Local-Variables sections,

All files with existing Local-Variables sections that use a prefix or
suffix would have to be changed.  We could not make them "work anyway"
since then the feature would not do its job.