How to debug "Debugger entered--Lisp error: (void-function nil)"

How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Hi,

I am using "GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, X toolkit)"
and run VM (view mail) in it, but the error comes also with
21.4.1. 

Whenever I enable debug-on-error I get a backtrace with the
following content:

,------------------------------------------
| Debugger entered--Lisp error: (void-function nil)
|  (nil)
`------------------------------------------

How can I debug this to find the source of this problem?

It also happens most of the time when I single step in edebug
mode which makes edebug practically useless.  When running with
debug-on-error set to nil I do not see the error.

Also it seems to be there already for some time as I found other
references when googling for <<<emacs debugger entered--Lisp error:
"(void-function nil)">>>, e.g. http://tinyurl.com/yv6t2j!

Thanks,
Robert

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

newsspam5REMOVETHIS@robf.de writes:

> Hi,
>
> I am using "GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, X toolkit)"
> and run VM (view mail) in it, but the error comes also with
> 21.4.1. 
>
> Whenever I enable debug-on-error I get a backtrace with the
> following content:
>
> ,------------------------------------------
> | Debugger entered--Lisp error: (void-function nil)
> |  (nil)
> `------------------------------------------
>
> How can I debug this to find the source of this problem?
>
> It also happens most of the time when I single step in edebug
> mode which makes edebug practically useless.  When running with
> debug-on-error set to nil I do not see the error.
>
> Also it seems to be there already for some time as I found other
> references when googling for <<<emacs debugger entered--Lisp error:
> "(void-function nil)">>>, e.g. http://tinyurl.com/yv6t2j!
>
> Thanks,
> Robert

Normally you will see this error when emacs is trying to execute a symbol which
it believes is a function (i.e. because it is the first element in a list). A
common cause is some config setting where you have a list and have forgotten to
quote it. For example,

(setq x (nil "fred" 1))

where the intention is to set x to the value of the list (nil "fred" 1).
However, the list is not quoted, so emacs tries to execute the function 'nil'
with the arguements "fred" and 1. The correct way to do this is

(setq x '(nil "fred" 1))

or 

(setq x (list nil "fred" 1)

What you need to do is track down the init error in your .vm file. Normally,
the backtrace will show the call stack, but what you have copied appears to
just be the last (top) element in the stack. With the rest of the call stack
you can usually narrow down the search as it will show you what emacs was doing
prior to trying to call the void function. 

I'd suggest going through your VM config and comment out everything and then
try adding each value back, one at a time until you get the error again. 

To give you confidence it will work, I'm running VM under emacs 22. I've not
had any problems except a couple of weeks ago when a change to emacs 22 caused
problems with compiling vm (an issue with new emacs approach to printing data
structures and fixed easily once I was pointed to the solution). You should
also note that you can get some unexpecttd/odd behavior/errors if you have some
emacs code compiled with emacs 21 and you try to run it under emacs 22 (though
code compiled with emacs 22 is more likely to cause issues for emacs 21). I run
different source trees for emacs 21 and emacs 22 for this reason. 

HTH

Tim

-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Tim X <timx@nospam.dev.null> writes:
> newsspam5REMOVETHIS@robf.de writes:
>
>> Hi,
>>
>> I am using "GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, X toolkit)"
>> and run VM (view mail) in it, but the error comes also with
>> 21.4.1. 
>>
>> Whenever I enable debug-on-error I get a backtrace with the
>> following content:
>>
>> ,------------------------------------------
>> | Debugger entered--Lisp error: (void-function nil)
>> |  (nil)
>> `------------------------------------------
>>
>> How can I debug this to find the source of this problem?
>>
>> It also happens most of the time when I single step in edebug
>> mode which makes edebug practically useless.  When running with
>> debug-on-error set to nil I do not see the error.
>>
>> Also it seems to be there already for some time as I found other
>> references when googling for <<<emacs debugger entered--Lisp error:
>> "(void-function nil)">>>, e.g. http://tinyurl.com/yv6t2j!
>>
>> Thanks,
>> Robert
>
> Normally you will see this error when emacs is trying to execute a symbol which
> it believes is a function (i.e. because it is the first element in a list). A
> common cause is some config setting where you have a list and have forgotten to
> quote it. For example,
>
> (setq x (nil "fred" 1))
>
> where the intention is to set x to the value of the list (nil "fred" 1).
> However, the list is not quoted, so emacs tries to execute the function 'nil'
> with the arguements "fred" and 1. The correct way to do this is
>
> (setq x '(nil "fred" 1))
>
> or 
>
> (setq x (list nil "fred" 1)
>
> What you need to do is track down the init error in your .vm file. Normally,
> the backtrace will show the call stack, but what you have copied appears to
> just be the last (top) element in the stack. With the rest of the call stack
> you can usually narrow down the search as it will show you what emacs was doing
> prior to trying to call the void function. 

This is exactly my problem, GNU Emacs does NOT give anything more,
i.e. those two lines are all I get in my backtrace buffer.

> I'd suggest going through your VM config and comment out everything and then
> try adding each value back, one at a time until you get the error again. 

It is not in the config, it is in (my) VM sources and it does not
happen for XEmacs with the same sources and configuration.

> To give you confidence it will work, I'm running VM under emacs 22. I've not
> had any problems except a couple of weeks ago when a change to emacs 22 caused
> problems with compiling vm (an issue with new emacs approach to printing data
> structures and fixed easily once I was pointed to the solution).

Could you also point me to the solution?

... maybe I should try to get a more recent Emacs.  

> You should also note that you can get some unexpecttd/odd
> behavior/errors if you have some emacs code compiled with emacs
> 21 and you try to run it under emacs 22 (though code compiled
> with emacs 22 is more likely to cause issues for emacs 21). I
> run different source trees for emacs 21 and emacs 22 for this
> reason.

I did not knew that there are problems between 21 and 22, so far
I was only beaten by those between X and GNU Emacs, but this is
also not the source of my problem ;-/

Thanks,
Robert

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Tim X <timx@nospam.dev.null> writes:
[...]
> To give you confidence it will work, I'm running VM under emacs 22.

Just to be sure it is broken only here, could you please run:

  emacs -eval '(setq debug-on-error t)' -f vm

and tell me the exact version/revision of GNU Emacs and VM you
are using?

Many thanks,
Robert

The latest backtrace I get ... HTF can this happen in redisplay
... the latest GNU Emacs from CVS is just compiling ... 

Debugger entered--Lisp error: (void-function nil)
  (nil)
  redisplay()
  sit-for(5)
  vm-display-startup-message()
  byte-code("BYTE CODE REMOVED BY ME" [access-method folder vm-primary-inbox f vm-recognize-imap-maildrops vm-recognize-pop-maildrops string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
  vm(nil nil)
  call-interactively(vm)
  command-execute(vm)
  command-line-1(("-eval" "(setq debug-on-error t)" "-f" "vm"))
  command-line()
  normal-top-level()

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

newsspam5REMOVETHIS@robf.de writes:

> Tim X <timx@nospam.dev.null> writes:
>> newsspam5REMOVETHIS@robf.de writes:
>>
>>> Hi,
>>>
>>> I am using "GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, X toolkit)"
>>> and run VM (view mail) in it, but the error comes also with
>>> 21.4.1. 
>>>
>>> Whenever I enable debug-on-error I get a backtrace with the
>>> following content:
>>>
>>> ,------------------------------------------
>>> | Debugger entered--Lisp error: (void-function nil)
>>> |  (nil)
>>> `------------------------------------------
>>>
>>> How can I debug this to find the source of this problem?
>>>
>>> It also happens most of the time when I single step in edebug
>>> mode which makes edebug practically useless.  When running with
>>> debug-on-error set to nil I do not see the error.
>>>
>>> Also it seems to be there already for some time as I found other
>>> references when googling for <<<emacs debugger entered--Lisp error:
>>> "(void-function nil)">>>, e.g. http://tinyurl.com/yv6t2j!
>>>
>>> Thanks,
>>> Robert
>>

[snip]

>>
>> What you need to do is track down the init error in your .vm file. Normally,
>> the backtrace will show the call stack, but what you have copied appears to
>> just be the last (top) element in the stack. With the rest of the call stack
>> you can usually narrow down the search as it will show you what emacs was doing
>> prior to trying to call the void function. 
>
> This is exactly my problem, GNU Emacs does NOT give anything more,
> i.e. those two lines are all I get in my backtrace buffer.
>

hmmm. Not sure exactly what that means. Sounds like the error is happening at
the very top level of the stack, which I would have thought was 'unusual' if
the error is being generated by an add-on package rather than in the core of
emacs. 


>> I'd suggest going through your VM config and comment out everything and then
>> try adding each value back, one at a time until you get the error again. 
>
> It is not in the config, it is in (my) VM sources and it does not
> happen for XEmacs with the same sources and configuration.
>

So, your getting the same error without any .vm file? Are you certain your
xemacs and emacs source trees are totally separate and there isn't some path
shadowing going on thats giving you a mix of emacs 21 and xemacs compiled code?


>> To give you confidence it will work, I'm running VM under emacs 22. I've not
>> had any problems except a couple of weeks ago when a change to emacs 22 caused
>> problems with compiling vm (an issue with new emacs approach to printing data
>> structures and fixed easily once I was pointed to the solution).
>
> Could you also point me to the solution?
>

Sure, but I doubt its of much use. It is specific to emacs 22 and affects the
compilation of the source rather than execution. The URL for the Debian bug
report on this is 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410492

> ... maybe I should try to get a more recent Emacs.  

Well, that might help with emacs 22, being a development branch, its always
wise to checkout the latest version if you run into an issue. However, if your
getting this under emacs 21, then you probably already have the latest version
of the stable emacs branch (there hasn't been an emacs 21 update for a while). 



>> You should also note that you can get some unexpecttd/odd
>> behavior/errors if you have some emacs code compiled with emacs
>> 21 and you try to run it under emacs 22 (though code compiled
>> with emacs 22 is more likely to cause issues for emacs 21). I
>> run different source trees for emacs 21 and emacs 22 for this
>> reason.
>
> I did not knew that there are problems between 21 and 22, so far
> I was only beaten by those between X and GNU Emacs, but this is
> also not the source of my problem ;-/
>

Its a bad idea (TM) to run code under one version of emacs that was compiled
under another. For example, emacs 22 has some functions that vary slightly form
the same functions in emacs 21 and this can cause some interesting problems. 

I still suspect it is either something in your .emacs/.vm or possibly some
interaction between the VM code and another package you are loading. I have
since confirmed that I can run VM 7.19 under both emacs 21.4 and emacs 22 (CVS)
with no errors (and I've got debug on error enabled). I'm running on a Debian
testing/unstable system and have quite a lot of additional packages installed,
including a fairly customized .emacs with my own code etc. It is possible you
are hitting a bug which has been resolved in the Debian package of VM. 

One other thing to check is your VM sources. The VM author hasn't been very
active for a few years now and there are now a couple of common forks of the
original code base getting around. Even if your not running Debian, it might be
worthwhile grabbing the Debian VM source package from the unstable branch and
build it yourself? 

It may also be worthwhile posting your .emacs and .vm, just in case there is
something others may notice that may help. Also, while trying to track down the
issue, make sure your not loading any other packages that may interact with VM,
such as bbdb, supercite, trivial-cite, etc, just in case the problem isn't VM,
but something being triggered by VM. 

sorry I can't provide more specific help. Emacs 21.4 definitely works with VM
7.19 and emacs 22 will work with it once the patch to prevent the compile bug
is applied. So, all I can say is that I wold be looking for something unique to
your installation/configuration rather than a bug in emacs or vm. 

good luck

Tim

-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

newsspam5REMOVETHIS@robf.de writes:

> Tim X <timx@nospam.dev.null> writes:
> [...]
>> To give you confidence it will work, I'm running VM under emacs 22.
>
> Just to be sure it is broken only here, could you please run:
>
>   emacs -eval '(setq debug-on-error t)' -f vm
>
> and tell me the exact version/revision of GNU Emacs and VM you
> are using?
>

As I do a fair amount of elisp and have a number of my own packages I'm
developing, I always have debug on error enabled. I find it handy, despite
minor irritations such as jumping into the debugger in VM if I try to move past
the last message in the folder. However, I do not get any backtrace or error
when I start Vm under either emacs 21 or emacs 22.

I'm running VM 7.19-12 (Debian package) and GNU Emacs 22.0.95.1
(i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-03-03 on pacem,
modified by Debian


> The latest backtrace I get ... HTF can this happen in redisplay
> ... the latest GNU Emacs from CVS is just compiling ... 
>
> Debugger entered--Lisp error: (void-function nil)
>   (nil)
>   redisplay()
>   sit-for(5)
>   vm-display-startup-message()
>   byte-code("BYTE CODE REMOVED BY ME" [access-method folder vm-primary-inbox f vm-recognize-imap-maildrops vm-recognize-pop-maildrops string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
>   vm(nil nil)
>   call-interactively(vm)
>   command-execute(vm)
>   command-line-1(("-eval" "(setq debug-on-error t)" "-f" "vm"))
>   command-line()
>   normal-top-level()

What does that "BYTE-CODE REMOVED BY ME" mean? I've not seen that before and
that line doesn't look right. Maybe try something like M-x
list-load-path-shadows just to be sure your loading what you think your
loading. 

tim

-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

BTW, there is also a gnu.emacs.vm.bug group that may be able to provide more
specific assistance. 

T



-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Tim X <timx@nospam.dev.null> writes:
[...]
>> The latest backtrace I get ... HTF can this happen in redisplay
>> ... the latest GNU Emacs from CVS is just compiling ... 
>>
>> Debugger entered--Lisp error: (void-function nil)
>>   (nil)
>>   redisplay()
>>   sit-for(5)
>>   vm-display-startup-message()
>>   byte-code("BYTE CODE REMOVED BY ME" [access-method folder vm-primary-inbox f vm-recognize-imap-maildrops vm-recognize-pop-maildrops string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
>>   vm(nil nil)
>>   call-interactively(vm)
>>   command-execute(vm)
>>   command-line-1(("-eval" "(setq debug-on-error t)" "-f" "vm"))
>>   command-line()
>>   normal-top-level()
>
> What does that "BYTE-CODE REMOVED BY ME" mean?

Well, it means that I removed the binary garbage form the
backtrace ;-)

> I've not seen that before and
> that line doesn't look right. Maybe try something like M-x
> list-load-path-shadows just to be sure your loading what you think your
> loading. 

Unfortunately there are no load path shadows and no extra
packages loaded.

Thanks
Robert.


[-- Attachment #2: The backtrace with byte code included ... --]
[-- Type: application/octet-stream, Size: 2309 bytes --]

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

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

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Tim X <timx@nospam.dev.null> writes:
[...]
>>> What you need to do is track down the init error in your .vm file. Normally,
>>> the backtrace will show the call stack, but what you have copied appears to
>>> just be the last (top) element in the stack. With the rest of the call stack
>>> you can usually narrow down the search as it will show you what emacs was doing
>>> prior to trying to call the void function. 
>>
>> This is exactly my problem, GNU Emacs does NOT give anything more,
>> i.e. those two lines are all I get in my backtrace buffer.
>>
>
> hmmm. Not sure exactly what that means. Sounds like the error is happening at
> the very top level of the stack, which I would have thought was 'unusual' if
> the error is being generated by an add-on package rather than in the core of
> emacs. 

Yeah, that is really odd ;-/

>
>>> I'd suggest going through your VM config and comment out everything and then
>>> try adding each value back, one at a time until you get the error again. 
>>
>> It is not in the config, it is in (my) VM sources and it does not
>> happen for XEmacs with the same sources and configuration.
>>
>
> So, your getting the same error without any .vm file?

Yes. 

> Are you certain your xemacs and emacs source trees are totally
> separate and there isn't some path shadowing going on thats
> giving you a mix of emacs 21 and xemacs compiled code?

Definitely.

>>> To give you confidence it will work, I'm running VM under emacs 22. I've not
>>> had any problems except a couple of weeks ago when a change to emacs 22 caused
>>> problems with compiling vm (an issue with new emacs approach to printing data
>>> structures and fixed easily once I was pointed to the solution).
>>
>> Could you also point me to the solution?
>>
>
> Sure, but I doubt its of much use. It is specific to emacs 22 and affects the
> compilation of the source rather than execution. The URL for the Debian bug
> report on this is 
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410492
>
>> ... maybe I should try to get a more recent Emacs.  
>
> Well, that might help with emacs 22, being a development branch, its always
> wise to checkout the latest version if you run into an issue. However, if your
> getting this under emacs 21, then you probably already have the latest version
> of the stable emacs branch (there hasn't been an emacs 21 update for a while). 

Yeah, I still get the error.

>>> You should also note that you can get some unexpecttd/odd
>>> behavior/errors if you have some emacs code compiled with emacs
>>> 21 and you try to run it under emacs 22 (though code compiled
>>> with emacs 22 is more likely to cause issues for emacs 21). I
>>> run different source trees for emacs 21 and emacs 22 for this
>>> reason.
>>
>> I did not knew that there are problems between 21 and 22, so far
>> I was only beaten by those between X and GNU Emacs, but this is
>> also not the source of my problem ;-/
>>
>
> Its a bad idea (TM) to run code under one version of emacs that was compiled
> under another. For example, emacs 22 has some functions that vary slightly form
> the same functions in emacs 21 and this can cause some interesting problems. 
>
> I still suspect it is either something in your .emacs/.vm or possibly some
> interaction between the VM code and another package you are loading. I have
> since confirmed that I can run VM 7.19 under both emacs 21.4 and emacs 22 (CVS)
> with no errors (and I've got debug on error enabled). I'm running on a Debian
> testing/unstable system and have quite a lot of additional packages installed,
> including a fairly customized .emacs with my own code etc. It is possible you
> are hitting a bug which has been resolved in the Debian package of VM. 
>
> One other thing to check is your VM sources. The VM author hasn't been very
> active for a few years now and there are now a couple of common forks of the
> original code base getting around.

Which are the fork you know?

I am only aware of mine.

Kyle has handed over to me and I am now preparing a VM 8.0
release, but I want to sort out this problem before.

> Even if your not running Debian, it might be worthwhile
> grabbing the Debian VM source package from the unstable branch
> and build it yourself?
>
> It may also be worthwhile posting your .emacs and .vm, just in case there is
> something others may notice that may help. Also, while trying to track down the
> issue, make sure your not loading any other packages that may interact with VM,
> such as bbdb, supercite, trivial-cite, etc, just in case the problem isn't VM,
> but something being triggered by VM. 

O.K. here is my current status on this, with Debian

  emacs21/testing uptodate 21.4a+1-3
  vm/testing uptodate 7.19-11

An the ~/.emacs containing only this single line:

  (setq debug-on-error t)

When I run

  emacs21 -f vm

I get the backtrace

  Debugger entered--Lisp error: (void-function nil)
  (nil)

I am really puzzled now ...

I am running emacs under a different account than the X session
and used .XAuthority to allow it to connect to my X session.

When I run it as

  emacs21 -nw -f vm

the error does not occur.

Gosh, I should have tried the Debian packages earlier ... thanks
for tip.

Still this is odd and I do not really understand it.

> sorry I can't provide more specific help. Emacs 21.4 definitely works with VM
> 7.19 and emacs 22 will work with it once the patch to prevent the compile bug
> is applied. So, all I can say is that I wold be looking for something unique to
> your installation/configuration rather than a bug in emacs or vm. 

Hey, you gave me many good tips!

Thank you!

Robert

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Tim X <timx@nospam.dev.null> writes:
> BTW, there is also a gnu.emacs.vm.bug group that may be able to provide more
> specific assistance. 

It is basically dead and if there is someone answering to bug
reports, then it is usually me. ;-)

I was using gnu.emacs.help as it seemed to be a GNU Emacs problem
and not a VM problem to me.

Robert.

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

newsspam5REMOVETHIS@robf.de writes:
[...]
> O.K. here is my current status on this, with Debian
>
>   emacs21/testing uptodate 21.4a+1-3
>   vm/testing uptodate 7.19-11
>
> An the ~/.emacs containing only this single line:
>
>   (setq debug-on-error t)
>
> When I run
>
>   emacs21 -f vm
>
> I get the backtrace
>
>   Debugger entered--Lisp error: (void-function nil)
>   (nil)
>
> I am really puzzled now ...
>
> I am running emacs under a different account than the X session
> and used .XAuthority to allow it to connect to my X session.
>
> When I run it as
>
>   emacs21 -nw -f vm
>
> the error does not occur.
>
> Gosh, I should have tried the Debian packages earlier ... thanks
> for tip.
>
> Still this is odd and I do not really understand it.

I just verified that it is not related to a .XAuthority / xhost
issue, i.e. it also happens if I run Emacs under the user running
the X session.

I will reboot now ;-/

Robert

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

newsspam5REMOVETHIS@robf.de writes:

> Tim X <timx@nospam.dev.null> writes:
>> BTW, there is also a gnu.emacs.vm.bug group that may be able to provide more
>> specific assistance. 
>
> It is basically dead and if there is someone answering to bug
> reports, then it is usually me. ;-)
>
> I was using gnu.emacs.help as it seemed to be a GNU Emacs problem
> and not a VM problem to me.
>

Just a few more suggestions -

1. Grab the vm package from debian unstable (I think it is 7.19-12 rather than
-11). This is the very latest version for Debian, but I don't think its been
put into testing yet. 

2. You asked about other 'forks' of VM. I probably over stated things by saying
they were forks - more correctly, they are versions that have been somewhat
customized/patched rather than being apropper fork. I only realised just now
that one of them is your patched version you mailed me about a few months ago
when I was having problems with VM's handling of apple mail attachments (I
didn't recognise your name/e-mail). There is one other, which I think is also
by someone in Germany, but I cannot find the URL I thought I had.

3. You mentioned you are trying this by running vm from another account and
connecting to the account from your Xsession using xauthority to handle display
access etc. you also mentioned you tried it without running it from another
account to eliminate xauthority issues. Make sure that when you do the su to
run emacs, you are oding an su - username and not just an su. The - will ensure
your reading the propper init files for the remote account and that the shell
for the remote account is being correctly setup. You can get some 'subtle'
and difficult to track down problems with just an su rather than an su -
(though therre are plenty of times you actually want su and not su -_) A common
problem is incorrect home directory settings. With just su, the account you
have logged into will have your home dir setting, with su - it will have the
remote home setting. This can affect things such as the user mailbox location
and config files that are read etc. . 

4. From your posts, it seems you are getting the problem only when trying to
run emacs with VM under X, but not if you use -nw. This is quite interesting
and a valuable clue. This would indicate the problem is with something emacs
does under X that it does not do under a console. Some possibilities may be 

- coding systems (I seem to remember one of the backtraces you posted, the one
  with BYTE-CODE MODIFIED BY ME on one of the lines also had errors about
  coding systems and remote pop mailboxes or similar). 

- fonts and images. Maybe its something to do with the VM toolbar
  images/pixmaps? I don't use these and have that disabled in my .vm

- X resource settings

 You also mentioned you have no .vm at all. Perhaps it would be worthwhile
 creating a very basic minimalist .vm in case the probem is an uninitialised
 variable that isn't being set to a default by vm and isn't being checked for a
 value - maybe the first mail it is trying to read/display requires mime
 decoding and there is no mime decoder set etc. I mention this because I seem
 to remember getting a void function error and backtrace when I tried to start
 vm without any .vm at all. I will try to remember to move my .vm to the side
 next time I'm starting emacs and see what I get. Note also that I have a
 .vm.windows config file to. Probably not relevant, but thought I'd mention it
 anyway. 

finally, your last resort is to just start putting some (message ....) lines in
the code and narrowing down where the problem is. You can then look in
*Messages* and see where 3execution gets to before the error is thrown. It must
be pretty early in the process to get such a small backtrace. I've also found
defadvice can be useful here - you can put a defadvice wrapper wround functions
and have it print a message, which will help you narrow own where the execution
fails etc.

All of these are just shots in the dark. I'm glad you are taking over
maintenance of VM from kyle as it would be a shame to see such a useful package
fall behind due to lack of maintenance. It is a good mail reader, but needs to
be maintained to keep pace with developments in mail features etc. 

Good luck.

Tim



-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[Tim X]

I just did some experiments which may help a bit.

1. With no .vm file, I do not get any errors or backtrace UNLESS the first
message in the INBOX requires one of the external utilities for handling quoted
printable etc. However, the backtrace has more information then you are seeing
and it is fairly clear what is wrong. So, I doubt that this is the problem. 

One other point, you said that the only line in your .emacs is the one for
debug-on-error. Do you have any custom variable settings in the file as well?
Maybe there is something in there you ahve put in for another program, like
gnus, which is causing problems? 

HTH

Tim

-- 
tcross (at) rapttech dot com dot au

Re: How to debug "Debugger entered--Lisp error: (void-function nil)"

[newsspam5REMOVETHIS]

Tim X <timx@nospam.dev.null> writes:
> newsspam5REMOVETHIS@robf.de writes:
>
>> Tim X <timx@nospam.dev.null> writes:
>>> BTW, there is also a gnu.emacs.vm.bug group that may be able to provide more
>>> specific assistance. 
>>
>> It is basically dead and if there is someone answering to bug
>> reports, then it is usually me. ;-)
>>
>> I was using gnu.emacs.help as it seemed to be a GNU Emacs problem
>> and not a VM problem to me.
>>
>
> Just a few more suggestions -
>
> 1. Grab the vm package from debian unstable (I think it is 7.19-12 rather than
> -11). This is the very latest version for Debian, but I don't think its been
> put into testing yet. 
>
> 2. You asked about other 'forks' of VM. I probably over stated things by saying
> they were forks - more correctly, they are versions that have been somewhat
> customized/patched rather than being apropper fork. I only realised just now
> that one of them is your patched version you mailed me about a few months ago
> when I was having problems with VM's handling of apple mail attachments (I
> didn't recognise your name/e-mail). There is one other, which I think is also
> by someone in Germany, but I cannot find the URL I thought I had.
>
> 3. You mentioned you are trying this by running vm from another account and
> connecting to the account from your Xsession using xauthority to handle display
> access etc. you also mentioned you tried it without running it from another
> account to eliminate xauthority issues. Make sure that when you do the su to
> run emacs, you are oding an su - username and not just an su. The - will ensure
> your reading the propper init files for the remote account and that the shell
> for the remote account is being correctly setup. You can get some 'subtle'
> and difficult to track down problems with just an su rather than an su -
> (though therre are plenty of times you actually want su and not su -_) A common
> problem is incorrect home directory settings. With just su, the account you
> have logged into will have your home dir setting, with su - it will have the
> remote home setting. This can affect things such as the user mailbox location
> and config files that are read etc. . 
>
> 4. From your posts, it seems you are getting the problem only when trying to
> run emacs with VM under X, but not if you use -nw. This is quite interesting
> and a valuable clue. This would indicate the problem is with something emacs
> does under X that it does not do under a console. Some possibilities may be 
>
> - coding systems (I seem to remember one of the backtraces you posted, the one
>   with BYTE-CODE MODIFIED BY ME on one of the lines also had errors about
>   coding systems and remote pop mailboxes or similar). 
>
> - fonts and images. Maybe its something to do with the VM toolbar
>   images/pixmaps? I don't use these and have that disabled in my .vm

I here the alarm bells!

With (setq vm-use-toolbar nil) in my ~/.vm it is gone ...

Now after some more testing I found that the following in the
item spec is causing the trouble:

  ':button '(:toggle nil)

Many thanks for guiding me in finding this!

Robert.