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

[Tim X <timx@nospam.dev.null>]

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