GNU bug report logs - #1077
23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

Previous Next

Full log

Message #84 received at 1077 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 1077 <at> debbugs.gnu.org
Subject: RE: bug#670: bug#1077: 23.0.60;
	x-create-frame: (wrong-type-argument number-or-marker-p nil)
Date: Sun, 28 Nov 2010 10:42:50 -0800

> > That link let me download a file `gdb-7.2-1-mingw32-bin.tar.lzma'.
> > I have no idea what to do with such a file (LZMA).
> 
> It's a compressed tar file.  Either download an lzma.exe and tar.exe
> (or bsdtar.exe) from somewhere, or try 7zip.

I have 7zip, and that worked.  I put the binaries in my PATH.  Next time I get a
crash I should be able to use GDB, I guess.

> > > It must be some Lisp code, called directly or indirectly by
> > > x-create-frame.
> >
> > Then why doesn't the Lisp debugger have a stack frame for 
> > the Lisp function that called `<'?  I assume you're saying that
> > C calls some Lisp function _besides_ the Lisp function `<'.
> > Why doesn't that function appear in the backtrace?
> 
> Lisp debugger has no visibility into the C level.

I understand that.  But I'm not clear on how the backtrace stack is constructed.
If the error occurs in `<' (Lisp), then shouldn't Lisp know what the _Lisp_
caller of Lisp `<' was?  (You've already mentioned, I think, that C doesn't
return control to Lisp `<' directly.)

IOW, I think you're saying that C gives control back to Lisp, but to some Lisp
function other than `<', some function that (eventually) calls `<' (Lisp).  I
don't understand why that Lisp function given control from C does not appear in
the backtrace.  Why do we see only a call to `x-create-frame' and then the error
message for the (Lisp) `>' comparison?

> > I suspect that you just forgot step #5: Enter Icicle minor 
> > mode using `icy-mode'.  If you do not see the lighter `Icy' in the 
> > mode line, then you are not in Icicle mode.
> 
> No, I didn't forget step #5, and I did see `Icy' in the mode line.
> Let's hope it's the missing C-M-End.

(You should get the same behavior for `C-M-down' as for `C-M-end' in this case.
They are bound to different commands in the minibuffer completion maps, but in
this case their behavior should be the same.)

In Icicle mode I've never seen a backtrace like the one you show.  Your
backtrace shows that `down-list' was invoked.  That's the command that
`C-M-down' is bound to _globally_, in both vanilla Emacs and in Icicle mode.

But `C-M-down' is _not_ bound to `down-list' in the minibuffer completion maps
in Icicle mode.  If you are really in Icicle mode, then `C-M-down' is bound (by
default) to `icicle-next-candidate-per-mode-help' in the minibuffer completion
maps.  If it is bound to that command, then you should be able to see the
backtrace I reported when you hit `C-M-down'.

But let's stick to using `C-M-end' here.  That's bound in the minibuffer
completion maps to `icicle-help-on-next-prefix-candidate' (in Icicle mode).  For
prefix-completion (which is what `TAB' does),
`icicle-next-candidate-per-mode-help' just calls
`icicle-next-candidate-per-mode-help'.

If you want to check the bindings, you can look at
`minibuffer-local-must-match-map'.  That's the keymap used for `C-h f' (since
`describe-function' calls `completing-read' with t as REQUIRE-MATCH arg).  When
in Icicle mode, `C-h v minibuffer-local-must-match-map' should include these
lines:

(C-M-end . icicle-help-on-next-prefix-candidate)
(C-M-down . icicle-next-candidate-per-mode-help)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.