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