[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15183: 24.3.50; emacs_backtrace.txt
From: |
martin rudalics |
Subject: |
bug#15183: 24.3.50; emacs_backtrace.txt |
Date: |
Sun, 25 Aug 2013 16:36:24 +0200 |
> w32_backtrace at w32fns.c:7982
> emacs_abort at w32fns.c:8014
> terminate_due_to_signal at emacs.c:369
> die at alloc.c:6573
> XWINDOW at lisp.h:799
> set_window_buffer at window.c:3155
> delete_frame at frame.c:1251
> Fdelete_frame at frame.c:1450
So IIUC when Drew calls `delete-frame' either (1) the selected frame
does not have a minibuffer or (2) the frame to be deleted was selected
and the frame selected instead doesn't have a minibuffer. I'm not yet
sure what to do but am afraid there's some basic misunderstanding here.
Consider choose_minibuf_frame in minibuf.c. It has a comment which says
/* I don't think that any frames may validly have a null minibuffer
window anymore. */
if (NILP (sf->minibuffer_window))
emacs_abort ();
But on my Emacs I can easily do something like
(let ((frame (make-frame '((minibuffer . nil)))))
(select-frame frame)
(minibuffer-window (selected-frame)))
which returns nil. So the selected frame's minibuffer window slot may
contain nil and unless I'm missing something we have to resolve this
issue first.
martin
- bug#15183: 24.3.50; emacs_backtrace.txt, Drew Adams, 2013/08/24
- bug#15183: 24.3.50; emacs_backtrace.txt, Juanma Barranquero, 2013/08/24
- bug#15183: 24.3.50; emacs_backtrace.txt,
martin rudalics <=
- bug#15183: 24.3.50; emacs_backtrace.txt, Drew Adams, 2013/08/25
- bug#15183: 24.3.50; emacs_backtrace.txt, martin rudalics, 2013/08/25
- bug#15183: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/08/25
- bug#15183: 24.3.50; emacs_backtrace.txt, martin rudalics, 2013/08/26
- bug#15183: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/08/26