Long pauses when opening files and other operations with emacs 23. and windows 7
killer...@gmail.com
operations cause emacs to stall for more than 10 seconds. For
example, opening a file usually causes this. display-about-screen
(ctrl-h, ctrl-a) always causes this. ctrl-g has no effect. Any
suggestions? Emacs is basically unusable.
I have cygwin installed, but not on my path. Nothing else special
about the system.
I have my $HOME set.
after looking around I tried adding (setq w32-get-true-file-attributes
nil) to my .emacs. No help there.
I am doing this with a network connection. That doesn't seem to
matter.
Keith S.
wrote:
> I recently migrated towindows7 and installed emacs 23.2.1. Many
I just upgraded from emacs 22.3 to 23.2 on Windows XP SP3, and am
having the same problem.
I do not have cygwin installed (or on my path). Even when I start
emacs with -q to bypass all startup options, I am running into the
same issue.
I do have a network drive installed, but it's not in my path, so it
shouldn't be responsible for the delays, unless emacs is trying to
scan it proactively (but inappropriately).
I've also noticed that the hang occurs when it goes to auto-save a
buffer. I've tried unloading tramp, which I know caused issues with
filename completion in the past -- no change.
I could definitely use some advice on this. Meanwhile, I'll probably
be going back to emacs22, which didn't have this problem.
Keith
Keith S.
> On May 30, 1:46 pm, "killersud...@gmail.com" <killersud...@gmail.com>
> wrote:
>
> > I recently migrated towindows7 and installed emacs 23.2.1. Many
> > operations cause emacs to stall for more than 10 seconds. For
> > example, opening a file usually causes this. display-about-screen
> > (ctrl-h, ctrl-a) always causes this. ctrl-g has no effect. Any
> > suggestions? Emacs is basically unusable.
>
> > I have cygwin installed, but not on my path. Nothing else special
> > about the system.
> > I have my $HOME set.
> > after looking around I tried adding (setq w32-get-true-file-attributes
> > nil) to my .emacs. No help there.
> > I am doing this with a network connection. That doesn't seem to
> > matter.
>
> having the same problem.
>
> I do not have cygwin installed (or on my path). Even when I start
> emacs with -q to bypass all startup options, I am running into the
> same issue.
>
> I do have a network drive installed, but it's not in my path, so it
> shouldn't be responsible for the delays, unless emacs is trying to
> scan it proactively (but inappropriately).
>
> I've also noticed that the hang occurs when it goes to auto-save a
> buffer. I've tried unloading tramp, which I know caused issues with
> filename completion in the past -- no change.
>
> I could definitely use some advice on this. Meanwhile, I'll probably
> be going back to emacs22, which didn't have this problem.
>
> Keith
Just to add to my own post -- I, too, set w32-get-true-file-attributes
to nil. It helped with some operations, like filename completion, but
there are still delays when opening (reading) or writing files into
the buffer.
Stefan Monnier
When something doesn't work right after an upgrade, a good piece of
advice is to file a bug-report about it.
In the case of Emacs, you do that with M-x report-emacs-bug RET
Stefan
Keith S.
I think it's a little too premature to file a bug. No bug is going to
get worked on if it isn't reproducible, and it's pointless to file
something until I can narrow down the scope of the potential problem.
Many other people have reported this issue, and several folks have
offered advice. For instance, setting w32-get-true-file-attributes was
certainly helpful for most of the slowdowns -- that wasn't a bug, but
a change that was documented in a very old changelog. And one that
most users, including myself, wouldn't have thought to connect with
this problem.
Right now, I think I MAY have further narrowed down the hanging
problems with opening files thanks to a clue from this blog post:
http://blog.zzamboni.org/solving-hangs-in-emacs-on-windows .
It looks like turning off font-lock-mode globally appears to have
helped. However, I've only been testing for about an hour, so it's
still a little early to say. I /do/ recall reading that emacs 23 on
Windows does some different things with fonts now, so it could simply
have something to do with that -- like the fact that I have a
surprising 323 (?!) fonts installed on this machine. Unfortunately,
Google hasn't yielded any other matches associating these slowdowns
with fonts. But if I conclude somewhat definitively that font-lock-
mode is the culprit, I may log a bug.
I upgraded to emacs 23 on another WinXP machine, and have NOT seen the
problems there. There are a handful of other differences between the
two machines that could affect file operations -- large number of
fonts, different A/V software, presence of network drives, offline
domain server vs. standalone workgroup, etc. -- so I'm still doing
process of elimination, and looking to get whatever feedback I can
from other users on the environments where they are experiencing this.
Keith
Uday S Reddy
>
> Many other people have reported this issue, and several folks have
> offered advice. For instance, setting w32-get-true-file-attributes was
> certainly helpful for most of the slowdowns -- that wasn't a bug, but
> a change that was documented in a very old changelog. And one that
> most users, including myself, wouldn't have thought to connect with
> this problem.
>
> Right now, I think I MAY have further narrowed down the hanging
> problems with opening files thanks to a clue from this blog post:
> http://blog.zzamboni.org/solving-hangs-in-emacs-on-windows .
There is an excellent set of diagnostic tools for Windows called sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb545046.aspx
Microsoft bought the company that made these tools and distributes them for
free. You can try using them to see what is going on when the hold-ups happen.
Cheers,
Uday
Keith S.
Already did that. Process Monitor clearly shows that it's taking
several seconds to read the file when the delay occurs either on the
file or the directory, but that doesn't help me narrow down what
behavior in emacs is causing it to happen, or why it only happens on
certain files (and even then, it doesn't necessarily happen on that
file if you restart emacs and open it again).