help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] Workarounds for emacs on Windows 7


From: John J. Xenakis
Subject: Re: [h-e-w] Workarounds for emacs on Windows 7
Date: Thu, 10 May 2012 10:41:34 -0400

Dear Eli,

>    . "M-x report-emacs-bug RET" and describe there every detail you can
>      about the problem.  The report will give us some information you
>      failed to mention, like the version of Emacs etc.

>    . If you are using any version older than the latest pretest of Emacs
>      24, v24.0.96 as of this writing, please install the latest version
>      and see if the problem persists.  If it does, mention that in your
>      bug report (assuming you submit it before upgrading).

>    . If the problem exists in the latest pretest, try to see what Emacs
>      is doing when the problem happens.  To that end, attach GDB to it
>      and show a backtrace from all of the threads.

>    . Finally, start a separate Emacs session running "emacs -Q", and see
>      if that session also causes trouble.  If it doesn't try bisecting
>      your .emacs to see which of the optional features you use there
>      causes the problem.

Here are some additional details:

* I'm using emacs 23.4.1 on 64 bit Windows 7.

* I start emacs from a DOS command line batch file with the command
    "c:\xx\emacs-23.4\bin\runemacs" --no-splash --load c:\jx\emacs\init.el

* The same problem occurred at another client with different
  application software running on a 64-bit Windows 7 system.  (One used
  Visual Studio with C#, the other uses Eclipse with Java.  I used
  Firefox on both systems.)

* The bug has occurred about 6-10 times since last September.

* I typically have 4, 5 or more frames open, each with two or more
  windows, so I'm a very heavy GUI user.

* The bug never occurs in less than a week of uptime, and often not
  until two weeks of uptime.

* On two or three occasions, the bug was triggered when I was
  scrolling through code.

* It's the last three items that led me to propose that there's a
  16-bit or 32-bit counter that's cycling around to zero.

* I run emacs on another Windows 7 system that acts as a kind of
  server.  The problem has never occurred there, which I attribute to
  the fact that it's a server, and the GUI is seldom used.

* I also run the same version of emacs on a Windows XP system with no
  problems.

I'll be happy to report it as a bug.

However, I'm more reluctant to install non-production software,
especially since I'd have to use it for possibly two weeks, and if
anything else goes wrong then my immediate reaction would be to go
back to the production software to get work done.

What I would be willing to do, if you think it would help, is to
install the non-production software and let it run overnight running
some macro that performs a GUI simulation.  For example, the macro
could open 20 frames, open and close files, scroll through pages of
code, and so forth.

I could run the same test with both production and non-production
software, to see if there's a difference.

If this would help, please just let me know how to set up the macro so
that the GUI is properly simulated.  For example, if emacs doesn't
update the screen since it's running in a macro, then the test won't
work.

John J. Xenakis
GenerationalDynamics.com

John J. Xenakis
100 Memorial Drive Apt 8-13A
Cambridge, MA 02142
Phone: 617-864-0010
E-mail: address@hidden
Web site: http://www.GenerationalDynamics.com
Forum:    http://www.GenerationalDynamics.com/forum





reply via email to

[Prev in Thread] Current Thread [Next in Thread]