[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7368: Testcase
From: |
Андрей Парамонов |
Subject: |
bug#7368: Testcase |
Date: |
Sat, 13 Nov 2010 11:47:19 +0300 |
2010/11/13 martin rudalics <rudalics@gmx.at>:
> On my trunk Emacs your code produces a new window on the selected frame.
Ah, sorry. Here is the modified version which I've actually checked ;-)
(let ((foo (get-buffer-create "foo.el"))
(bar (get-buffer-create "bar.el")))
(switch-to-buffer foo)
(delete-other-windows)
(emacs-lisp-mode)
(insert "(a")
(completion-at-point)
(display-buffer bar t))
> So `display-buffer' simply has no other choice but
> making a new frame.
In principle, in this very awkward situation display-buffer has 3 options:
1) To display buffer in selected window -- but not-in-this-window=t.
2) To display buffer in a new frame -- but pop-up-frames says we
*never* make a separate frame.
3) To display buffer in place of completions window -- but that window
is "dedicated".
To me option 3 seems the least unexpected.
Anyway, something needs to be fixed, as current documentation for
pop-up-frames is wrong.
> BTW, the snippet
>
> (progn
> (delete-other-windows)
> (display-buffer (other-buffer) t))
>
> should be sufficient for exhibiting the behavior you observe.
No, the completions buffer plays important role.
Thanks for your support,
Andrey Paramonov
- bug#7368: 23.2; Python interpreter buffer should never appear in separate frame, Andrey Paramonov, 2010/11/10
- bug#7368: Testcase, Андрей Парамонов, 2010/11/13
- bug#7368: Testcase, martin rudalics, 2010/11/13
- bug#7368: Testcase,
Андрей Парамонов <=
- bug#7368: Testcase, martin rudalics, 2010/11/13
- bug#7368: Testcase, Stefan Monnier, 2010/11/15
- bug#7368: Testcase, Андрей Парамонов, 2010/11/16
- bug#7368: Testcase, Stefan Monnier, 2010/11/16
- bug#7368: Testcase, martin rudalics, 2010/11/17
bug#7368: display-buffer a softly dedicated window, Андрей Парамонов, 2010/11/17