w32 emacs 21.3 problem

w32 emacs 21.3 problem

[B. T. Raven]

After getting a "Invalid VxD dynamic link error ..." on a win98
installation, I reinstalled windows (conservatively) and tried a few other
things to no avail. Pulling and replacing a memory stick fixed the win98
problem but now I see a debug backtrace instead of getting the .emacs
functionality:

Debugger entered--Lisp error: (void-variable k)
;; my comment: variable k is some artifact. There is none such in the
.emacs
  eval-buffer(#<buffer  *load*> nil "~/.emacs" nil t)
  load-with-code-conversion("d:/EMACS/.emacs" "~/.emacs" t t)
  load("~/.emacs" t t)
  #[nil "\b^[,T\x17
...

The .emacs starts with:

;; -*- coding: utf-8 -*-

and has many exotic characters in it and I suspect that I may have wiped
out some of the .nls codepage files that are needed for unicode support.
The registry, though, looks like they are still installed.

Emacs is invoked in a batch file if that makes a difference:

set HOME=D:\EMACS
D:\emacs\emacs-21.3\bin\runemacs.exe --debug-init
set HOME=

And running Alt-! and then the dos set command shows that HOME=D:\EMACS is
being set correctly in this shell so I'm reading the .emacs that I think I
am.

Before my memory problems this .emacs has been working flawlessly (mostly)
for many months.

Does any of you have any ideas on where I can start looking for a
solution?

Thanks.

Ed


--

Re: w32 emacs 21.3 problem

[robert.thorpe]

B. T. Raven wrote:
> After getting a "Invalid VxD dynamic link error ..." on a win98
> installation, I reinstalled windows (conservatively) and tried a few other
> things to no avail. Pulling and replacing a memory stick fixed the win98
> problem but now I see a debug backtrace instead of getting the .emacs
> functionality:
>
> Debugger entered--Lisp error: (void-variable k)
> ;; my comment: variable k is some artifact. There is none such in the
> .emacs
>   eval-buffer(#<buffer  *load*> nil "~/.emacs" nil t)
>   load-with-code-conversion("d:/EMACS/.emacs" "~/.emacs" t t)
>   load("~/.emacs" t t)
>   #[nil "\b^[,T\x17
> ...
>
> The .emacs starts with:
>
> ;; -*- coding: utf-8 -*-
>
> and has many exotic characters in it and I suspect that I may have wiped
> out some of the .nls codepage files that are needed for unicode support.
> The registry, though, looks like they are still installed.
>
> Emacs is invoked in a batch file if that makes a difference:
>
> set HOME=D:\EMACS
> D:\emacs\emacs-21.3\bin\runemacs.exe --debug-init
> set HOME=
>
> And running Alt-! and then the dos set command shows that HOME=D:\EMACS is
> being set correctly in this shell so I'm reading the .emacs that I think I
> am.
>
> Before my memory problems this .emacs has been working flawlessly (mostly)
> for many months.
>
> Does any of you have any ideas on where I can start looking for a
> solution?

Start by seeing if emacs -Q works, if so then it's something in your
.emacs file at least triggering the bug.

Then you can proceed by chopping your .emacs file in half.  Comment the
bottom half out, see if it works, then try with the top half commented
out.  Then split the offending half into halves and continue until you
find the line triggering the behaviour.

Re: w32 emacs 21.3 problem

[B. T. Raven]

<robert.thorpe@antenova.com> wrote in message
news:1155140985.141253.264170@i42g2000cwa.googlegroups.com...
B. T. Raven wrote:
> After getting a "Invalid VxD dynamic link error ..." on a win98
> installation, I reinstalled windows (conservatively) and tried a few
other
> things to no avail. Pulling and replacing a memory stick fixed the win98
> problem but now I see a debug backtrace instead of getting the .emacs
> functionality:
>
> Debugger entered--Lisp error: (void-variable k)
> ;; my comment: variable k is some artifact. There is none such in the
> .emacs
>   eval-buffer(#<buffer  *load*> nil "~/.emacs" nil t)
>   load-with-code-conversion("d:/EMACS/.emacs" "~/.emacs" t t)
>   load("~/.emacs" t t)
>   #[nil "\b^[,T\x17
> ...
>
> The .emacs starts with:
>
> ;; -*- coding: utf-8 -*-
>
> and has many exotic characters in it and I suspect that I may have wiped
> out some of the .nls codepage files that are needed for unicode support.
> The registry, though, looks like they are still installed.
>
> Emacs is invoked in a batch file if that makes a difference:
>
> set HOME=D:\EMACS
> D:\emacs\emacs-21.3\bin\runemacs.exe --debug-init
> set HOME=
>
> And running Alt-! and then the dos set command shows that HOME=D:\EMACS
is
> being set correctly in this shell so I'm reading the .emacs that I think
I
> am.
>
> Before my memory problems this .emacs has been working flawlessly
(mostly)
> for many months.
>
> Does any of you have any ideas on where I can start looking for a
> solution?

Start by seeing if emacs -Q works, if so then it's something in your
.emacs file at least triggering the bug.

Then you can proceed by chopping your .emacs file in half.  Comment the
bottom half out, see if it works, then try with the top half commented
out.  Then split the offending half into halves and continue until you
find the line triggering the behaviour.

Thanks, Robert. On my system I have to use -q instead of -Q
for --no-init-file. I knew that that would work since even with the bad
.emacs it would load the main program normally. I started commenting out
sections but almost right away I found a letter k and the beginning of a
line before the open paren. I had looked for space-k since I thought k had
to be a token. Alles in Ordnung now. Thanks again.

Ed.