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

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

[Drew Adams]

My guess is that the error is coming from a `visibility' value of nil. And
`visibility' should probably not be nil anyway here - the frame should be
displayed visibly, presumably. There is no `visibility' parameter value given to
`x-create-frame-with-faces', so it must be coming up with that on its own when
it calls `x-create-frame'.
 
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  >(nil 0)
  x-create-frame(((visibility) (width . 100) (width . 80) (height
  . 14) (menu-bar-lines . 1) (top . 0) (left . 0) (unsplittable . t)
  (user-position . t) (vertical-scroll-bars . right) (height . 14)
  (width . 80) (unsplittable . t))) 
  x-create-frame-with-faces(((background-color . "LavenderBlush2")
  (mouse-color . "VioletRed") (cursor-color . "VioletRed") (width
  . 100) (font . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1")
  (width . 80)
  (height . 14) (mouse-color . "Yellow") (cursor-color . "Yellow")
  (menu-bar-lines . 1) (foreground-color . "Black") (background-color
  . "LightSteelBlue") (top . 0) (left . 0) (unsplittable . t)
  (user-position . t) (vertical-scroll-bars . right) (height . 14)
  (width . 80) (unsplittable . t))) 
  make-frame(((background-color . "LavenderBlush2") (mouse-color
  . "VioletRed") (cursor-color . "VioletRed") (width . 100) (font
  . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1")
  (width . 80) (height . 14) (mouse-color . "Yellow") (cursor-color
  . "Yellow") (menu-bar-lines . 1) (foreground-color . "Black")
  (background-color . "LightSteelBlue") (top . 0) (left . 0)
  (unsplittable . t) (user-position . t) (vertical-scroll-bars
  . right) (height . 14) (width . 80) (unsplittable . t))) 
  special-display-popup-frame(#<buffer *Completions*>
  ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
  (cursor-color . "VioletRed") (width . 100))) 
  1on1-display-*Completions*-frame(#<buffer *Completions*>
  ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
  (cursor-color . "VioletRed") (width . 100))) 
  apply(1on1-display-*Completions*-frame #<buffer *Completions*>
  ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
  (cursor-color . "VioletRed") (width . 100))) 
  special-display-popup-frame(#<buffer *Completions*>
  (1on1-display-*Completions*-frame ((background-color
  . "LavenderBlush2") (mouse-color . "VioletRed") (cursor-color
  . "VioletRed") (width . 100)))) 
  old-display-buffer(#<buffer *Completions*> nil nil)
  display-buffer(#<buffer *Completions*> nil nil)
  (with-output-to-temp-buffer "*Completions*" (let* (... ...) (when
  last ...) (display-completion-list ...))) 
  (if (and completions (or ... ...)) (with-output-to-temp-buffer
  "*Completions*" (let* ... ... ...)) (let (...) (when ... ...))
  (ding) (minibuffer-message (if completions "Sole completion" "No
  completions"))) 
  (let* ((string ...) (completions ...)) (message nil) (if (and
  completions ...) (with-output-to-temp-buffer "*Completions*" ...)
  (let ... ...) (ding) (minibuffer-message ...)) nil) 
  minibuffer-completion-help()
  (if (case completion-auto-help (lazy ...) (t completion-auto-help))
  (minibuffer-completion-help) (minibuffer-message "Next char not
  unique")) 
  (cond ((not exact) (if ... ... ...)) ((eq this-command last-command)
  (if completion-auto-help ...))) 
  (if completed nil (cond (... ...) (... ...)))
  (unless completed (cond (... ...) (... ...)))
  (let ((exact ...)) (unless completed (cond ... ...))
  (minibuffer--bitset completed t exact)) 
  (if (not (or unchanged completed)) (completion--do-completion
  try-completion-function) (let (...) (unless completed ...)
  (minibuffer--bitset completed t exact))) 
  (let* ((comp-pos ...) (completion ...) (completed ...) (unchanged
  ...)) (unless unchanged (goto-char end) (insert completion)
  (delete-region beg end)) (goto-char (+ beg comp-pos)) (if (not ...)
  (completion--do-completion try-completion-function) (let
  ... ... ...))) 
  (cond ((null comp) (ding) (minibuffer-message "No match")
  (minibuffer--bitset nil nil nil)) ((eq t comp) (minibuffer--bitset
  nil nil t)) (t (let* ... ... ... ...))) 
  (let* ((beg ...) (end ...) (string ...) (comp ...)) (cond
  (... ... ... ...) (... ...) (t ...))) 
  completion--do-completion()
  (let ((--cl-var-- ...)) (cond (... nil) (... ... ... t)
  (... ... ... t) (t t))) 
  (case (completion--do-completion) (0 nil) (1 (goto-char ...)
  (minibuffer-message "Sole completion") t) (3 (goto-char ...)
  (minibuffer-message "Complete, but not unique") t) (t t)) 
  (if (window-live-p window) (with-current-buffer (window-buffer
  window) (if ... ... ...) nil) (case (completion--do-completion) (0
  nil) (1 ... ... t) (3 ... ... t) (t t))) 
  (let ((window minibuffer-scroll-window)) (if (window-live-p window)
  (with-current-buffer ... ... nil) (case ... ... ... ... ...))) 
  minibuffer-complete()
  (unwind-protect (minibuffer-complete) (delete-overlay ol))
  (let ((ol ...)) (unwind-protect (minibuffer-complete)
  (delete-overlay ol))) 
  crm-complete()
  call-interactively(crm-complete nil nil)
  read-from-minibuffer("Friends: " nil (keymap (remap keymap
  (minibuffer-completion-help . crm-completion-help)
  (minibuffer-complete-word . crm-complete-word) (minibuffer-complete
  . crm-complete) keymap (mouse-yank-secondary) (yank-pop)
  (transpose-sexps) (transpose-words) (transpose-chars)
  (reposition-window) (kill-line) (kill-paragraph)
  (backward-kill-paragraph) (backward-kill-sentence) (kill-sexp)
  (backward-kill-sexp) (kill-word) (backward-kill-word) (delete-char)
  (delete-backward-char) (backward-delete-char-untabify)
  (digit-argument) (negative-argument) (universal-argument)
  (self-insert-command)) keymap (24 keymap (124) (119)) (33554464)
  (33554433) (30) (67108923) (67108899) (67108910) (67108927)
  (67108900) (67108924) (67108960) (67108908) (67108922) (67108901)
  (67108987) (67108989) (67108905) (67108904) (67108926) (67108906)
  (67108907) (67108909) (67108990) (33554444) (12) (insert) (C-insert)
  (C-pause) (M-pause) (67108988) (67108897) (C-return) (23) (S-delete)
  (delete) (C-S-next) (C-S-prior) (C-S-down) (C-S-up) (C-S-return)
  (M-return) (C-M-return) (C-M-f1) (C-f1) (C-M-help) (C-help)
  (C-M-next) ...) nil nil nil nil) 
  (let* ((minibuffer-completion-table ...)
  (minibuffer-completion-predicate predicate)
  (minibuffer-completion-confirm ...) (crm-completion-table table)
  (map ...) (input ...)) (and def (string-equal input "") (setq input
  def)) (split-string input crm-separator)) 
  completing-read-multiple("Friends: " ("Luke " David "Robert"))
  eval((completing-read-multiple "Friends: " (quote ("Luke " David
  "Robert")))) 
  pp-eval-expression((completing-read-multiple "Friends: " (quote
  ("Luke " David "Robert")))) 
  pp-eval-last-sexp(nil)
  call-interactively(pp-eval-last-sexp nil nil)

This is my value of `special-display-buffer-names':
 
(("*Completions*" 1on1-display-*Completions*-frame
  ((background-color . "LavenderBlush2")
   (mouse-color . "VioletRed")
   (cursor-color . "VioletRed")
   (width . 100)))
 ("*Help*" 1on1-display-*Help*-frame
  ((background-color . "Thistle")
   (mouse-color . "Blue Violet")
   (cursor-color . "Blue Violet")
   (height . 40))))
 
And this is `1on1-display-*Completions*-frame':
 
(defun 1on1-display-*Completions*-frame (buf &optional args)
  "Display *Completions* buffer in its own frame.
`special-display-function' is used to do the actual displaying.
Completion input events are redirected to `1on1-minibuffer-frame'.
BUF and ARGS are the arguments to `special-display-function'."
  (let ((old-ptr-shape x-pointer-shape)
        return-window)
    (when (and 1on1-*Completions*-frame-flag
               (boundp 'x-pointer-box-spiral))
      (setq x-pointer-shape x-pointer-box-spiral))
    (setq return-window
          (select-window
           (funcall special-display-function buf args)))
    (when (fboundp 'zoom-frm-out)
      (condition-case nil
          (progn (zoom-frm-out) (zoom-frm-out))
        (error nil)))
    
    ;; We reposition frame this way, instead of binding
    ;; `special-display-frame-alist' with this value, because
    ;; `after-make-frame-functions' might resize frame.
    (when 1on1-*Completions*-frame-at-right-flag
      (modify-frame-parameters
       (selected-frame)
       `((left . ,(- (x-display-pixel-width)
                     (+ (frame-pixel-width) 7))))))
    (raise-frame)
    (when (boundp '1on1-minibuffer-frame)
      (redirect-frame-focus
         (selected-frame)
         1on1-minibuffer-frame))
    (when (and 1on1-*Completions*-frame-flag
               (boundp 'x-pointer-box-spiral))
      (setq x-pointer-shape old-ptr-shape))
    return-window))
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-10-03 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

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

[Drew Adams]

No, I take back my guess about `visibility'. Just evaluating

(x-create-frame ((visibility) (width . 100) (width . 80) (height . 14)
(menu-bar-lines . 1) (top . 0) (left . 0) (unsplittable . t) (user-position . t)
(vertical-scroll-bars . right) (height . 14) (width . 80) (unsplittable . t)))

does not necessarily lead to the bug (error).

Something is happening inside `x-create-frame' -
for some reason, it tries to do (> nil 0).


> From: Drew Adams Sent: Friday, October 03, 2008 10:23 AM
> 
> My guess is that the error is coming from a `visibility' 
> value of nil. And `visibility' should probably not be nil anyway
> here - the frame should be displayed visibly, presumably. There is
> no `visibility' parameter value given to `x-create-frame-with-faces',
> so it must be coming up with that on its own when it calls
> `x-create-frame'.
>  
> Debugger entered--Lisp error: (wrong-type-argument 
> number-or-marker-p nil)
>   >(nil 0)
>   x-create-frame(((visibility) (width . 100) (width . 80) (height
>   . 14) (menu-bar-lines . 1) (top . 0) (left . 0) (unsplittable . t)
>   (user-position . t) (vertical-scroll-bars . right) (height . 14)
>   (width . 80) (unsplittable . t))) 
>   x-create-frame-with-faces(((background-color . "LavenderBlush2")
>   (mouse-color . "VioletRed") (cursor-color . "VioletRed") (width
>   . 100) (font . "-*-Lucida 
> Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1")
>   (width . 80)
>   (height . 14) (mouse-color . "Yellow") (cursor-color . "Yellow")
>   (menu-bar-lines . 1) (foreground-color . "Black") (background-color
>   . "LightSteelBlue") (top . 0) (left . 0) (unsplittable . t)
>   (user-position . t) (vertical-scroll-bars . right) (height . 14)
>   (width . 80) (unsplittable . t))) 
>   make-frame(((background-color . "LavenderBlush2") (mouse-color
>   . "VioletRed") (cursor-color . "VioletRed") (width . 100) (font
>   . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1")
>   (width . 80) (height . 14) (mouse-color . "Yellow") (cursor-color
>   . "Yellow") (menu-bar-lines . 1) (foreground-color . "Black")
>   (background-color . "LightSteelBlue") (top . 0) (left . 0)
>   (unsplittable . t) (user-position . t) (vertical-scroll-bars
>   . right) (height . 14) (width . 80) (unsplittable . t))) 
>   special-display-popup-frame(#<buffer *Completions*>
>   ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
>   (cursor-color . "VioletRed") (width . 100))) 
>   1on1-display-*Completions*-frame(#<buffer *Completions*>
>   ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
>   (cursor-color . "VioletRed") (width . 100))) 
>   apply(1on1-display-*Completions*-frame #<buffer *Completions*>
>   ((background-color . "LavenderBlush2") (mouse-color . "VioletRed")
>   (cursor-color . "VioletRed") (width . 100))) 
>   special-display-popup-frame(#<buffer *Completions*>
>   (1on1-display-*Completions*-frame ((background-color
>   . "LavenderBlush2") (mouse-color . "VioletRed") (cursor-color
>   . "VioletRed") (width . 100)))) 
>   old-display-buffer(#<buffer *Completions*> nil nil)
>   display-buffer(#<buffer *Completions*> nil nil)
>   (with-output-to-temp-buffer "*Completions*" (let* (... ...) (when
>   last ...) (display-completion-list ...))) 
>   (if (and completions (or ... ...)) (with-output-to-temp-buffer
>   "*Completions*" (let* ... ... ...)) (let (...) (when ... ...))
>   (ding) (minibuffer-message (if completions "Sole completion" "No
>   completions"))) 
>   (let* ((string ...) (completions ...)) (message nil) (if (and
>   completions ...) (with-output-to-temp-buffer "*Completions*" ...)
>   (let ... ...) (ding) (minibuffer-message ...)) nil) 
>   minibuffer-completion-help()
>   (if (case completion-auto-help (lazy ...) (t completion-auto-help))
>   (minibuffer-completion-help) (minibuffer-message "Next char not
>   unique")) 
>   (cond ((not exact) (if ... ... ...)) ((eq this-command last-command)
>   (if completion-auto-help ...))) 
>   (if completed nil (cond (... ...) (... ...)))
>   (unless completed (cond (... ...) (... ...)))
>   (let ((exact ...)) (unless completed (cond ... ...))
>   (minibuffer--bitset completed t exact)) 
>   (if (not (or unchanged completed)) (completion--do-completion
>   try-completion-function) (let (...) (unless completed ...)
>   (minibuffer--bitset completed t exact))) 
>   (let* ((comp-pos ...) (completion ...) (completed ...) (unchanged
>   ...)) (unless unchanged (goto-char end) (insert completion)
>   (delete-region beg end)) (goto-char (+ beg comp-pos)) (if (not ...)
>   (completion--do-completion try-completion-function) (let
>   ... ... ...))) 
>   (cond ((null comp) (ding) (minibuffer-message "No match")
>   (minibuffer--bitset nil nil nil)) ((eq t comp) (minibuffer--bitset
>   nil nil t)) (t (let* ... ... ... ...))) 
>   (let* ((beg ...) (end ...) (string ...) (comp ...)) (cond
>   (... ... ... ...) (... ...) (t ...))) 
>   completion--do-completion()
>   (let ((--cl-var-- ...)) (cond (... nil) (... ... ... t)
>   (... ... ... t) (t t))) 
>   (case (completion--do-completion) (0 nil) (1 (goto-char ...)
>   (minibuffer-message "Sole completion") t) (3 (goto-char ...)
>   (minibuffer-message "Complete, but not unique") t) (t t)) 
>   (if (window-live-p window) (with-current-buffer (window-buffer
>   window) (if ... ... ...) nil) (case (completion--do-completion) (0
>   nil) (1 ... ... t) (3 ... ... t) (t t))) 
>   (let ((window minibuffer-scroll-window)) (if (window-live-p window)
>   (with-current-buffer ... ... nil) (case ... ... ... ... ...))) 
>   minibuffer-complete()
>   (unwind-protect (minibuffer-complete) (delete-overlay ol))
>   (let ((ol ...)) (unwind-protect (minibuffer-complete)
>   (delete-overlay ol))) 
>   crm-complete()
>   call-interactively(crm-complete nil nil)
>   read-from-minibuffer("Friends: " nil (keymap (remap keymap
>   (minibuffer-completion-help . crm-completion-help)
>   (minibuffer-complete-word . crm-complete-word) (minibuffer-complete
>   . crm-complete) keymap (mouse-yank-secondary) (yank-pop)
>   (transpose-sexps) (transpose-words) (transpose-chars)
>   (reposition-window) (kill-line) (kill-paragraph)
>   (backward-kill-paragraph) (backward-kill-sentence) (kill-sexp)
>   (backward-kill-sexp) (kill-word) (backward-kill-word) (delete-char)
>   (delete-backward-char) (backward-delete-char-untabify)
>   (digit-argument) (negative-argument) (universal-argument)
>   (self-insert-command)) keymap (24 keymap (124) (119)) (33554464)
>   (33554433) (30) (67108923) (67108899) (67108910) (67108927)
>   (67108900) (67108924) (67108960) (67108908) (67108922) (67108901)
>   (67108987) (67108989) (67108905) (67108904) (67108926) (67108906)
>   (67108907) (67108909) (67108990) (33554444) (12) (insert) (C-insert)
>   (C-pause) (M-pause) (67108988) (67108897) (C-return) (23) (S-delete)
>   (delete) (C-S-next) (C-S-prior) (C-S-down) (C-S-up) (C-S-return)
>   (M-return) (C-M-return) (C-M-f1) (C-f1) (C-M-help) (C-help)
>   (C-M-next) ...) nil nil nil nil) 
>   (let* ((minibuffer-completion-table ...)
>   (minibuffer-completion-predicate predicate)
>   (minibuffer-completion-confirm ...) (crm-completion-table table)
>   (map ...) (input ...)) (and def (string-equal input "") (setq input
>   def)) (split-string input crm-separator)) 
>   completing-read-multiple("Friends: " ("Luke " David "Robert"))
>   eval((completing-read-multiple "Friends: " (quote ("Luke " David
>   "Robert")))) 
>   pp-eval-expression((completing-read-multiple "Friends: " (quote
>   ("Luke " David "Robert")))) 
>   pp-eval-last-sexp(nil)
>   call-interactively(pp-eval-last-sexp nil nil)
> 
> This is my value of `special-display-buffer-names':
>  
> (("*Completions*" 1on1-display-*Completions*-frame
>   ((background-color . "LavenderBlush2")
>    (mouse-color . "VioletRed")
>    (cursor-color . "VioletRed")
>    (width . 100)))
>  ("*Help*" 1on1-display-*Help*-frame
>   ((background-color . "Thistle")
>    (mouse-color . "Blue Violet")
>    (cursor-color . "Blue Violet")
>    (height . 40))))
>  
> And this is `1on1-display-*Completions*-frame':
>  
> (defun 1on1-display-*Completions*-frame (buf &optional args)
>   "Display *Completions* buffer in its own frame.
> `special-display-function' is used to do the actual displaying.
> Completion input events are redirected to `1on1-minibuffer-frame'.
> BUF and ARGS are the arguments to `special-display-function'."
>   (let ((old-ptr-shape x-pointer-shape)
>         return-window)
>     (when (and 1on1-*Completions*-frame-flag
>                (boundp 'x-pointer-box-spiral))
>       (setq x-pointer-shape x-pointer-box-spiral))
>     (setq return-window
>           (select-window
>            (funcall special-display-function buf args)))
>     (when (fboundp 'zoom-frm-out)
>       (condition-case nil
>           (progn (zoom-frm-out) (zoom-frm-out))
>         (error nil)))
>     
>     ;; We reposition frame this way, instead of binding
>     ;; `special-display-frame-alist' with this value, because
>     ;; `after-make-frame-functions' might resize frame.
>     (when 1on1-*Completions*-frame-at-right-flag
>       (modify-frame-parameters
>        (selected-frame)
>        `((left . ,(- (x-display-pixel-width)
>                      (+ (frame-pixel-width) 7))))))
>     (raise-frame)
>     (when (boundp '1on1-minibuffer-frame)
>       (redirect-frame-focus
>          (selected-frame)
>          1on1-minibuffer-frame))
>     (when (and 1on1-*Completions*-frame-flag
>                (boundp 'x-pointer-box-spiral))
>       (setq x-pointer-shape old-ptr-shape))
>     return-window))
>  
> 
> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>  of 2008-10-03 on LENNART-69DE564
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --no-opt 
> --cflags -Ic:/g/include
> -fno-crossjumping'
>  
> 
> 
> 
> 
> 
> 

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

[Drew Adams]

I don't think I received Yidong's reply of 2008-10-15 for some reason, but I see
it now in the bug database:

> Please run Emacs under a debugger, set a breakpoint at `error',
> trigger the error, and get a backtrace.

I don't know how to do that, and I do not have the C source code anyway, in
general.

I looked at the latest w32fns.c in CVS, however, trying to find a `>' test in
x-create-frame, but I didn't make any progress. I even tried diffing with the
Emacs 22 version of w32fns.c (which works), but there were too many diffs to see
what might be the problem. 

Can't someone please check the x-create-frame code and see where the problem
might be? I'm afraid that the Lisp backtrace I sent is all I can offer. This is
happening in a call to special-display-popup-frame.

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

[Drew Adams]

> From: Drew Adams Sent: Saturday, November 22, 2008 8:47 AM
> I don't think I received Yidong's reply of 2008-10-15 for 
> some reason, but I see it now in the bug database:
> 
> > Please run Emacs under a debugger, set a breakpoint at `error',
> > trigger the error, and get a backtrace.
> 
> I don't know how to do that, and I do not have the C source 
> code anyway, in general.
> 
> I looked at the latest w32fns.c in CVS, however, trying to 
> find a `>' test in x-create-frame, but I didn't make any
> progress. I even tried diffing with the Emacs 22 version of
> w32fns.c (which works), but there were too many diffs to see
> what might be the problem. 
> 
> Can't someone please check the x-create-frame code and see 
> where the problem might be? I'm afraid that the Lisp
> backtrace I sent is all I can offer. This is
> happening in a call to special-display-popup-frame.

I am still seeing this in 23.1 (the release):

 In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.4)'

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  >(nil 0)
  x-create-frame(((visibility) (width . 80) (height . 14) (menu-bar-lines . 1)
(top . 0) (left . 0) (unsplittable . t) (user-position . t)
(vertical-scroll-bars . right) (height . 14) (width . 80) (unsplittable . t)))
  x-create-frame-with-faces(((font . "-*-Lucida
Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1") (width . 80) (height . 14)
(mouse-color . "Yellow") (cursor-color . "Yellow") (menu-bar-lines . 1)
(foreground-color . "Black") (background-color . "LightSteelBlue") (top . 0)
(left . 0) (unsplittable . t) (user-position . t) (vertical-scroll-bars . right)
(height . 14) (width . 80) (unsplittable . t)))
  make-frame(((font . "-*-Lucida
Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1") (width . 80) (height . 14)
(mouse-color . "Yellow") (cursor-color . "Yellow") (menu-bar-lines . 1)
(foreground-color . "Black") (background-color . "LightSteelBlue") (top . 0)
(left . 0) (unsplittable . t) (user-position . t) (vertical-scroll-bars . right)
(height . 14) (width . 80) (unsplittable . t)))
  special-display-popup-frame(#<buffer *Messages*> nil)
  display-buffer(#<buffer *Messages*>)
  mouse-drag-region((down-mouse-1 (#<window 6 on  *Minibuf-0*> 1 (391 . 18)
-136706397 nil 1 (43 . 0) nil (391 . 18) (9 . 15))))
  call-interactively(mouse-drag-region nil nil)

Can no one check the x-create-frame code to see what the problem might be?

I'm using a standalone minibuffer frame.

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

[Drew Adams]

I am still seeing this systematically, including in the latest dev version,

In GNU Emacs 24.0.50.1 (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.

Another clue, perhaps: I get this error when I do something in the minibuffer
(invoke some function) that tries to create a frame.  For example, if the *Help*
frame doesn't already exist when I hit the key mentioned above to show the
output from `describe-function' (for some completion candidate) in *Help*, then
I get the error when it tries to create the *Help* frame.

I tried to follow `display-buffer' in the debugger.  I can't get further than
the C-code call to x-create-frame.  If you look at the date when I originally
filed this bug you should be able to see when some change was made to the
x-create-frame C-code that introduced this regression.  At least you should be
able to see some code in x-create-frame or called from it that tries to test (>
SOMETHING1 SOMETHING2), which ends up calling (> nil 0), raising the error.  I
tried ediffing the Emacs 22.1 C code for x-create-frame against the current C
code for it, but I couldn't guess anything (that single function definition
alone is over 12,000 chars!).

It's been this way since Emacs 23 (even pretests for 23).  No one has tried to
look into this.

-----------------------

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  >(nil 0)
  x-create-frame(((visibility) (tool-bar-lines . 0) (fringe . 0) (right-fringe .
0) (left-fringe . 0) (icon-type) (vertical-scroll-bars . right) (user-position .
t) (minibuffer) (height . 35) (width . 80) (left . 0) (top . 0) (menu-bar-lines
. 1) (cursor-type . bar)))
  x-create-frame-with-faces(((tool-bar-lines . 0) (fringe . 0) (right-fringe .
0) (left-fringe . 0) (icon-type) (vertical-scroll-bars . right) (user-position .
t) (minibuffer) (height . 35) (width . 80) (left . 0) (top . 0) (menu-bar-lines
. 1) (cursor-type . bar) (cursor-color . "Red") (mouse-color . "Red") (font .
"-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1") (background-color .
"LightBlue") (foreground-color . "Black")))
  make-frame(nil)
  (lambda nil (make-frame pop-up-frame-alist))()
  funcall((lambda nil (make-frame pop-up-frame-alist)))
  (frame-selected-window (funcall pop-up-frame-function))
  (let ((win (frame-selected-window (funcall pop-up-frame-function))))
(window--display-buffer-2 buffer win display-buffer-mark-dedicated))
  (cond ((not (buffer-live-p buffer)) (error "No such buffer %s" buffer))
(display-buffer-function (funcall display-buffer-function buffer
not-this-window)) ((and (not not-this-window) (eq (window-buffer
(selected-window)) buffer)) (window--display-buffer-1 (selected-window))) ((and
can-use-selected-window (same-window-p name-of-buffer))
(window--display-buffer-2 buffer (selected-window))) ((let ((frames (or frame
(and (or use-pop-up-frames display-buffer-reuse-frames ...) 0)
(last-nonminibuffer-frame)))) (setq window-to-use (catch (quote found) (dolist
(window (get-buffer-window-list buffer ... frames)) (when (or
can-use-selected-window ...) (throw ... window)))))) (window--display-buffer-1
window-to-use)) ((and special-display-function (let ((pars (special-display-p
name-of-buffer))) (when pars (funcall special-display-function buffer (if (listp
pars) pars)))))) ((or use-pop-up-frames (not frame-to-use)) (let ((win
(frame-selected-window (funcall pop-up-frame-function))))
(window--display-buffer-2 buffer win display-buffer-mark-dedicated))) ((and
pop-up-windows (or (not (frame-parameter frame-to-use (quote unsplittable)))
(and (eq frame-to-use (selected-frame)) (setq frame-to-use
(last-nonminibuffer-frame)) (window--frame-usable-p frame-to-use) (not
(frame-parameter frame-to-use (quote unsplittable))))) (setq window-to-use (or
(window--try-to-split-window (get-largest-window frame-to-use t))
(window--try-to-split-window (get-lru-window frame-to-use t)))))
(window--display-buffer-2 buffer window-to-use display-buffer-mark-dedicated))
((let ((window-to-undedicate (and not-this-window (not (window-dedicated-p))
(set-window-dedicated-p (selected-window) t) (selected-window))))
(unwind-protect (setq window-to-use (or (get-lru-window frame-to-use) (let (...)
(unless ... window)) (get-largest-window (quote visible)) (let (...) (unless ...
window)) (get-largest-window 0) (frame-selected-window (funcall
pop-up-frame-function)))) (when (window-live-p window-to-undedicate)
(set-window-dedicated-p window-to-undedicate nil))))
(window--even-window-heights window-to-use) (window--display-buffer-2 buffer
window-to-use)))
  (let* ((can-use-selected-window (not (or not-this-window (window-dedicated-p
(selected-window)) (window-minibuffer-p)))) (buffer (if (bufferp buffer-or-name)
buffer-or-name (get-buffer buffer-or-name))) (name-of-buffer (buffer-name
buffer)) (use-pop-up-frames (if (eq pop-up-frames (quote graphic-only))
(display-graphic-p) pop-up-frames)) (frame-to-use (or (window--frame-usable-p
(selected-frame)) (window--frame-usable-p (last-nonminibuffer-frame))))
window-to-use) (cond ((not (buffer-live-p buffer)) (error "No such buffer %s"
buffer)) (display-buffer-function (funcall display-buffer-function buffer
not-this-window)) ((and (not not-this-window) (eq (window-buffer
(selected-window)) buffer)) (window--display-buffer-1 (selected-window))) ((and
can-use-selected-window (same-window-p name-of-buffer))
(window--display-buffer-2 buffer (selected-window))) ((let ((frames (or frame
(and ... 0) (last-nonminibuffer-frame)))) (setq window-to-use (catch (quote
found) (dolist (window ...) (when ... ...))))) (window--display-buffer-1
window-to-use)) ((and special-display-function (let ((pars (special-display-p
name-of-buffer))) (when pars (funcall special-display-function buffer (if ...
pars)))))) ((or use-pop-up-frames (not frame-to-use)) (let ((win
(frame-selected-window (funcall pop-up-frame-function))))
(window--display-buffer-2 buffer win display-buffer-mark-dedicated))) ((and
pop-up-windows (or (not (frame-parameter frame-to-use (quote unsplittable)))
(and (eq frame-to-use (selected-frame)) (setq frame-to-use
(last-nonminibuffer-frame)) (window--frame-usable-p frame-to-use) (not
(frame-parameter frame-to-use ...)))) (setq window-to-use (or
(window--try-to-split-window (get-largest-window frame-to-use t))
(window--try-to-split-window (get-lru-window frame-to-use t)))))
(window--display-buffer-2 buffer window-to-use display-buffer-mark-dedicated))
((let ((window-to-undedicate (and not-this-window (not ...)
(set-window-dedicated-p ... t) (selected-window)))) (unwind-protect (setq
window-to-use (or (get-lru-window frame-to-use) (let ... ...)
(get-largest-window ...) (let ... ...) (get-largest-window 0)
(frame-selected-window ...))) (when (window-live-p window-to-undedicate)
(set-window-dedicated-p window-to-undedicate nil))))
(window--even-window-heights window-to-use) (window--display-buffer-2 buffer
window-to-use))))
  display-buffer(#<buffer delim-col.el> nil)
  pop-to-buffer(#<buffer delim-col.el>)

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> 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 24.0.50.1 (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.

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

[Drew Adams]

> 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.

Please read the thread.

I don't have a complete recipe starting with emacs -Q.  I've spent hours trying
to track down this bug.  Believe me, if I had a simple -Q recipe I would have
sent it long ago.  And that would have saved me lots of time spent in the
debugger and staring at C-code diffs looking for clues.

> > No one has tried to look into this.
> That's not true.

Please read the thread.

Do you see _any_ indication there that anyone has tried to look at the C code of
the function in question, and at its changes during the time period in question?
From the beginning I pointed to that code, but I am the only one in thread to
speak about it.  I traced this as far as I can in Lisp - up to the place where
it passes the hand to C.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sat, 27 Nov 2010 08:15:17 -0800
> 
> > 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.
> 
> Please read the thread.

I did.  But I can always hope, can't I?

> I don't have a complete recipe starting with emacs -Q.  I've spent hours trying
> to track down this bug.  Believe me, if I had a simple -Q recipe I would have
> sent it long ago.  And that would have saved me lots of time spent in the
> debugger and staring at C-code diffs looking for clues.

Can you install GDB (from the MinGW site) and run Emacs under it?  If
you can install GDB, I can send instructions for how to attach it to
Emacs and set a breakpoint where we want it.  When the breakpoint
breaks, I can tell how to provide the information needed for
identifying the code which barfs.

My only other idea is to define a Lisp function `error' (which will
override the primitive) with the same signature as the primitive,
edebug-defun it, and hope that when the problem happens again, you
will be able to see from the Lisp backtrace who throws the error.

If none of the above helps, then I'm afraid the only chance to fix
this is if someone who can stumbles across the same bug.  That's
because from your descriptions it's quite clear that you have a very
complex non-default setup of how buffers are displayed in frames,
which makes the chances to reproduce this without a recipe slim at
best.

> > > No one has tried to look into this.
> > That's not true.
> 
> Please read the thread.
> 
> Do you see _any_ indication there that anyone has tried to look at the C code of
> the function in question, and at its changes during the time period in question?
> From the beginning I pointed to that code, but I am the only one in thread to
> speak about it.

The fact that you are the only one to post there does not mean no one
else tried to figure it out.  It just means no one had anything
intelligent to say about it.

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

[Drew Adams]

> Can you install GDB (from the MinGW site) and run Emacs under it?  If
> you can install GDB, I can send instructions for how to attach it to
> Emacs and set a breakpoint where we want it.  When the breakpoint
> breaks, I can tell how to provide the information needed for
> identifying the code which barfs.

(Note: there is a reproducible recipe from emacs -Q at the end.)

No, I cannot install GDB, but if you point me to a Windows binary for it I will
be glad to try that.

(I also get multiple crashes per day for the latest dev builds, so...  BTW, why
does the question asking whether I want to debug with GDB have `Yes' as the
default value if I don't have GDB installed?  That obliges users to pick up the
mouse and click `No' instead of just hitting RET.  If you try to answer `Yes'
you just get into trouble: That provokes a Microsoft error, letting you send
lots of interesting info to MS for `GNU Emacs: The extensible self-documenting
text editor'.  I.e., `Yes' => `Send Error Report' or `Don't Send'.)

> My only other idea is to define a Lisp function `error' (which will
> override the primitive) with the same signature as the primitive,
> edebug-defun it, and hope that when the problem happens again, you
> will be able to see from the Lisp backtrace who throws the error.

I did that (though I don't see how/why it would help).  I tried this:

(defun orig-error (&rest args)
  (while t (signal 'error (list (apply 'format args)))))

(defun error (&rest args)
  (apply #'orig-error args))

I tried that with each of the following variants:

1. Adding `(debug)' at the beginning of the `error' code.
2. `M-x debug-on-entry RET error RET'.
3. `M-x edebug-defun error RET'.

I also tried defining `error' without invoking the original:

(defun error (&rest args)
  (message "ERROR args: %S" args))

In all cases I got the same backtrace that I have posted before.
Apparently only Lisp calls to `error' can be so traced, which is what I would
expect.

> > Do you see _any_ indication there that anyone has tried to 
> > look at the C code of the function in question, and at its
> > changes during the time period in question?
> > From the beginning I pointed to that code, but I am the 
> > only one in thread to speak about it.
> 
> The fact that you are the only one to post there does not mean no one
> else tried to figure it out.  It just means no one had anything
> intelligent to say about it.

I guess you're speaking for yourself.  So I guess you already checked the
possible places in that code where a `>' comparison is made, and could not see
how any of them could end up trying to compare a nil arg.

I tried that (looking at all occurrences of `>' in w32fns.c).  If the problem is
really in that file (it isn't necessarily), then maybe one of the following
lines is where the error gets raised.  (I'm using the C source code from the
23.2 release.)

x_to_w32_color (but first has wrong literal number comparison):
   1033:	  if (value < 0.0 || value > 1.0)
   1075:	  while (ptr > approx && isdigit (*ptr))

x_set_border_pixel:
   1585:  if (FRAME_W32_WINDOW (f) != 0 && f->border_width > 0)

x_set_tool_bar_lines (but >=, not >, and guarded by INTEGERP):
   1760:  if (INTEGERP (value) && XINT (value) >= 0)

map_keypad_keys:
   2360:  if (virt_key < VK_CLEAR || virt_key > VK_DELETE)
   2366:  if (virt_key >= VK_PRIOR && virt_key <= VK_DOWN)

w32_wnd_proc (but comparison against literal nums != 0):
   3041:	  if (wParam > 255 || !lispy_function_keys[wParam])
   3088:		      while (--add >= 0)
   3226:      if (w32_num_mouse_buttons > 2)
   3290:      if (w32_num_mouse_buttons > 2)

x-display-visual-class (but literal comparison != 0):
   4874:  else if (dpyinfo->n_planes * dpyinfo->n_cbits > 8)

x-close-connection:
   5067:  if (dpyinfo->reference_count > 0)

hourglass_started:
   5268:      && XINT (Vhourglass_delay) > 0)
   5271:	   && XFLOAT_DATA (Vhourglass_delay) > 0)

x-show-tip:
   5867:      && XINT (XCAR (Vx_max_tooltip_size)) > 0
   5869:      && XINT (XCDR (Vx_max_tooltip_size)) > 0)

x-file-dialog (but wrong literal comparison):
   6139:    if (w32_major_version > 4 && w32_major_version < 95)

w32-send-sys-command (but wrong literal comparison):
   6354:      > 32)

w32_parse_hot_key (but wrong literal comparisons):
   6422:  if (vk_code < 0 || vk_code > 255)

w32-battery-status (but wrong literal comparison):
   6690:      if (system_status.BatteryLifePercent > 100)

Pruning those that test against other numerical literals than 0, etc., that
leaves only these few lines:

x_to_w32_color:
   1075:	  while (ptr > approx && isdigit (*ptr))

x_set_border_pixel:
   1585:  if (FRAME_W32_WINDOW (f) != 0 && f->border_width > 0)

map_keypad_keys:
   2360:  if (virt_key < VK_CLEAR || virt_key > VK_DELETE)
   2366:  if (virt_key >= VK_PRIOR && virt_key <= VK_DOWN)

x-close-connection:
   5067:  if (dpyinfo->reference_count > 0)

hourglass_started:
   5268:      && XINT (Vhourglass_delay) > 0)
   5271:	   && XFLOAT_DATA (Vhourglass_delay) > 0)

x-show-tip:
   5867:      && XINT (XCAR (Vx_max_tooltip_size)) > 0
   5869:      && XINT (XCDR (Vx_max_tooltip_size)) > 0)

It is possible that the problematic code is in a different file, called by
something from this file.  But those few locations above might be a good place
to start checking.  Noticing the last one, I tried enabling tooltip-mode
(normally I have it disabled), but the problem remained.

----

If you want a reproducible test case from emacs -Q, here is one.  It requires
that you download some files, but nothing else special.

1. Download the Icicles files and the following libraries, from Emacs wiki.
http://www.emacswiki.org/emacs/hexrgb.el
http://www.emacswiki.org/emacs/oneonone.el
http://www.emacswiki.org/emacs/icicles.el
http://www.emacswiki.org/emacs/icicles-cmd1.el
http://www.emacswiki.org/emacs/icicles-cmd2.el
http://www.emacswiki.org/emacs/icicles-face.el
http://www.emacswiki.org/emacs/icicles-fn.el
http://www.emacswiki.org/emacs/icicles-mac.el
http://www.emacswiki.org/emacs/icicles-mcmd.el
http://www.emacswiki.org/emacs/icicles-mode.el
http://www.emacswiki.org/emacs/icicles-opt.el
http://www.emacswiki.org/emacs/icicles-var.el

2. Run this command starting in the directory where you put the libraries (e.g.
make a Windows shortcut):

runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"

3. M-: (add-to-list 'load-path ".")

4. M-x load-library icicles

5. M-x icy-mode

6. M-: (setq debug-on-error  t)

7. C-h f  f o r w  TAB down down C-M-down

That should be enough to bring up the backtrace.

#6 is a key step.  If you don't do #6, or if after provoking the error you do
(setq debug-on-error nil) and then try step #7 again, there is no problem. So it
seems that the error in question is one that is ignored (e.g. via
condition-case) unless debug-on-error is t.  When that is non-nil, Emacs tries
to show the *Backtrace* buffer in a new frame. Dunno whether that is the frame
creation for *Backtrace* that is problematic.  From experimenting, it seems it
can be any new frame.

FYI: You can use C-g to cancel out of completing.  For testing, you might want
to kill buffers *Help* and *Backtrace* after one test, before the next (that
should also remove their frames).

Dunno if that is needed, but sometimes the error does not show up even with
`debug-on-error' = nil if the frame it is trying to display (e.g. *Help*, in
particular) already exists.  (But that is not true for the *Backtrace* frame -
even if it exists already the error is raised.)  This seems to be a bug about
`x-create-frame' - if no new frame is created then no error is raised.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sat, 27 Nov 2010 15:32:49 -0800
> 
> (Note: there is a reproducible recipe from emacs -Q at the end.)

Thanks.  I tried it, but couldn't reproduce the problem.  Details
below.

> No, I cannot install GDB, but if you point me to a Windows binary for it I will
> be glad to try that.

Installing a Windows binary is what I meant.  You can find it here:

  http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/GDB-7.2/gdb-7.2-1-mingw32-bin.tar.lzma/download

Let me know once you have it installed.

> (I also get multiple crashes per day for the latest dev builds

It would be good to know a recipe for that.  If that's impossible,
perhaps after installing GDB you will be able to provide more info.

> why does the question asking whether I want to debug with GDB have
> `Yes' as the default value if I don't have GDB installed?

Because it doesn't check whether GDB is available.  Feel free to
submit a bug report about that.

> That obliges users to pick up the mouse and click `No' instead of
> just hitting RET.

Can't you do that with arrow keys?

> If you try to answer `Yes' you just get into trouble: That provokes
> a Microsoft error, letting you send lots of interesting info to MS
> for `GNU Emacs: The extensible self-documenting text editor'.  I.e.,
> `Yes' => `Send Error Report' or `Don't Send'.)

That's the default Windows GIT debugger in action.  You can download
and install DrMinGW, a JIT debugger that knows about MinGW, from here:

  http://code.google.com/p/jrfonseca/wiki/DrMingw

and then, if you answer NO, you will get a meaningful C-level
backtrace that you can save to a text file and attach to a mail
message.

> I guess you're speaking for yourself.  So I guess you already checked the
> possible places in that code where a `>' comparison is made, and could not see
> how any of them could end up trying to compare a nil arg.

There are too many possibilities, and I couldn't easily figure out
which one of the possible code paths would be taken by x-create-frame
in your setup.  Some of them call Lisp, but I couldn't find any calls
to < from the functions thus called, probably because I didn't look in
the right places.

> I tried that (looking at all occurrences of `>' in w32fns.c).  If the problem is
> really in that file (it isn't necessarily), then maybe one of the following
> lines is where the error gets raised.  (I'm using the C source code from the
> 23.2 release.)

No, C code cannot signal a Lisp error from native C comparisons with <
or >.  It must be some Lisp code, called directly or indirectly by
x-create-frame.

> runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
> 
> 3. M-: (add-to-list 'load-path ".")
> 
> 4. M-x load-library icicles
> 
> 5. M-x icy-mode
> 
> 6. M-: (setq debug-on-error  t)
> 
> 7. C-h f  f o r w  TAB down down C-M-down

What is C-M-down?  On my Windows box I don't get any key event if I
press and hold Alt+Ctrl and type the down-arrow key.  Do you have some
non-default keyboard setup?  I used ESC C-down instead, is that the
right key? does ESC C-down trigger the bug on your machine?

Anyway, on my machine, with stock Emacs 23.2, I get a Lisp backtrace,
but a different one:

Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 31
32)
  scan-lists(28 1 -1)
  down-list(1)
  call-interactively(down-list nil nil)
  [...] <<<<<<<<<<<<<<<<<< few levels omitted here
  (setq val (completing-read (if fn ... "Describe function: ") obarray (quote fboundp) t nil nil (and fn ...)))
  (let ((fn ...) (enable-recursive-minibuffers t) val) (setq val (completing-read ... obarray ... t nil nil ...)) (list (if ... fn ...)))
  call-interactively(describe-function nil nil)

> That should be enough to bring up the backtrace.

Well, it doesn't for me, unfortunately.  I tried both Emacs 23.2 and a
recent build of 24.0.50, with the same result: I get the error about
unbalanced parentheses.

Are you sure that the exact Lisp files downloaded from the links you
posted reproduce the problem on your machine?  Maybe you have modified
versions of them.

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

[martin rudalics]

 > It must be some Lisp code, called directly or indirectly by
 > x-create-frame.

The menu-bar-lines indications appear inconsistent for stand-alone
minibuffer frames.  If I do

(let ((frame (make-frame '((minibuffer . only)))))
   (frame-parameter frame 'menu-bar-lines))

the frame I create doesn't have a menubar but the frame parameter says
there's one such line.  And in the ChangeLogs I can find

2006-03-02  Nick Roberts  <nickrob@snap.net.nz>

	* dframe.el (dframe-frame-mode): Don't burp when menu-bar-lines
	is nil.

so apparently a similar problem already occurred in the wild.

martin

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

[Eli Zaretskii]

> Date: Sun, 28 Nov 2010 10:50:50 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Drew Adams <drew.adams@oracle.com>, 1077@debbugs.gnu.org
> 
>  > It must be some Lisp code, called directly or indirectly by
>  > x-create-frame.
> 
> The menu-bar-lines indications appear inconsistent for stand-alone
> minibuffer frames.  If I do
> 
> (let ((frame (make-frame '((minibuffer . only)))))
>    (frame-parameter frame 'menu-bar-lines))
> 
> the frame I create doesn't have a menubar but the frame parameter says
> there's one such line.

Can you see how this inconsistency could explain the (> nil 0) thing
that burps?  When there's no menubar, the menu-bar-lines parameter
should be zero, not nil, right?

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

[martin rudalics]

 >> The menu-bar-lines indications appear inconsistent for stand-alone
 >> minibuffer frames.  If I do
 >>
 >> (let ((frame (make-frame '((minibuffer . only)))))
 >>    (frame-parameter frame 'menu-bar-lines))
 >>
 >> the frame I create doesn't have a menubar but the frame parameter says
 >> there's one such line.
 >
 > Can you see how this inconsistency could explain the (> nil 0) thing
 > that burps?  When there's no menubar, the menu-bar-lines parameter
 > should be zero, not nil, right?

Not from this observation whose purpose was only to point at the
inconsistency.  But from Nick's fix cited earlier I deduce that
(frame-parameter ... 'menu-bar-lines) apparently can return nil.

Looking at dframe.el I find

		(let* ((mh (dframe-frame-parameter dframe-attached-frame
						   'menu-bar-lines))
		       ...
			   (list (cons 'height (+ (or mh 0) (frame-height)))))))

so somehow mh can be nil - IIUC the value returned by
`dframe-frame-parameter' is that of `frame-parameter'.

So one would have to look at things like

(define-key menu-bar-showhide-menu [menu-bar-mode]
   `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
	      :help ,(purecopy "Turn menu-bar on/off")
	      :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))

and friends whether they could be the culprits.  But it's also
possible that Drew's code calls `frame-parameter'.

martin

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

[Drew Adams]

> > No, I cannot install GDB, but if you point me to a Windows
> > binary for it I will be glad to try that.
> 
> Installing a Windows binary is what I meant.  You can find it here:
> http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/G
> DB/GDB-7.2/gdb-7.2-1-mingw32-bin.tar.lzma/download

We must have different notions of using a Windows binary, and perhaps of a
Windows binary. ;-) (just kidding)

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).  On Windows (you've heard of
that, right Eli? - still kidding), _users_ typically download a setup.exe file
(zip that contains one), and then double-click that to launch an installer.

> Let me know once you have it installed.

Let me know whether the downloaded file gives me a Windows binary, and if so how
to use it.

> > (I also get multiple crashes per day for the latest dev builds
> 
> It would be good to know a recipe for that.  If that's impossible,
> perhaps after installing GDB you will be able to provide more info.

That's why I mentioned it in this context.  (I don't have a recipe.)

> > why does the question asking whether I want to debug with GDB have
> > `Yes' as the default value if I don't have GDB installed?
> 
> Because it doesn't check whether GDB is available.  Feel free to
> submit a bug report about that.

Done - bug #7507.

> > `Yes' => `Send Error Report' or `Don't Send'.)
> 
> That's the default Windows GIT debugger in action.  You can download
> and install DrMinGW, a JIT debugger that knows about MinGW, from here:
> 
>   http://code.google.com/p/jrfonseca/wiki/DrMingw
> 
> and then, if you answer NO, you will get a meaningful C-level
> backtrace that you can save to a text file and attach to a mail
> message.

I'll just use the GDB binary instead, if available.

> No, C code cannot signal a Lisp error from native C comparisons with <
> or >.  It must be some Lisp code, called directly or indirectly by
> x-create-frame.

Good to know.

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?

Is this another Emacs bug you'd like me to file?  (Still kidding, but ready to
file it, if you think that's a good idea.)

> > runemacs.exe -Q --debug-init -l "hexrgb.el" -l 
> "oneonone.el" -f "1on1-emacs"
> > 
> > 3. M-: (add-to-list 'load-path ".")
> > 
> > 4. M-x load-library icicles
> > 
> > 5. M-x icy-mode
> > 
> > 6. M-: (setq debug-on-error  t)
> > 
> > 7. C-h f  f o r w  TAB down down C-M-down
> 
> What is C-M-down?  On my Windows box I don't get any key event if I
> press and hold Alt+Ctrl and type the down-arrow key.

Sorry, I meant `end' (the End key), not `down' (down arrow key).

Alternatively, you can use `S-TAB next next C-M-next C-M-next...'.  That's the
Page Down key.  (I had written that originally, but (mis-)edited it to TAB and
down.)

(Actually, `C-M-down' should also work here, but I did mean `C-M-end'.)

Sorry for the recipe mistake.  But I don't think that was your problem - see
below.

> Are you sure that the exact Lisp files downloaded from the
> links you posted reproduce the problem on your machine?
> Maybe you have modified versions of them.

I'm sure. I copied the files to a new directory, and created a Windows shortcut
to open in that directory, before following the recipe.

I just tried it all again, since I modified icicles-mcmd.el slightly yesterday
(no relation to this bug).  Just so we're on the same page going forward, it
might be better if you would please download `icicles-mcmd.el' again, before
trying the recipe again.

I have never seen such a backtrace as you show.  However, trying now and _not_
doing step #5 gives me such a backtrace.  That's vanilla Emacs behavior, not
Icicles.  In vanilla Emacs, even in the minibuffer keymaps, the `down' key is
bound to `down-list'.  You are asking Emacs to go down a list but there is no
list in the minibuffer: the minibuffer input is just a function name.

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.

Thanks for your help, Eli.

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

[Drew Adams]

> But it's also possible that Drew's code calls `frame-parameter'.

I do call `frame-parameter'.  Below is a grep of the test files I pointed to.
Dunno whether any of those calls are relevant to this bug.

grep -nH -e frame-parameter *.el
icicles-cmd1.el:4419:  (cdr (assq 'name (frame-parameters (next-frame
(selected-frame))))) nil
icicles-cmd1.el:4456:      (setq fname  (frame-parameter fr 'name))
icicles-cmd1.el:4886:                (cdr (assq 'buffer-list
(frame-parameters))))
icicles-cmd2.el:329:  (lambda (font) (modify-frame-parameters orig-frame (list
(cons 'font font)))) ; Action function
icicles-cmd2.el:337:   (orig-font            (frame-parameter nil 'font))
icicles-cmd2.el:340:   (orig-menu-bar        (assq 'menu-bar-lines
(frame-parameters orig-frame))))
icicles-cmd2.el:342:  (modify-frame-parameters orig-frame (list '(menu-bar-lines
. 0)))
icicles-cmd2.el:343:  (modify-frame-parameters orig-frame (list (cons 'font
orig-font) orig-menu-bar)) ; Undo code.
icicles-cmd2.el:344:  (modify-frame-parameters orig-frame (list orig-menu-bar)))
; Last code.
icicles-cmd2.el:412:    (modify-frame-parameters
icicles-cmd2.el:417:   (orig-bg                            (frame-parameter nil
'background-color))
icicles-cmd2.el:431:  (modify-frame-parameters orig-frame (list (cons
'background-color orig-bg))) ; Undo code
icicles-cmd2.el:439:    (modify-frame-parameters
icicles-cmd2.el:444:   (orig-bg                            (frame-parameter nil
'foreground-color))
icicles-cmd2.el:458:  (modify-frame-parameters orig-frame (list (cons
'foreground-color orig-bg))) ; Undo code
icicles-mac.el:222:           (cdr (assq 'buffer-list (frame-parameters))))
icicles-mcmd.el:4845:          (modify-frame-parameters
icicles-mcmd.el:6806:                   (eq (cdr (assoc 'minibuffer
(frame-parameters this-frame)))
icicles-opt.el:1966:                       (let ((frame-bg  (cdr (assq
'background-color (frame-parameters)))))
icicles-opt.el:3115:     frame-parameters  frame-pixel-height  frame-pixel-width
frame-root-window
oneonone.el:152:;;  frame-parameter alists.  They are defined using `defvar',
not
oneonone.el:416:;;     1on1-set-minibuffer-frame-top/bottom: Rewrote with
modify-frame-parameters.
oneonone.el:423:;;     Changed some individual frame-parameter variables from
defcustom to defvar.
oneonone.el:1257:        (modify-frame-parameters 1on1-minibuffer-frame
1on1-minibuffer-frame-alist)
oneonone.el:1329:To get the frame's current cursor type, use
`frame-parameters'."
oneonone.el:1333:  (modify-frame-parameters (selected-frame) (list (cons
'cursor-type cursor-type))))
oneonone.el:1337:  (let ((type (cdr (assoc 'cursor-type (frame-parameters)))))
oneonone.el:1407:      (modify-frame-parameters
oneonone.el:1425:    (modify-frame-parameters
oneonone.el:1456:                                 (frame-parameter nil
'background-color)
oneonone.el:1469:                               (frame-parameter nil
'background-color)

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sun, 28 Nov 2010 09:26:08 -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 the former; in
that case, you first uncompress it with lzma and then untar with tar.
(Yes, I'm also angry on the MinGW folks that started to use this
compression before it's sufficiently widespread, at least on Windows,
and the available ports of Tar don't support it directly yet.)

> On Windows (you've heard of
> that, right Eli? - still kidding), _users_ typically download a setup.exe file
> (zip that contains one), and then double-click that to launch an installer.

Once you've unpacked the archive, the "installation" is just copy the
.exe files to some place on your PATH, and that's it. 

> 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 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.

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

[Drew Adams]

> > 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)

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

[Eli Zaretskii]

C-M-End _was_ the missing part.  Using it I can reproduce the problem.

Martin's guess was correct, the problem is triggered by this menu
item (from menu-bar.el):

 (define-key menu-bar-showhide-menu [menu-bar-mode]
    `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
	       :help ,(purecopy "Turn menu-bar on/off")
	       :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))

This happens when Emacs tries to build a menu bar for the new frame (I
think).

The complete C backtrace is near the end of this message.  (I used
Emacs compiled from a somewhat old revision on the trunk (101173),
because I have a branch that is built without optimizations, and it
was easy to use it for debugging this problem.  I'm saying this in
case someone would like to take a look at the current trunk sources:
be aware that the line numbers are slightly different than in the
current sources.)

I tried to find out why `(frame-parameter nil 'menu-bar-lines)'
returns nil.  If I go to frame #21, which is the call to
Fx_create_frame on w32fns.c, I see that the value of `parameters', the
frame parameters, where w32_window is called, is this:

  ((visibility) (fringe . 0) (nil . 0) (nil . 0) (nil . 1) (icon-type) (nil) (cursor-type . bar) (nil . 40) (nil . 80) (nil . 14) (nil . 1) (nil . 0) (nil . 0) (nil . t) (nil . t) (nil . right) (nil . 14) (nil . 80) (nil . t))

Confused by the many `nil's here?  That's because each call to
x_get_arg and x_default_parameter replaces its parameter name with
nil, after processing that parameter.  The original value, still
available in frame #22, is this:

 ((visibility) (fringe . 0) (right-fringe . 0) (left-fringe . 0) (tool-bar-lines . 1) (icon-type) (minibuffer) (cursor-type . bar) (height . 40) (width . 80) (height . 14) (menu-bar-lines . 1) (top . 0) (left . 0) (unsplittable . t) (user-position . t) (vertical-scroll-bars . right) (height . 14) (width . 80) (unsplittable . t))

However, down at frame #3, where the menu item is being evaluated, I
see this:

 (gdb) p selected_frame
 $9 = 49998341
 (gdb) xtype
 Lisp_Vectorlike
 PVEC_FRAME
 (gdb) xframe
 $10 = (struct frame *) 0x2faea00
 "Emacs Minibuffer"
 (gdb) p $10->param_alist
 $11 = 53110590
 (gdb) pr
 ((background-mode . light) (display-type . color) (fringe . 0) (alpha) (scroll-bar-width) (cursor-type . bar) (auto-lower) (auto-raise) (icon-type) (fullscreen) (title) (buffer-predicate) (tool-bar-lines . 1) (menu-bar-lines) (right-fringe . 0) (left-fringe . 0) (line-spacing) (screen-gamma) (border-color . "black") (cursor-color . "Black") (mouse-color . "Black") (background-color . "PaleGoldenrod") (foreground-color . "Red") (vertical-scroll-bars) (internal-border-width . 0) (border-width . 2) (font . "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1") (font-parameter . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1") (font-backend uniscribe gdi))

See that `(menu-bar-lines)'?  That looks like the culprit, doesn't it?
And it's a different frame from what we saw in Fx_create_frame, observe:

 (gdb) frame 21
 #21 0x0130ff17 in Fx_create_frame (parameters=272774838) at w32fns.c:4408
 4408      w32_window (f, window_prompting, minibuffer_only);
 (gdb) p f
 $12 = (struct frame *) 0x1058ac00
 (gdb) p $12->param_alist
 $13 = 272700038
 (gdb) pr
 (gdb)
 ((fullscreen) (title) (buffer-predicate) (tool-bar-lines . 1) (menu-bar-lines . 1) (right-fringe . 0) (left-fringe . 0) (line-spacing) (screen-gamma) (border-color . "black") (cursor-color . "Red") (mouse-color . "Red") (background-color . "LightBlue") (foreground-color . "Black") (vertical-scroll-bars . right) (internal-border-width . 0) (border-width . 2) (font . "-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1") (font-parameter . "-*-Lucida Console-normal-r-*-*-14-112-96-96-c-*-iso8859-1") (font-backend uniscribe gdi))

But down below, in frame #3, where `(frame-parameter nil 'menu-bar-lines)'
is evaluated, it _will_ use selected_frame, right?  So what's going on
here?  Any ideas are welcome.

Here's the full backtrace, for the reference:

 Breakpoint 3, wrong_type_argument (predicate=48325922, value=48269338)
     at data.c:117
 117       xsignal2 (Qwrong_type_argument, predicate, value);
 (gdb) bt
 #0  wrong_type_argument (predicate=48325922, value=48269338) at data.c:117
 #1  0x01031e99 in arithcompare (num1=48269338, num2=0, comparison=grtr)
     at data.c:2242
 #2  0x01032215 in Fgtr (num1=48269338, num2=0) at data.c:2307
 #3  0x01039cb0 in Feval (form=53019718) at eval.c:2351
 #4  0x010379d2 in internal_condition_case_1 (bfun=0x10392a5 <Feval>,
     arg=53019718, handlers=48326994,
     hfun=0x1017d61 <menu_item_eval_property_1>) at eval.c:1503
 #5  0x01017e22 in menu_item_eval_property (sexpr=53019718) at keyboard.c:7728
 #6  0x01019f9f in parse_menu_item (item=48269338, inmenubar=0)
     at keyboard.c:8005
 #7  0x011e549d in single_menu_item (key=48457402, item=53019438,
     dummy=48269338, skp_v=0x829e20) at menu.c:336
 #8  0x011c13ea in map_keymap_item (fun=0x11e547d <single_menu_item>,
     args=48269338, key=48457402, val=53019438, data=0x829e20) at keymap.c:613
 #9  0x011c19a8 in map_keymap_internal (map=274367590,
     fun=0x11e547d <single_menu_item>, args=48269338, data=0x829e20)
     at keymap.c:650
 #10 0x011c1c93 in map_keymap_canonical (map=274367590,
     fun=0x11e547d <single_menu_item>, args=48269338, data=0x829e20)
     at keymap.c:710
 #11 0x011e5314 in single_keymap_panes (keymap=52948478, pane_name=48269338,
     prefix=51388162, maxdepth=9) at menu.c:302
 #12 0x011e57bf in single_menu_item (key=51388162, item=53016798,
     dummy=48269338, skp_v=0x829fc0) at menu.c:439
 #13 0x011c13ea in map_keymap_item (fun=0x11e547d <single_menu_item>,
     args=48269338, key=51388162, val=53016798, data=0x829fc0) at keymap.c:613
 #14 0x011c19a8 in map_keymap_internal (map=273656398,
     fun=0x11e547d <single_menu_item>, args=48269338, data=0x829fc0)
     at keymap.c:650
 #15 0x011c1c93 in map_keymap_canonical (map=273656398,
     fun=0x11e547d <single_menu_item>, args=48269338, data=0x829fc0)
     at keymap.c:710
 #16 0x011e5314 in single_keymap_panes (keymap=49415702, pane_name=21049777,
     prefix=48549802, maxdepth=10) at menu.c:302
 #17 0x011e5cdf in parse_single_submenu (item_key=48549802,
     item_name=21049777, maps=48269338) at menu.c:556
 #18 0x01302b7e in set_frame_menubar (f=0x1058ac00, first_time=1, deep_p=1)
     at w32menu.c:462
 #19 0x0130318d in initialize_frame_menubar (f=0x1058ac00) at w32menu.c:630
 #20 0x0130edad in w32_window (f=0x1058ac00, window_prompting=9,
     minibuffer_only=0) at w32fns.c:4023
 #21 0x0130ff17 in Fx_create_frame (parameters=272774838) at w32fns.c:4408
 #22 0x0103bbd7 in Ffuncall (nargs=2, args=0x82a5f0) at eval.c:2983
 #23 0x01285518 in Fbyte_code (bytestr=20509393, vector=20509517, maxdepth=20)
     at bytecode.c:679
 #24 0x0103c943 in funcall_lambda (fun=20509357, nargs=1, arg_vector=0x82a834)
     at eval.c:3165
 #25 0x0103c15e in Ffuncall (nargs=2, args=0x82a830) at eval.c:3029
 #26 0x01285518 in Fbyte_code (bytestr=20899473, vector=20899637, maxdepth=24)
     at bytecode.c:679
 #27 0x0103c943 in funcall_lambda (fun=20899445, nargs=1, arg_vector=0x82aa74)
     at eval.c:3165
 #28 0x0103c15e in Ffuncall (nargs=2, args=0x82aa70) at eval.c:3029
 #29 0x01285518 in Fbyte_code (bytestr=20895281, vector=20895421, maxdepth=20)
     at bytecode.c:679
 #30 0x0103c943 in funcall_lambda (fun=20895245, nargs=2, arg_vector=0x82acc4)
     at eval.c:3165
 #31 0x0103c15e in Ffuncall (nargs=3, args=0x82acc0) at eval.c:3029
 #32 0x010399d5 in Feval (form=53041086) at eval.c:2321
 #33 0x01039aa1 in Feval (form=53041094) at eval.c:2333
 #34 0x010353ea in Fsetq (args=53041102) at eval.c:494
 #35 0x010397ec in Feval (form=53041110) at eval.c:2295
 #36 0x01035249 in Fprogn (args=53041038) at eval.c:395
 #37 0x01036e34 in Flet (args=53044302) at eval.c:1051
 #38 0x010397ec in Feval (form=53044398) at eval.c:2295
 #39 0x01035249 in Fprogn (args=53040966) at eval.c:395
 #40 0x0103c828 in funcall_lambda (fun=53040958, nargs=2, arg_vector=0x82b3f8)
     at eval.c:3158
 #41 0x0103c225 in Ffuncall (nargs=3, args=0x82b3f4) at eval.c:3040
 #42 0x0103a410 in Fapply (nargs=3, args=0x82b3f4) at eval.c:2448
 #43 0x0103b822 in Ffuncall (nargs=4, args=0x82b3f0) at eval.c:2964
 #44 0x01285518 in Fbyte_code (bytestr=20895281, vector=20895421, maxdepth=20)
     at bytecode.c:679
 #45 0x0103c943 in funcall_lambda (fun=20895245, nargs=2, arg_vector=0x82b634)
     at eval.c:3165
 #46 0x0103c15e in Ffuncall (nargs=3, args=0x82b630) at eval.c:3029
 #47 0x01285518 in Fbyte_code (bytestr=20886545, vector=20886797, maxdepth=20)
     at bytecode.c:679
 #48 0x0103c943 in funcall_lambda (fun=20886501, nargs=3, arg_vector=0x82b884)
     at eval.c:3165
 #49 0x0103c15e in Ffuncall (nargs=4, args=0x82b880) at eval.c:3029
 #50 0x0103b174 in call3 (fn=48488522, arg1=274228741, arg2=48269338,
     arg3=48269338) at eval.c:2813
 #51 0x01183014 in display_buffer (buffer=274228741,
     not_this_window_p=48269338, override_frame=48269338) at window.c:3662
 #52 0x01183539 in temp_output_buffer_show (buf=274228741) at window.c:3732
 #53 0x01285f6a in Fbyte_code (bytestr=50346321, vector=274004357, maxdepth=20)
     at bytecode.c:887
 #54 0x0103c943 in funcall_lambda (fun=51707909, nargs=1, arg_vector=0x82bb58)
     at eval.c:3165
 #55 0x0103c15e in Ffuncall (nargs=2, args=0x82bb54) at eval.c:3029
 #56 0x01285518 in Fbyte_code (bytestr=270726561, vector=271226117,
     maxdepth=32) at bytecode.c:679
 #57 0x0103c943 in funcall_lambda (fun=50395237, nargs=1, arg_vector=0x82bd00)
     at eval.c:3165
 #58 0x0103c39a in apply_lambda (fun=50395237, args=271672654, eval_flag=1)
     at eval.c:3092
 #59 0x0103a1a0 in Feval (form=271672662) at eval.c:2390
 #60 0x01035249 in Fprogn (args=271672646) at eval.c:395
 #61 0x01036e34 in Flet (args=271672670) at eval.c:1051
 #62 0x010397ec in Feval (form=271672710) at eval.c:2295
 #63 0x01035249 in Fprogn (args=273762886) at eval.c:395
 #64 0x01121017 in Fsave_current_buffer (args=273762862) at editfns.c:1012
 #65 0x010397ec in Feval (form=273762854) at eval.c:2295
 #66 0x0103a291 in Feval (form=271672742) at eval.c:2406
 #67 0x01035249 in Fprogn (args=271672630) at eval.c:395
 #68 0x010351a1 in Fcond (args=271672358) at eval.c:373
 #69 0x010397ec in Feval (form=271673278) at eval.c:2295
 #70 0x01035249 in Fprogn (args=271671030) at eval.c:395
 #71 0x0103c828 in funcall_lambda (fun=271671022, nargs=1, arg_vector=0x82c4d0)
     at eval.c:3158
 #72 0x0103c39a in apply_lambda (fun=271671022, args=271673870, eval_flag=1)
     at eval.c:3092
 #73 0x0103a2bb in Feval (form=271673894) at eval.c:2408
 #74 0x01035249 in Fprogn (args=271673862) at eval.c:395
 #75 0x010351a1 in Fcond (args=271673854) at eval.c:373
 #76 0x010397ec in Feval (form=271674190) at eval.c:2295
 #77 0x01035249 in Fprogn (args=271673846) at eval.c:395
 #78 0x010351a1 in Fcond (args=271673838) at eval.c:373
 #79 0x010397ec in Feval (form=271675302) at eval.c:2295
 #80 0x01035249 in Fprogn (args=271673830) at eval.c:395
 #81 0x01036e34 in Flet (args=271623118) at eval.c:1051
 #82 0x010397ec in Feval (form=271623830) at eval.c:2295
 #83 0x01035249 in Fprogn (args=271673510) at eval.c:395
 #84 0x0103c828 in funcall_lambda (fun=271673462, nargs=0, arg_vector=0x82cc64)
     at eval.c:3158
 #85 0x0103c225 in Ffuncall (nargs=1, args=0x82cc60) at eval.c:3040
 #86 0x010399d5 in Feval (form=271574614) at eval.c:2321
 #87 0x01035249 in Fprogn (args=273763166) at eval.c:395
 #88 0x010397ec in Feval (form=273763142) at eval.c:2295
 #89 0x010374a1 in Funwind_protect (args=273763134) at eval.c:1304
 #90 0x010397ec in Feval (form=273763126) at eval.c:2295
 #91 0x01035249 in Fprogn (args=273763118) at eval.c:395
 #92 0x01121017 in Fsave_current_buffer (args=273763118) at editfns.c:1012
 #93 0x010397ec in Feval (form=273763110) at eval.c:2295
 #94 0x01035249 in Fprogn (args=273763102) at eval.c:395
 #95 0x01036e34 in Flet (args=273763094) at eval.c:1051
 #96 0x010397ec in Feval (form=273763086) at eval.c:2295
 #97 0x0103a291 in Feval (form=271574606) at eval.c:2406
 #98 0x01035249 in Fprogn (args=271574638) at eval.c:395
 #99 0x01120fcd in Fsave_excursion (args=271574638) at editfns.c:997
 #100 0x010397ec in Feval (form=271574598) at eval.c:2295
 #101 0x01035249 in Fprogn (args=271574646) at eval.c:395
 #102 0x01036e34 in Flet (args=271574590) at eval.c:1051
 #103 0x010397ec in Feval (form=271574518) at eval.c:2295
 #104 0x01035249 in Fprogn (args=271574654) at eval.c:395
 #105 0x010351a1 in Fcond (args=271574726) at eval.c:373
 #106 0x010397ec in Feval (form=271574230) at eval.c:2295
 #107 0x01035249 in Fprogn (args=271574734) at eval.c:395
 #108 0x0103c828 in funcall_lambda (fun=271574742, nargs=3,
     arg_vector=0x82d930) at eval.c:3158
 #109 0x0103c39a in apply_lambda (fun=271574742, args=271575070, eval_flag=1)
     at eval.c:3092
 #110 0x0103a2bb in Feval (form=271575046) at eval.c:2408
 #111 0x01035249 in Fprogn (args=271575110) at eval.c:395
 #112 0x0103c828 in funcall_lambda (fun=271575118, nargs=0,
     arg_vector=0x82dc24) at eval.c:3158
 #113 0x0103c225 in Ffuncall (nargs=1, args=0x82dc20) at eval.c:3040
 #114 0x0103b068 in apply1 (fn=271530586, arg=48269338) at eval.c:2749
 #115 0x0128293d in Fcall_interactively (function=271530586,
     record_flag=48269338, keys=48290565) at callint.c:376
 #116 0x0103bd17 in Ffuncall (nargs=4, args=0x82de90) at eval.c:2989
 #117 0x0103b174 in call3 (fn=48438138, arg1=271530586, arg2=48269338,
     arg3=48269338) at eval.c:2813
 #118 0x01022c05 in Fcommand_execute (cmd=271530586, record_flag=48269338,
     keys=48269338, special=48269338) at keyboard.c:10329
 #119 0x01008a25 in command_loop_1 () at keyboard.c:1732
 #120 0x010378c2 in internal_condition_case (bfun=0x1007440 <command_loop_1>,
     handlers=48326994, hfun=0x1006b75 <cmd_error>) at eval.c:1458
 #121 0x0100704b in command_loop_2 (ignore=48269338) at keyboard.c:1338
 #122 0x010372e1 in internal_catch (tag=48425154,
     func=0x1007028 <command_loop_2>, arg=48269338) at eval.c:1202
 #123 0x01006fb2 in command_loop () at keyboard.c:1303
 #124 0x01006267 in recursive_edit_1 () at keyboard.c:940
 #125 0x01251fe5 in read_minibuf (map=48258454, initial=20248241,
     prompt=271900017, backup_n=4, expflag=0, histvar=48454826, histpos=0,
     defalt=48269338, allow_props=1, inherit_input_method=0) at minibuf.c:713
 #126 0x012530b9 in Fread_from_minibuffer (prompt=271900017,
     initial_contents=272549566, keymap=48258454, sys_read=48269338,
     hist=48454826, default_value=48269338, inherit_input_method=48269338)
     at minibuf.c:1000
 #127 0x0103a052 in Feval (form=50269526) at eval.c:2370
 #128 0x01035249 in Fprogn (args=50268054) at eval.c:395
 #129 0x0103c828 in funcall_lambda (fun=50267870, nargs=7, arg_vector=0x82e4a0)
     at eval.c:3158
 #130 0x0103c39a in apply_lambda (fun=50267870, args=270485830, eval_flag=1)
     at eval.c:3092
 #131 0x0103a2bb in Feval (form=270485838) at eval.c:2408
 #132 0x010353ea in Fsetq (args=270485846) at eval.c:494
 #133 0x010397ec in Feval (form=270485854) at eval.c:2295
 #134 0x01035249 in Fprogn (args=270485334) at eval.c:395
 #135 0x01036e34 in Flet (args=270486798) at eval.c:1051
 #136 0x010397ec in Feval (form=270486870) at eval.c:2295
 #137 0x01035249 in Fprogn (args=270485094) at eval.c:395
 #138 0x0103c828 in funcall_lambda (fun=270485086, nargs=8,
     arg_vector=0x82e9f0) at eval.c:3158
 #139 0x0103c39a in apply_lambda (fun=270485086, args=270482558, eval_flag=1)
     at eval.c:3092
 #140 0x0103a2bb in Feval (form=270482566) at eval.c:2408
 #141 0x01035249 in Fprogn (args=270482494) at eval.c:395
 #142 0x010372e1 in internal_catch (tag=271087194, func=0x10351ec <Fprogn>,
     arg=270482494) at eval.c:1202
 #143 0x0103724c in Fcatch (args=270482574) at eval.c:1173
 #144 0x010397ec in Feval (form=270482598) at eval.c:2295
 #145 0x010353ea in Fsetq (args=270482606) at eval.c:494
 #146 0x010397ec in Feval (form=270482614) at eval.c:2295
 #147 0x01035249 in Fprogn (args=270482478) at eval.c:395
 #148 0x01036e34 in Flet (args=270482750) at eval.c:1051
 #149 0x010397ec in Feval (form=270482950) at eval.c:2295
 #150 0x01035249 in Fprogn (args=270482446) at eval.c:395
 #151 0x010351a1 in Fcond (args=270482438) at eval.c:373
 #152 0x010397ec in Feval (form=270483102) at eval.c:2295
 #153 0x01035249 in Fprogn (args=270482406) at eval.c:395
 #154 0x01036b30 in FletX (args=270483286) at eval.c:996
 #155 0x010397ec in Feval (form=270483510) at eval.c:2295
 #156 0x01035249 in Fprogn (args=270482350) at eval.c:395
 #157 0x0103c828 in funcall_lambda (fun=270482342, nargs=7,
     arg_vector=0x82f460) at eval.c:3158
 #158 0x0103c39a in apply_lambda (fun=270482342, args=272935534, eval_flag=1)
     at eval.c:3092
 #159 0x0103a2bb in Feval (form=272935470) at eval.c:2408
 #160 0x010353ea in Fsetq (args=272935462) at eval.c:494
 #161 0x010397ec in Feval (form=272935454) at eval.c:2295
 #162 0x01035249 in Fprogn (args=272935046) at eval.c:395
 #163 0x01036e34 in Flet (args=272935446) at eval.c:1051
 #164 0x010397ec in Feval (form=272935366) at eval.c:2295
 #165 0x012827c7 in Fcall_interactively (function=49546058,
     record_flag=48269338, keys=48290565) at callint.c:345
 #166 0x0103bd17 in Ffuncall (nargs=4, args=0x82fb80) at eval.c:2989
 #167 0x0103b174 in call3 (fn=48438138, arg1=49546058, arg2=48269338,
     arg3=48269338) at eval.c:2813
 #168 0x01022c05 in Fcommand_execute (cmd=49546058, record_flag=48269338,
     keys=48269338, special=48269338) at keyboard.c:10329
 #169 0x01008a25 in command_loop_1 () at keyboard.c:1732
 #170 0x010378c2 in internal_condition_case (bfun=0x1007440 <command_loop_1>,
     handlers=48326994, hfun=0x1006b75 <cmd_error>) at eval.c:1458
 #171 0x0100704b in command_loop_2 (ignore=48269338) at keyboard.c:1338
 #172 0x010372e1 in internal_catch (tag=48325114,
     func=0x1007028 <command_loop_2>, arg=48269338) at eval.c:1202
 #173 0x01007003 in command_loop () at keyboard.c:1317
 #174 0x01006267 in recursive_edit_1 () at keyboard.c:940
 #175 0x0100678b in Frecursive_edit () at keyboard.c:1002
 #176 0x01002aa6 in main (argc=9, argv=0xa32450) at emacs.c:1766

 Lisp Backtrace:
 ">" (0x829a90)
 "x-create-frame" (0x82a5f4)
 "x-create-frame-with-faces" (0x82a834)
 "make-frame" (0x82aa74)
 "special-display-popup-frame" (0x82acc4)
 "funcall" (0x82acc0)
 "select-window" (0x82aea0)
 "setq" (0x82afe0)
 "let" (0x82b1b0)
 "1on1-display-*Help*-frame" (0x82b3f8)
 "apply" (0x82b3f4)
 "special-display-popup-frame" (0x82b634)
 "display-buffer" (0x82b884)
 "describe-function" (0x82bb58)
 "help-xref-interned" (0x82bd00)
 "let" (0x82c040)
 "save-current-buffer" (0x82c1a0)
 "with-current-buffer" (0x82c2a0)
 "cond" (0x82c420)
 "icicle-help-on-candidate-symbol" (0x82c4d0)
 "cond" (0x82c7c0)
 "cond" (0x82c940)
 "let" (0x82cb10)
 "icicle-help-on-candidate" (0x82cc64)
 "funcall" (0x82cc60)
 "progn" (0x82ce80)
 "unwind-protect" (0x82cfa0)
 "save-current-buffer" (0x82d100)
 "let" (0x82d2d0)
 "save-selected-window" (0x82d3d0)
 "save-excursion" (0x82d530)
 "let" (0x82d700)
 "cond" (0x82d880)
 "icicle-successive-action" (0x82d930)
 "icicle-help-on-next-prefix-candidate" (0x82dc24)
 "call-interactively" (0x82de94)
 "old-read-from-minibuffer" (0x82e360)
 "read-from-minibuffer" (0x82e4a0)
 "setq" (0x82e760)
 "let" (0x82e940)
 "icicle-lisp-vanilla-completing-read" (0x82e9f0)
 "catch" (0x82ed70)
 "setq" (0x82eeb0)
 "let" (0x82f080)
 "cond" (0x82f200)
 "let*" (0x82f3b0)
 "completing-read" (0x82f460)
 "setq" (0x82f720)
 "let" (0x82f8f0)
 "call-interactively" (0x82fb84)

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

[Drew Adams]

> C-M-End _was_ the missing part.  Using it I can reproduce the problem.

I'd be very surprised if `C-M-down' doesn't do the same thing as `C-M-end', and
even more surprised if it gives the backtrace you reported earlier.  Can you
confirm?

> Martin's guess was correct, the problem is triggered by this menu
> item (from menu-bar.el)

Hoorah and thanks to you both.  Looking forward to a fix; I'm sure someone will
DTRT once this is figured out.  Thx.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sun, 28 Nov 2010 10:42:50 -0800
> 
> 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's a good idea to download the file src/.gdbinit as well, and have
it handy.  You should start GDB in the directory where you keep
.gdbinit, so that GDB will automatically read it at startup.  That
file has many useful commands that make debugging Emacs and printing
the various objects and data structures much easier.  Let me know if
you want me to send you that file, in case you have difficulties
getting it from the repository.

> > > 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.)

By now you will have seen my initial analysis of the problem, so you
know the reason: `<' was called directly from C, via the `eval'
primitive, when the code which builds the menu bar evaluated the
properties of the menu items.  IOW, I was mistaken, it's not called by
some other Lisp.

> 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'.

Maybe the reason is that I typed `ESC C-down', not C-M-down.  I don't
think it's important at this time, since C-M-End reproduces the
problem.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sun, 28 Nov 2010 11:46:53 -0800
> 
> I'd be very surprised if `C-M-down' doesn't do the same thing as `C-M-end', and
> even more surprised if it gives the backtrace you reported earlier.  Can you
> confirm?

I'm on a different machine now, and here C-M-down does produce the
same backtrace with `(> nil 0)'.  Not sure what happened on the
machine where I tried it at first.

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

[Stefan Monnier]

> 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.)

The Elisp backtrace only keeps track of Elisp function calls, so if the
C code runs a chunk of code via `eval' rather than via `funcall', there
is no function name pushed on the Elisp backtrace :-(


        Stefan

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

[Drew Adams]

> It's a good idea to download the file src/.gdbinit as well,

What's the URL?

> Let me know if you want me to send you that file, in case you
> have difficulties getting it from the repository.

I don't see any repository. I followed the link you sent earlier, and then
clicked "direct link", which was a URL directly to the zip file.  So sure,
please mail me the file (and perhaps also give me a URL to "the repository").

> By now you will have seen my initial analysis of the problem, so you
> know the reason: `<' was called directly from C, via the `eval'
> primitive, when the code which builds the menu bar evaluated the
> properties of the menu items.  IOW, I was mistaken, it's not called by
> some other Lisp.

Thanks for the clarification.  Another mystery in my mind bites the dust.

> Maybe the reason is that I typed `ESC C-down', not C-M-down.  I don't
> think it's important at this time, since C-M-End reproduces the
> problem.

Got it.  Thx.

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

[martin rudalics]

 > And it's a different frame from what we saw in Fx_create_frame, observe:
 > [...]
 > But down below, in frame #3, where `(frame-parameter nil 'menu-bar-lines)'
 > is evaluated, it _will_ use selected_frame, right?  So what's going on
 > here?  Any ideas are welcome.

Do you mean the selected frame changes in between?

Anyway, I think there are at least three other bugs:

(1) Evaluating Lisp code in `define-key' can crash Emacs.

(2) The menu-bar define-key operations to toggle `menu-bar-mode' and
     `tool-bar-mode' do not take into account that the values of the
     respective frame parameter can be nil.

(3) Frame parameters of `menu-bar-lines' and actual appearance of a
     menubar are inconsistent for minibuffer-only frames.

martin

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

[Eli Zaretskii]

> Date: Mon, 29 Nov 2010 11:56:09 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Drew Adams <drew.adams@oracle.com>, 1077@debbugs.gnu.org
> 
>  > And it's a different frame from what we saw in Fx_create_frame, observe:
>  > [...]
>  > But down below, in frame #3, where `(frame-parameter nil 'menu-bar-lines)'
>  > is evaluated, it _will_ use selected_frame, right?  So what's going on
>  > here?  Any ideas are welcome.
> 
> Do you mean the selected frame changes in between?

No.  We are in the middle of creating a new frame, remember?  The
frame that we are creating is not constructed yet, so it cannot yet
become the selected_frame.  It will become that later.  The currently
selected frame is still the minibuffer frame:

 (gdb) p selected_frame
 $9 = 49998341
 (gdb) xframe
 $10 = (struct frame *) 0x2faea00
 "Emacs Minibuffer"

The problem is that the offending menu item accesses the currently
selected frame's parameters:

 (define-key menu-bar-showhide-menu [menu-bar-mode]
    `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
	       :help ,(purecopy "Turn menu-bar on/off")
	       :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))
                                                      ^^^

The frame we are creating is not yet ready, and is certainly not yet
the selected frame!  Isn't that a bug? shouldn't we use
menu-updating-frame instead of nil, in the above call to
frame-parameter?

> Anyway, I think there are at least three other bugs:
> 
> (1) Evaluating Lisp code in `define-key' can crash Emacs.

Sorry, I don't follow: are you saying that we must not evaluate Lisp
code inside `define-key', or are you saying something else?

> 
> (2) The menu-bar define-key operations to toggle `menu-bar-mode' and
>      `tool-bar-mode' do not take into account that the values of the
>      respective frame parameter can be nil.

As you see above, this happens for the minibuffer frame.  Can you
explain how we get `(menu-bar-lines)' instead of having the usual
`(menu-bar-lines . 1)' or `(menu-bar-lines . 0)' in the parameters
alist of the minibuffer frame?  Is that normal, or is that another
bug?

> (3) Frame parameters of `menu-bar-lines' and actual appearance of a
>      menubar are inconsistent for minibuffer-only frames.

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

[martin rudalics]

 > The frame we are creating is not yet ready, and is certainly not yet
 > the selected frame!  Isn't that a bug? shouldn't we use
 > menu-updating-frame instead of nil, in the above call to
 > frame-parameter?

I think so.  Hopefully `menu-updating-frame' has the correct parameters
in place.

 > Sorry, I don't follow: are you saying that we must not evaluate Lisp
 > code inside `define-key', or are you saying something else?

I thought about wrapping the Lisp code so that the call fails more
gracefully.  Crashing seems a bit too harsh to me, at least for such
a trivial reason.

 >> (2) The menu-bar define-key operations to toggle `menu-bar-mode' and
 >>      `tool-bar-mode' do not take into account that the values of the
 >>      respective frame parameter can be nil.
 >
 > As you see above, this happens for the minibuffer frame.  Can you
 > explain how we get `(menu-bar-lines)' instead of having the usual
 > `(menu-bar-lines . 1)' or `(menu-bar-lines . 0)' in the parameters
 > alist of the minibuffer frame?  Is that normal, or is that another
 > bug?

IIRC it's somewhere documented that `menu-bar-lines' and
`tool-bar-lines' can be nil.  And a user can always remove a parameter
completely so any frame parameter can be nil.

 >> (3) Frame parameters of `menu-bar-lines' and actual appearance of a
 >>      menubar are inconsistent for minibuffer-only frames.

Though unrelated this strikes me as the strangest bug of them all.  It
means that we can't rely on the actual value of a frame parameter even
if it's non-nil.

martin

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

[Eli Zaretskii]

> Date: Mon, 29 Nov 2010 21:14:27 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 1077@debbugs.gnu.org
> 
>  > The frame we are creating is not yet ready, and is certainly not yet
>  > the selected frame!  Isn't that a bug? shouldn't we use
>  > menu-updating-frame instead of nil, in the above call to
>  > frame-parameter?
> 
> I think so.  Hopefully `menu-updating-frame' has the correct parameters
> in place.

Any objections to the patch below?  It fixes the error and the
following crash with Drew's recipe.


=== modified file 'lisp/menu-bar.el'
--- lisp/menu-bar.el	2010-08-13 13:26:13 +0000
+++ lisp/menu-bar.el	2010-11-29 21:08:59 +0000
@@ -966,7 +966,9 @@ mail status in mode line"))
 (define-key menu-bar-showhide-menu [menu-bar-mode]
   `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
 	      :help ,(purecopy "Turn menu-bar on/off")
-	      :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))
+	      :button (:toggle . (> (frame-parameter (or menu-updating-frame
+							 (selected-frame))
+						     'menu-bar-lines) 0))))
 
 (defun menu-bar-set-tool-bar-position (position)
   (customize-set-variable 'tool-bar-mode t)

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

[Drew Adams]

>  (define-key menu-bar-showhide-menu [menu-bar-mode]
>    `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
>  	      :help ,(purecopy "Turn menu-bar on/off")
> -	      :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))
> +	      :button (:toggle . (> (frame-parameter (or menu-updating-frame
> +
(selected-frame))
> +
'menu-bar-lines) 0))))

Ignore if this makes no sense; I'm not following the details of this, and I'm
ignorant about menu-updating-frame.

Can menu-updating-frame be nil?  In that case, don't we get the same error/bug?

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Mon, 29 Nov 2010 13:33:00 -0800
> 
> >  (define-key menu-bar-showhide-menu [menu-bar-mode]
> >    `(menu-item ,(purecopy "Menu-bar") toggle-menu-bar-mode-from-frame
> >  	      :help ,(purecopy "Turn menu-bar on/off")
> > -	      :button (:toggle . (> (frame-parameter nil 'menu-bar-lines) 0))))
> > +	      :button (:toggle . (> (frame-parameter (or menu-updating-frame
> > +                                                    (selected-frame))
> > +                                                'menu-bar-lines) 0))))
> 
> Ignore if this makes no sense; I'm not following the details of this, and I'm
> ignorant about menu-updating-frame.
> 
> Can menu-updating-frame be nil?

It can, but not when we are evaluating menu items as part of creating
a frame.  I left the reference to selected-frame for that very reason.

> In that case, don't we get the same error/bug?

I'm not sure.  I'm still trying to understand when and why did the
menu-bar-lines parameter got a nil value in the minibuffer frame's
parameters.  Depending on what I find, there could be an additional
change.  If this happens only in minibuffer frames, then the above
should be enough to fix the bug, because minibuffer frames without a
menu bar will never evaluate their menu items.

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

[martin rudalics]

 > I'm not sure.  I'm still trying to understand when and why did the
 > menu-bar-lines parameter got a nil value in the minibuffer frame's
 > parameters.  Depending on what I find, there could be an additional
 > change.  If this happens only in minibuffer frames, then the above
 > should be enough to fix the bug, because minibuffer frames without a
 > menu bar will never evaluate their menu items.

 From the Elisp manual

`menu-bar-lines'
      The number of lines to allocate at the top of the frame for a menu
      bar.  The default is 1.  A value of `nil' means don't display a
      menu bar.  *Note Menu Bar::.  (The X toolkit and GTK allow at most
      one menu bar line; they treat larger values as 1.)

so `nil' is a valid value and evaluating a menu bar item probably should
know how to handle it.

martin

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 08:56:41 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Drew Adams <drew.adams@oracle.com>, 1077@debbugs.gnu.org
> 
> `menu-bar-lines'
>       The number of lines to allocate at the top of the frame for a menu
>       bar.  The default is 1.  A value of `nil' means don't display a
>       menu bar.

Is it different from (menu-bar-lines . 0) ?  If not, do you happen to
know why are we using two different conventions to convey the same
information?

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 08:56:41 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Drew Adams <drew.adams@oracle.com>, 1077@debbugs.gnu.org
> 
> `menu-bar-lines'
>       The number of lines to allocate at the top of the frame for a menu
>       bar.  The default is 1.  A value of `nil' means don't display a
>       menu bar.  *Note Menu Bar::.  (The X toolkit and GTK allow at most
>       one menu bar line; they treat larger values as 1.)
> 
> so `nil' is a valid value and evaluating a menu bar item probably should
> know how to handle it.

Btw, the code which injects this nil into the frame parameters is no
other than oneonone.el itself.  It has this part:

    (defcustom 1on1-minibuffer-frame-alist
      (list
       (or (assq 'foreground-color minibuffer-frame-alist)
	   (cons 'foreground-color 1on1-minibuffer-frame-foreground))
       [...]
       (or (assq 'menu-bar-lines minibuffer-frame-alist)
	   (cons 'menu-bar-lines nil))
            ^^^^^^^^^^^^^^^^^^^^^^^^^

If I replace this with `(cons 'menu-bar-lines 0)', the original
problem goes away without any changes in menu-bar.el.

Drew, any reason not to make that change in your package?

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

[martin rudalics]

 > Is it different from (menu-bar-lines . 0) ?

The only difference I can think of is that nil stands for "this frame
cannot have a menubar" and zero for "the menubar has been temporarily
disabled".  But if not entry for `menu-bar-lines' exists, calling
(frame-parameter ... 'menu-bar-lines) returns nil.  Hence, the caller
should be prepared to deal with a return value of nil anyway (ideally
using `numberp' since the call might return any value).

 > If not, do you happen to
 > know why are we using two different conventions to convey the same
 > information?

Probably for using `menu-bar-lines' in a uniform manner instead of a
combination of `menu-bar-mode' and `menu-bar-lines'.  The most
interesting thing about this is that on GNU systems Emacs never uses a
value greater than 1 (if I correctly recall a discussion about this).
And on Windows any calculations with a value greater than 1 are broken
anway.  So using a boolean `menu-bar' should suffice.

martin

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 15:01:09 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 1077@debbugs.gnu.org
> 
>  > Is it different from (menu-bar-lines . 0) ?
> 
> The only difference I can think of is that nil stands for "this frame
> cannot have a menubar" and zero for "the menubar has been temporarily
> disabled".

What is the difference between these two?  What does "cannot have a
menu bar" mean in practice?  Just wondering.

> But if not entry for `menu-bar-lines' exists, calling
> (frame-parameter ... 'menu-bar-lines) returns nil.

That's not guaranteed to be true.  You will see in the implementation
of frame-parameter and frame-parameters that we return values for some
frame parameters without ever looking at the frame's parameter alist.
It's true that frame-parameter actually does look in frame's parameter
alist when the value of menu-bar-lines is requested, but
frame-parameters does not, at least for TTYs.

That said, I agree that any code which is called during frame creation
should be able to avoid signaling an error.

>  > If not, do you happen to
>  > know why are we using two different conventions to convey the same
>  > information?
> 
> Probably for using `menu-bar-lines' in a uniform manner instead of a
> combination of `menu-bar-mode' and `menu-bar-lines'.

If so, this is a thing of the past, as we no longer need
menu-bar-mode, menu-bar-lines alone is enough, right?

> The most
> interesting thing about this is that on GNU systems Emacs never uses a
> value greater than 1 (if I correctly recall a discussion about this).
> And on Windows any calculations with a value greater than 1 are broken
> anway.  So using a boolean `menu-bar' should suffice.

Even funnier, the ELisp manual shows an example of building a menu bar
with two lines, see the node "Menu Bar" there.

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

[Drew Adams]

> Btw, the code which injects this nil into the frame parameters is no
> other than oneonone.el itself.  It has this part:
> 
>     (defcustom 1on1-minibuffer-frame-alist
>       (list
>        (or (assq 'foreground-color minibuffer-frame-alist)
> 	   (cons 'foreground-color 1on1-minibuffer-frame-foreground))
>        [...]
>        (or (assq 'menu-bar-lines minibuffer-frame-alist)
> 	   (cons 'menu-bar-lines nil))
>             ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> If I replace this with `(cons 'menu-bar-lines 0)', the original
> problem goes away without any changes in menu-bar.el.
> 
> Drew, any reason not to make that change in your package?

OK, I've made that change.

However, Emacs has the _general convention_ that a nil-valued frame parameter is
the same as an absence of that parameter.  Not having parameter `foo' present as
one of a frame's parameters is the same as having `(foo)' as the parameter cons.
This is true (should be true) for predefined parameters and for user-defined
frame parameters.  It is general behavior, and should just work (IMO).

And note that the doc Martin cites, in the Elisp manual, was explicitly _added_
for Emacs 21, presumably because this is important (not to be missed) - it is
not present in the Emacs 20 Elisp manual:

Elisp 20 manual:

`menu-bar-lines'
     The number of lines to allocate at the top of the frame for a menu
     bar.  The default is 1.  *Note Menu Bar::.  (In Emacs versions
     that use the X toolkit, there is only one menu bar line; all that
     matters about the number you specify is whether it is greater than
     zero.)

Elisp 21 manual:

menu-bar-lines
The number of lines to allocate at the top of the frame for a menu bar. The
default is 1. A value of nil means don't display a menu bar. See Menu Bar. (The
X toolkit and GTK allow at most one menu bar line; they treat larger values as
1.) 

FWIW (not much), I have this change-log comment in oneonone.el from 2005/05/28:
;;     Corrected 1on1-minibuffer-frame-alist and
;;     1on1-special-display-frame-alist for menu-bar-lines (nil).
Dunno what that was a change _from_, unfortunately. ;-)

Thanks for fixing this.  I do think that a value of nil should behave normally,
however, i.e., behave the same as a missing `menu-bar-lines' entry, which also
means the same as a `(menu-bar-lines . 0)' entry.

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

[Drew Adams]

> > But if not entry for `menu-bar-lines' exists, calling
> > (frame-parameter ... 'menu-bar-lines) returns nil.
> 
> That's not guaranteed to be true.  You will see in the implementation
> of frame-parameter and frame-parameters that we return values for some
> frame parameters without ever looking at the frame's parameter alist.
> It's true that frame-parameter actually does look in frame's parameter
> alist when the value of menu-bar-lines is requested, but
> frame-parameters does not, at least for TTYs.

My impression (I don't have references to prove it) is that this general rule
_has_ worked, and it has only recently (in the last few years) been broken.  And
IIRC it was broken by Emacs Dev when trying to work around (fix) bugs introduced
wrt the tool-bar code.  IOW, my impression is that we ended up breaking this
behavior because that's how we decided to fix some bugs that were introduced.

This stuff (e.g. tool-bar code) became more complex during this process,
especially in conjunction with startup and the default frame alists.  Overall,
the tool-bar behavior might have been improved (dunno), but I'm not sure the
general handling of frame parameters didn't suffer.

Yidong might have something different to say about this.  My impression is only
that, an impression.  I believe he is familiar with the code and the changes.

> That said, I agree that any code which is called during frame creation
> should be able to avoid signaling an error.

I think a frame alist entry of `(menu-bar-lines)' should be handled correctly:
handled just the same as `(menu-bar-lines . 0)' and the same as having no entry.


> If so, this is a thing of the past, as we no longer need
> menu-bar-mode, menu-bar-lines alone is enough, right?

I'm not aware that there ever was a _frame parameter_ named `menu-bar-mode'.
Certainly there is none mentioned in the Emacs 20 Elisp manual.  There is a
`menu-bar-mode' _command_ (and mode).

> Even funnier, the ELisp manual shows an example of building a menu bar
> with two lines, see the node "Menu Bar" there.

And that should be possible.  If it isn't possible today because of some
limitations then it should be kept as a future possibility and put on the TODO
list (IMO).
 

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

[martin rudalics]

 >> The only difference I can think of is that nil stands for "this frame
 >> cannot have a menubar" and zero for "the menubar has been temporarily
 >> disabled".
 >
 > What is the difference between these two?  What does "cannot have a
 > menu bar" mean in practice?  Just wondering.

Minibuffer-only frames don't have a menubar by design.  Surprisingly
they have (menu-bar-lines . 1) here.

 >> But if not entry for `menu-bar-lines' exists, calling
 >> (frame-parameter ... 'menu-bar-lines) returns nil.
 >
 > That's not guaranteed to be true.

For the menu-bar-lines parameter it is true AFAICT.

 > You will see in the implementation
 > of frame-parameter and frame-parameters that we return values for some
 > frame parameters without ever looking at the frame's parameter alist.
 > It's true that frame-parameter actually does look in frame's parameter
 > alist when the value of menu-bar-lines is requested, but
 > frame-parameters does not, at least for TTYs.

Do you mean where it goes for the menu_bar_lines entry from the frame
structure via FRAME_MENU_BAR_LINES?  I suppose this is the only part of
the menu-bar handling code that is still correct.

 > That said, I agree that any code which is called during frame creation
 > should be able to avoid signaling an error.

I still don't get it why a condition_case can't handle such an error.

 >> Probably for using `menu-bar-lines' in a uniform manner instead of a
 >> combination of `menu-bar-mode' and `menu-bar-lines'.
 >
 > If so, this is a thing of the past, as we no longer need
 > menu-bar-mode, menu-bar-lines alone is enough, right?

Currently, menu-bar alone is enough ;-)

 > Even funnier, the ELisp manual shows an example of building a menu bar
 > with two lines, see the node "Menu Bar" there.

It used to work with Emacs' own menubars IIRC.

martin

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

[martin rudalics]

 >> That said, I agree that any code which is called during frame creation
 >> should be able to avoid signaling an error.

Using something like `define-key-safely' maybe.

 > I'm not aware that there ever was a _frame parameter_ named `menu-bar-mode'.

There never was such a parameter.

 >> Even funnier, the ELisp manual shows an example of building a menu bar
 >> with two lines, see the node "Menu Bar" there.
 >
 > And that should be possible.  If it isn't possible today because of some
 > limitations then it should be kept as a future possibility and put on the TODO
 > list (IMO).

On a windowing system it's not Emacs who decides how many lines the
menubar takes up.  And the Windows API isn't even able to tell
applications how many lines it actually uses for the menubar.  Most GNU
based applications like Mozilla and Thunderbird do not allow Windows to
make two menubar lines in the first place.

martin

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

[Drew Adams]

>  > What is the difference between these two?  What does "cannot have a
>  > menu bar" mean in practice?  Just wondering.
> 
> Minibuffer-only frames don't have a menubar by design.  Surprisingly
> they have (menu-bar-lines . 1) here.

Why by design?  I mean why must that be the design?  No menu-bar by default, I
could understand.

But I can see that someone might well want a menu-bar for a minibuffer
standalone frame.  After all, there is a menu-bar menu, `Minibuf', which is
missing altogether when you use a standalone minibuffer frame.  I've asked in
the past that the `Minibuf' menu be made available (or it at least be possible
to make it available) even when you use a standalone minibuffer frame.

I think `menu-bar-lines' and even `tool-bar-lines' should be respected by a
minibuffer frame.  Why preclude users from having these if they find some use
for them in some context?  What reason can we have for a design that _prevents_
a minibuffer frame from using these?  Sounds short-sighted, to me.

And I'm someone who would probably _not_ enable such things for my own
minibuffer frame.  I just don't see why we throw out the possibility.

>  > Even funnier, the ELisp manual shows an example of 
>  > building a menu bar with two lines, see the node "Menu Bar" there.
> 
> It used to work with Emacs' own menubars IIRC.

I think so too, but my recollection of this is faint and probably faulty.

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

[Drew Adams]

>  >> building a menu bar with two lines...
>  >
>  > And that should be possible.  If it isn't possible today 
>  > because of some limitations then it should be kept as a future
>  > possibility and put on the TODO list (IMO).
> 
> On a windowing system it's not Emacs who decides how many lines the
> menubar takes up.  And the Windows API isn't even able to tell
> applications how many lines it actually uses for the menubar. 
> Most GNU based applications like Mozilla and Thunderbird do not allow 
> Windows to make two menubar lines in the first place.

Emacs is not limited by design to a particular set of window managers/systems,
let alone the current states of some particular set.  Or at least it should not
be - not by design.

IOW, if a user cannot currently cannot get this feature on window sytem WXYZ, so
be it (too bad).  That's not the same thing as hard-wiring Emacs to not provide
the feature.

Besides, is this true also for tool bars?  Depends on what is meant by a tool
bar, perhaps.  But (I think) I see lots of applications on MS Windows that have
multiple tool-bar lines (and multiple tool bars).

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Tue, 30 Nov 2010 07:42:50 -0800
> 
> I do think that a value of nil should behave normally,
> however, i.e., behave the same as a missing `menu-bar-lines' entry, which also
> means the same as a `(menu-bar-lines . 0)' entry.

I agree, and will do (as soon as Savannah comes back on line).

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Tue, 30 Nov 2010 07:56:55 -0800
> 
> > > But if not entry for `menu-bar-lines' exists, calling
> > > (frame-parameter ... 'menu-bar-lines) returns nil.
> > 
> > That's not guaranteed to be true.  You will see in the implementation
> > of frame-parameter and frame-parameters that we return values for some
> > frame parameters without ever looking at the frame's parameter alist.
> > It's true that frame-parameter actually does look in frame's parameter
> > alist when the value of menu-bar-lines is requested, but
> > frame-parameters does not, at least for TTYs.
> 
> My impression (I don't have references to prove it) is that this general rule
> _has_ worked, and it has only recently (in the last few years) been broken.

Perhaps for a couple of frame parameters that was changed recently.
However, the general fact that _some_ frame parameters are returned
without ever consulting the frame's parameter alist -- this fact is
true for as long as I can remember.

> I'm not aware that there ever was a _frame parameter_ named `menu-bar-mode'.
> Certainly there is none mentioned in the Emacs 20 Elisp manual.  There is a
> `menu-bar-mode' _command_ (and mode).

Every mode (well, almost every one) has a variable by that same name.
Try "C-h v menu-bar-mode RET".  I'm sure you already knew that.

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 18:05:03 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 1077@debbugs.gnu.org
> 
>  > That said, I agree that any code which is called during frame creation
>  > should be able to avoid signaling an error.
> 
> I still don't get it why a condition_case can't handle such an error.

Because part of the recipe is to set debug-on-error non-nil?

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 18:07:23 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 'Eli Zaretskii' <eliz@gnu.org>, 1077@debbugs.gnu.org
> 
>  > I'm not aware that there ever was a _frame parameter_ named `menu-bar-mode'.
> 
> There never was such a parameter.

I didn't mean a frame parameter, I meant a mode variable.

> On a windowing system it's not Emacs who decides how many lines the
> menubar takes up.

You mean, Emacs compiled with a toolkit.  Emacs compiled without a
toolkit still does decide that, even if it's an X session.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Tue, 30 Nov 2010 09:57:20 -0800
> 
> >  > What is the difference between these two?  What does "cannot have a
> >  > menu bar" mean in practice?  Just wondering.
> > 
> > Minibuffer-only frames don't have a menubar by design.  Surprisingly
> > they have (menu-bar-lines . 1) here.
> 
> Why by design?  I mean why must that be the design?

It's not the design.  Simply, no one bothered to solve the
difficulties that are related to having menu bars in minibuffer-only
frames.  The function set_menu_bar_lines, which handles changes in the
menu-bar-lines frame parameter, has this fragment right at its
beginning:

  /* Right now, menu bars don't work properly in minibuf-only frames;
     most of the commands try to apply themselves to the minibuffer
     frame itself, and get an error because you can't switch buffers
     in or split the minibuffer window.  */
  if (FRAME_MINIBUF_ONLY_P (f))
    return;

So it simply punts for minibuffer-only frames.

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

[Drew Adams]

> > I'm not aware that there ever was a _frame parameter_ named 
> > `menu-bar-mode'.  Certainly there is none mentioned in the
> > Emacs 20 Elisp manual.  There is a `menu-bar-mode' _command_
> > (and mode).
> 
> Every mode (well, almost every one) has a variable by that same name.
> Try "C-h v menu-bar-mode RET".  I'm sure you already knew that.

Yes, I'm aware of that.  That's why I added "(and mode)".

But a variable is not the same thing as a frame parameter.
The question was about a frame parameter named `menu-bar-mode'.

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

[Drew Adams]

> > I do think that a value of nil should behave normally,
> 
> I agree, and will do (as soon as Savannah comes back on line).

Great. Thx.

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

[martin rudalics]

 > Emacs is not limited by design to a particular set of window managers/systems,
 > let alone the current states of some particular set.  Or at least it should not
 > be - not by design.
 >
 > IOW, if a user cannot currently cannot get this feature on window sytem WXYZ, so
 > be it (too bad).  That's not the same thing as hard-wiring Emacs to not provide
 > the feature.

Being able to set `menu-bar-lines' to something > 1 is hardly useful
when the window manager decides how many lines the menubar has.  It
might be useful to know the actual size of the menubar for calculating
the size of the Emacs window.  But you would not need a frame parameter
for that.

martin

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

[martin rudalics]

 >> Minibuffer-only frames don't have a menubar by design.  Surprisingly
 >> they have (menu-bar-lines . 1) here.
 >
 > Why by design?  I mean why must that be the design?  No menu-bar by default, I
 > could understand.

I doesn't have to be designed that way.  But the minibuffer window is
special so you would have to design a minibuffer-menubar with its own
keymap.  That would be a different design.

 > And I'm someone who would probably _not_ enable such things for my own
 > minibuffer frame.  I just don't see why we throw out the possibility.

I do.  Nobody's around to write such a thing.

martin

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

[martin rudalics]

 > It's not the design.

By design a minibuffer is a special buffer and a minibuffer window is a
special window.  The concepts of a standalone minibuffer window are
mostly unchanged from that of a minibuffer window attached to a normal
frame.

 > Simply, no one bothered to solve the
 > difficulties that are related to having menu bars in minibuffer-only
 > frames.  The function set_menu_bar_lines, which handles changes in the
 > menu-bar-lines frame parameter, has this fragment right at its
 > beginning:
 >
 >   /* Right now, menu bars don't work properly in minibuf-only frames;
 >      most of the commands try to apply themselves to the minibuffer
 >      frame itself, and get an error because you can't switch buffers
 >      in or split the minibuffer window.  */

You either have to redesign the concept of minibuffer windows or work
around the design.  Both tasks seem non-trivial to me.  "Right now" is
just another way to express that.

martin

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

[Drew Adams]

>  > IOW, if a user currently cannot get this feature on 
>  > window sytem WXYZ, so be it (too bad).  That's not the
>  > same thing as hard-wiring Emacs to not provide the feature.
> 
> Being able to set `menu-bar-lines' to something > 1 is hardly useful
> when the window manager decides how many lines the menubar has.

I believe we are saying the same thing here.  That's what I meant by a user not
currently being able to get the feature on some given window system.

The point is that that doesn't mean that some other window system might not
provide such a feature, or even that a future or past version of the same window
system might not provide it.

IOW, let's separate which features Emacs allows from what some window managers
might support.  Certainly we do that in general; there are some window mgrs that
do not support some features that Emacs supports.

> It might be useful to know the actual size of the menubar for calculating
> the size of the Emacs window.  But you would not need a frame 
> parameter for that.

Sorry, I don't follow.  What does that have to do with what you or I say above?

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

[Drew Adams]

>  > Why by design?  I mean why must that be the design?  No 
>  > menu-bar by default, I could understand.
> 
> I doesn't have to be designed that way.  But the minibuffer window is
> special so you would have to design a minibuffer-menubar with its own
> keymap.  That would be a different design.

Minibuffer window or minibuffer frame?  The menu bar is for a frame, no?

What makes the minibuffer frame necessarily special wrt a menu-bar?

(The active minibuffer itself already has a menu-bar menu, `Minibuf', but that
is currently unavailable for the minibuffer frame, since that frame has no
menu-bar.)

>  > And I'm someone who would probably _not_ enable such 
>  > things for my own minibuffer frame.  I just don't see why
>  > we throw out the possibility.
> 
> I do.  Nobody's around to write such a thing.

Lack of resources has never prevented us from excluding the _possibility_.  Just
add it to the TODO list.

It makes perfect sense, in particular, that the `Minibuf' menu-bar menu should
be displayable when the minibuffer is active, and that is not the case now when
you use a standalone minibuffer frame.  I'd call that a bug.

But the fix for that particular bug need not necessarily be to allow a menu-bar
on the minibuffer frame.  An alternative (essentially a workaround) might be to
show the `Minibuf' menu in all frames whenever the minibuffer is active.

Aside from that (`Minibuf' menu support when you have a standalone minibuffer
frame), I think that we should add support for a menu-bar on a minibuffer frame
to the TODO list.

Whether and when particular things on the TODO list actually get done is a
question of resources.  Whether to put something on the TODO list should not be
a question of current resources.

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

[Drew Adams]

> By design a minibuffer is a special buffer and a minibuffer 
> window is a special window.  The concepts of a standalone
> minibuffer window are mostly unchanged from that of a
> minibuffer window attached to a normal frame.

If so, then both (a) it should be possible for the minibuffer frame to have a
menu-bar - just like a "normal" frame, and (b) it should be possible for the
`Minibuf' menu-bar menu to be shown when you use a standalone minibuffer frame.

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

[Drew Adams]

Resending.  This reply of mine bounced for some reason.

-----Original Message-----
From: Drew Adams Sent: Tuesday, November 30, 2010 11:20 AM
To: 'Eli Zaretskii' Cc: rudalics@gmx.at; 1077@debbugs.gnu.org
Subject: RE: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument
number-or-marker-p nil)

> It's not the design.  Simply, no one bothered to solve the
> difficulties that are related to having menu bars in minibuffer-only
> frames.  The function set_menu_bar_lines, which handles changes in the
> menu-bar-lines frame parameter, has this fragment right at its
> beginning:
> 
>   /* Right now, menu bars don't work properly in minibuf-only frames;
>      most of the commands try to apply themselves to the minibuffer
>      frame itself, and get an error because you can't switch buffers
>      in or split the minibuffer window.  */
>   if (FRAME_MINIBUF_ONLY_P (f))
>     return;
> 
> So it simply punts for minibuffer-only frames.

OK, so it sounds like a bug or missing feature, rather than a design
limitation/choice.  Can we please add fixing this to the TODO list?  (I'm
assuming it will not be fixed as part of the fix for this bug.)

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <1077@debbugs.gnu.org>
> Date: Tue, 30 Nov 2010 12:21:22 -0800
> 
> (I'm assuming it will not be fixed as part of the fix for this bug.)

Right.

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

[martin rudalics]

 > If so, then both (a) it should be possible for the minibuffer frame to have a
 > menu-bar - just like a "normal" frame,

The code for such a menu-bar must be either designed specifically for
such a frame or the current menu-bar.el code must be redesigned to
accomodate the pecularities of the minibuffer frame.  Neither of these
is simple as the current problems indicate.

 > and (b) it should be possible for the
 > `Minibuf' menu-bar menu to be shown when you use a standalone minibuffer frame.

You mean a Minibuf entry from some other "normal" frame?  When you go to
such an entry with the mouse you very likely automatically select the
associated frame too and probably get some very convoluted semantics wrt
the selected frame.  Besides, what would you do when there's no "normal"
frame?

martin

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

[martin rudalics]

 >> I still don't get it why a condition_case can't handle such an error.
 >
 > Because part of the recipe is to set debug-on-error non-nil?

Probably.  But what is `debug-on-error' good for when Emacs crashes?

martin

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

[Lennart Borgman]

On Tue, Nov 30, 2010 at 12:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Is it different from (menu-bar-lines . 0) ?  If not, do you happen to
> know why are we using two different conventions to convey the same
> information?

Is not that just because the way the parameters are passed?

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

[Drew Adams]

>  > and (b) it should be possible for the
>  > `Minibuf' menu-bar menu to be shown when you use a 
>  > standalone minibuffer frame.
> 
> You mean a Minibuf entry from some other "normal" frame?  

I meant shown in the minibuffer frame's menu bar.

But I think I also mentioned being able to show the `Minibuf' menu in all other
frames, as an alternative (e.g. while waiting to get a minibuffer-frame menu
bar).  So no, that's not what I was saying, but yes, that too.

> When you go to such an entry with the mouse you very likely 
> automatically select the associated frame too

Not sure that matters, even it it's true.  And it's not difficult to fix that
menu's behavior to select the minibuffer window if it's not selected.

> and probably get some very convoluted semantics wrt
> the selected frame.

=?

> Besides, what would you do when there's no "normal" frame?

No frame that has a menu bar means no menu bar, so no `Minibuf' menu-bar menu.
Nothing new here.

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

[Stefan Monnier]

> `menu-bar-lines'
>      The number of lines to allocate at the top of the frame for a menu
>      bar.  The default is 1.  A value of `nil' means don't display a
>      menu bar.  *Note Menu Bar::.  (The X toolkit and GTK allow at most
>      one menu bar line; they treat larger values as 1.)

> so `nil' is a valid value and evaluating a menu bar item probably should
> know how to handle it.

I think the above doc only means that the C code interprets a nil as
meaning  "no menu bar" when you set that frame parameter.  Whether it
also means that this same C code can return nil when you query this
parameter is not quite so clear.


        Stefan

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

[Eli Zaretskii]

> Date: Wed, 01 Dec 2010 10:58:59 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 1077@debbugs.gnu.org
> 
>  >> I still don't get it why a condition_case can't handle such an error.
>  >
>  > Because part of the recipe is to set debug-on-error non-nil?
> 
> Probably.  But what is `debug-on-error' good for when Emacs crashes?

Absolutely nothing.  However, `debug-on-error' doesn't know that Emacs
is about to crash, so it doesn't know that it's no good.

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

[martin rudalics]

 >> `menu-bar-lines'
 >>      The number of lines to allocate at the top of the frame for a menu
 >>      bar.  The default is 1.  A value of `nil' means don't display a
 >>      menu bar.  *Note Menu Bar::.  (The X toolkit and GTK allow at most
 >>      one menu bar line; they treat larger values as 1.)
 >
 >> so `nil' is a valid value and evaluating a menu bar item probably should
 >> know how to handle it.
 >
 > I think the above doc only means that the C code interprets a nil as
 > meaning  "no menu bar" when you set that frame parameter.  Whether it
 > also means that this same C code can return nil when you query this
 > parameter is not quite so clear.

I don't think it's of great importance.  From the example I gave earlier

(let ((frame (make-frame '((minibuffer . only)))))
   (frame-parameter frame 'menu-bar-lines))

the value returned by `frame-parameter' may have no relation to what is
actually displayed.

martin

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

[martin rudalics]

 >> and probably get some very convoluted semantics wrt
 >> the selected frame.
 >
 > =?

Which one is the selected frame when I have a standalone minibuffer
frame and access the Minibuf entry in the menubar of another frame?

Or do you mean you don't care?

martin

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

[Drew Adams]

>  >> and probably get some very convoluted semantics wrt
>  >> the selected frame.
>  >
>  > =?
> 
> Which one is the selected frame when I have a standalone minibuffer
> frame and access the Minibuf entry in the menubar of another frame?

I don't know, here.  But I do use a standalone minibuffer all the time and I
click etc. things in other frames during minibuffer input (e.g. using
completion).  (This is on Windows; dunno whether that makes a difference.)

There is a difference (as I'm sure you know) between a frame having the focus
and a window being selected.

Typically during minibuffer input (e.g. using completion) the minibuffer window
is selected, at least at some point(s), but the frame that has the focus remains
the frame that had the focus before calling `completing-read' (or whatever).

That doesn't prevent things working as expected.  Activating the minibuffer does
not move the frame focus to the minibuffer frame, I believe.  And a user can
still interact with other frames during this.  But yes, it can happen that some
user actions during input will cause the focused frame to change.

(I'm going on memory here; I don't claim 100% accuracy for this description.)

So I would agree that it might be tricky or that we don't (that is, I don't)
know a priori what would happen wrt choosing a menu item in another frame's menu
bar.  But presumably using the menu bar of the frame with the focus (which is
not the minibuffer frame) should not have any such focus-change effect - that
would be my guess anyway.

> Or do you mean you don't care?

My `=?' meant "what do you mean by that?"  What convoluted semantics do you
foresee?  That's all I meant.

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

[Eli Zaretskii]

> Date: Tue, 30 Nov 2010 20:12:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 1077@debbugs.gnu.org
> 
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Cc: <1077@debbugs.gnu.org>
> > Date: Tue, 30 Nov 2010 07:42:50 -0800
> > 
> > I do think that a value of nil should behave normally,
> > however, i.e., behave the same as a missing `menu-bar-lines' entry, which also
> > means the same as a `(menu-bar-lines . 0)' entry.
> 
> I agree, and will do (as soon as Savannah comes back on line).

Done, both on the Emacs 23 branch and on the trunk (slightly different
patches were needed in each case).