[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argume

From: Eli Zaretskii
Subject: bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)
Date: Sat, 27 Nov 2010 10:22:08 +0200

> From: "Drew Adams" <address@hidden>
> Date: Fri, 26 Nov 2010 18:52:09 -0800
> Cc: 
> I am still seeing this systematically, including in the latest dev version,
> In GNU Emacs (i386-mingw-nt5.1.2600)
>  of 2010-11-22 on 3249CTO
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (4.4) --no-opt --cflags
> -Ic:/imagesupport/include'
> Below is a backtrace from this current version.
> One scenario that provokes the error:
> I have a standalone minibuffer frame. I bind a key in 
> `completion-list-mode-map'
> during minibuffer completion to call `describe-function' on a command name
> candidate in *Completions* that is clicked with mouse-2.  *Help*, like
> *Completions* is a special-display buffer that appears in its own frame. Input
> from *Completions* is redirected to the minibuffer.
> I do C-h f and get some candidates in *Completions*. I click one with mouse-2.
> *Help* shows its doc. I click the file-name link in *Help* to see the source
> library for the function. That's when I get the error.
> Same thing if I use a key bound in `minibuffer-must-match-map' and type a
> candidate then hit that key. Either way I see the function doc in *Help*, and
> when I click the file-name link I get the error.
> There are other ways to reproduce it.  They all involve an action during
> minibuffer completion.

Please post a complete recipe, starting with "emacs -Q", to reproduce
this problem.  Since you are unable to run Emacs under GDB and provide
a traceback which would pinpoint the locus of the error, someone else
will have to do that, and they will need this recipe.  The details you
posted are important, but they will only help once the exact place
which throws the error is identified.

> No one has tried to look into this.

That's not true.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]