* bug#8856: 24.0.50; regression: `special-display-popup-frame' broken
@ 2011-06-13 17:43 Drew Adams
2011-06-14 9:15 ` martin rudalics
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2011-06-13 17:43 UTC (permalink / raw)
To: 8856
I do not have a recipe from emacs -Q. The simplest recipe I have
offhand is to start with this:
runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f
"1on1-emacs"
You can download the two files mentioned
from here:
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24
And then do this:
M-x f TAB ; to display *Completions* frame.
C-] ; to return to top level.
M-x f TAB o
Or just hit TAB twice in a row: M-x f TAB TAB. IOW, try to type more
input in minibuffer. This raises the error
"Buffer is read-only #<buffer *Completions*>"
This should not happen, because the code that creates my special-display
frame *Completions* does this:
(redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)
The code that does that is in function
`1on1-display-*Completions*-frame', which is invoked via this entry on
list `special-display-buffer-names':
("*Completions*" 1on1-display-*Completions*-frame
((background-color ...)))
My guess is that `special-display-popup-frame' is the culprit, but the
effect is as if `redirect-frame-focus' were no longer respected. And I
see that the code of `special-display-popup-frame' has not changed
recently.
What seems to be happening (determined by debugging entry to
`1on1-display-*Completions*-frame'), is that
`1on1-display-*Completions*-frame' gets called only when the frame is
created, not each time `special-display-popup-frame' is called. So if
*Completions* is already displayed `1on1-display-*Completions*-frame' is
not invoked for its display, and the call to `redirect-frame-focus' is
not effected.
`C-h f special-display-popup-frame' says that it is obsolete as of 24.1,
but this just now stopped working.
And the doc, AFAICT, says nothing about how to do what users have always
done using `special-display-buffer-names'. That uses
`special-display-popup-frame', which is still the default value of
`special-display-function'.
This seems to be horribly broken now. I see other problems that might
(or might not) be related: breakage of dedicated frames (no longer
dedicated), so that, for instance, other buffers get put into my
dedicated *Completions* frame.
We seem to be in a halfway position now, between two horses (or two
chairs, depending on your culture). The default value of
`special-display-function' is a function that is declared obsolete! And
things that have always worked no longer work at all.
It's not clear, if users are being required to adjust their code, what
adjustments are needed. Some guidance needs to be provided, in addition
to fixing any related bugs.
I cannot use Emacs for the moment, starting with this build. I must use
an older build until this problem (and perhaps related problems) can be
fixed.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-06-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8856: 24.0.50; regression: `special-display-popup-frame' broken
2011-06-13 17:43 bug#8856: 24.0.50; regression: `special-display-popup-frame' broken Drew Adams
@ 2011-06-14 9:15 ` martin rudalics
0 siblings, 0 replies; 4+ messages in thread
From: martin rudalics @ 2011-06-14 9:15 UTC (permalink / raw)
To: Drew Adams; +Cc: 8856
> My guess is that `special-display-popup-frame' is the culprit, but the
> effect is as if `redirect-frame-focus' were no longer respected. And I
> see that the code of `special-display-popup-frame' has not changed
> recently.
>
> What seems to be happening (determined by debugging entry to
> `1on1-display-*Completions*-frame'), is that
> `1on1-display-*Completions*-frame' gets called only when the frame is
> created, not each time `special-display-popup-frame' is called. So if
> *Completions* is already displayed `1on1-display-*Completions*-frame' is
> not invoked for its display, and the call to `redirect-frame-focus' is
> not effected.
Could you please try stepping through `special-display-popup-frame' with
an old version that works for you and the latest one to find out whether
the function that does `redirect-frame-focus' gets called and, if not, why
it gets called in the former and why not in the latter?
martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated
@ 2011-06-13 16:08 Drew Adams
2011-06-13 18:00 ` martin rudalics
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2011-06-13 16:08 UTC (permalink / raw)
To: 8851
This regression was introduced between this build (from today,
6/13/2011) and the Windows build of LAST week, which was this:
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-06-06 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
I don't have a recipe starting from emacs -Q. But these are the
symptoms:
I have non-nil `pop-up-frames'. I use a special-display frame for
buffers such as `*Buffer List*' and `*info*'.
My value of `special-display-regexps' is this:
("[ ]?[*][^*]+[*]")
My special-display frames hav a different background color from my
regular frames. I visit a file foo.el, then use `C-x 5 0' to remove
its frame. I hit C-x C-b and get the buffer menu in a new,
special-display frame. I click mouse-2 on the foo.el line to
visit that file.
Prior to this week's build, this opens foo.el in a new frame, in a
regular frame. With this week's build it visits foo.el in the same
frame that showed `*Buffer List*'. IOW, `pop-up-frames' is not being
respected (in the case where there is not already a frame showing
foo.el).
What is happening is that `Buffer-menu-mouse-select' is incorrectly
invoking `switch-to-buffer' instead of `switch-to-buffer-other-window'.
This is happening because the window of the special-display buffer is
not dedicated, as it should be.
This returns nil:
(window-dedicated-p #<window 14 on *Buffer List*>)
Similarly, M-: (window-dedicated-p (selected-window)) in any
special-display buffer window returns nil. It should return non-nil.
In my setup the windows of buffers such as `*Buffer List*' and `*info*'
should definitely be dedicated. They are special-display buffers (and
their special-display-frame backgrounds confirm this).
As the manual says, and as has always been the behavior in previous
Emacs versions, "By default, special display means to give the buffer a
dedicated frame."
The frames showing special-display buffers should be dedicated frames.
Clicking mouse-2 on a buffer name in `*Buffer List*' should not visit
that buffer in the same window/frame.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-06-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated
2011-06-13 16:08 bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated Drew Adams
@ 2011-06-13 18:00 ` martin rudalics
2011-06-13 18:41 ` Drew Adams
0 siblings, 1 reply; 4+ messages in thread
From: martin rudalics @ 2011-06-13 18:00 UTC (permalink / raw)
To: Drew Adams; +Cc: 8851
> Similarly, M-: (window-dedicated-p (selected-window)) in any
> special-display buffer window returns nil. It should return non-nil.
Does the patch below fix it?
martin
=== modified file 'lisp/window.el'
*** lisp/window.el 2011-06-13 08:21:09 +0000
--- lisp/window.el 2011-06-13 17:53:54 +0000
***************
*** 4372,4378 ****
(dedicated (cdr (assq 'dedicated specifiers)))
(no-other-window (cdr (assq 'no-other-window specifiers))))
;; Show BUFFER in WINDOW.
- (set-window-dedicated-p window nil)
(set-window-buffer window buffer)
(when dedicated
(set-window-dedicated-p window dedicated))
--- 4372,4377 ----
***************
*** 4482,4487 ****
--- 4481,4488 ----
(window-point best-window) buffer
(window-total-size best-window) (selected-window)))))
+ ;; Reset dedicated status of best-window here.
+ (set-window-dedicated-p best-window nil)
(display-buffer-in-window buffer best-window specifiers))))
(defconst display-buffer-split-specifiers '(largest lru selected root left top right bottom)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated
2011-06-13 18:00 ` martin rudalics
@ 2011-06-13 18:41 ` Drew Adams
2011-06-14 9:15 ` martin rudalics
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2011-06-13 18:41 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 8851
> Does the patch below fix it?
Thanks for your quick reply, Martin. No, I'm afraid it doesn't change anything
wrt this bug.
I didn't download the latest source files to apply your patch, but the build I'm
using is supposedly from today. I applied your patch manually to its source
code, which means that I eval'ed these two updated definitions (below). That
didn't help.
(defun display-buffer-in-window (buffer window specifiers)
"Display BUFFER in WINDOW and raise its frame if needed.
WINDOW must be a live window and defaults to the selected one.
Return WINDOW.
SPECIFIERS must be a list of buffer display specifiers, see the
documentation of `display-buffer-alist' for a description."
(setq buffer (normalize-live-buffer buffer))
(setq window (normalize-live-window window))
(let* ((old-frame (selected-frame))
(new-frame (window-frame window))
(dedicated (cdr (assq 'dedicated specifiers)))
(no-other-window (cdr (assq 'no-other-window specifiers))))
;; Show BUFFER in WINDOW.
;;---- (set-window-dedicated-p window nil)
(set-window-buffer window buffer)
(when dedicated
(set-window-dedicated-p window dedicated))
(when no-other-window
(set-window-parameter window 'no-other-window t))
(unless (eq old-frame new-frame)
(display-buffer-select-window window))
;; Return window.
window))
(defun display-buffer-reuse-window (buffer method &optional specifiers)
"Display BUFFER in an existing window.
METHOD must be a list in the form of the cdr of a `reuse-window'
buffer display specifier, see `display-buffer-alist' for an
explanation. The first element must specifiy the window to use,
and can be either nil, `same', `other', or a live window. The
second element must specify the window's buffer and can be either
nil, `same', `other', or a live buffer. The third element is the
frame to use - either nil, 0, `visible', `other', t, or a live
frame.
Optional argument SPECIFIERS must be a list of valid display
specifiers. Return the window chosen to display BUFFER, nil if
none was found."
(let* ((method-window (nth 0 method))
(method-buffer (nth 1 method))
(method-frame (nth 2 method))
(reuse-dedicated (assq 'reuse-window-dedicated specifiers))
windows other-frame dedicated time best-window best-time)
(when (eq method-frame 'other)
;; `other' is not handled by `window-list-1'.
(setq other-frame t)
(setq method-frame t))
(dolist (window (window-list-1 nil 'nomini method-frame))
(let ((window-buffer (window-buffer window)))
(when (and (not (window-minibuffer-p window))
;; Don't reuse a side window.
(or (not (eq (window-parameter window 'window-side) 'side))
(eq window-buffer buffer))
(or (not method-window)
(and (eq method-window 'same)
(eq window (selected-window)))
(and (eq method-window 'other)
(not (eq window (selected-window))))
;; Special case for applications that specifiy
;; the window explicitly.
(eq method-window window))
(or (not method-buffer)
(and (eq method-buffer 'same)
(eq window-buffer buffer))
(and (eq method-buffer 'other)
(not (eq window-buffer buffer)))
;; Special case for applications that specifiy
;; the window's buffer explicitly.
(eq method-buffer window-buffer))
(or (not other-frame)
(not (eq (window-frame window) (selected-frame))))
;; Handle dedicatedness.
(or (eq window-buffer buffer)
;; The window does not show the same buffer.
(not (setq dedicated (window-dedicated-p window)))
;; If the window is weakly dedicated to its
;; buffer, reuse-dedicated must be non-nil.
(and (not (eq dedicated t)) reuse-dedicated)
;; If the window is strongly dedicated to its
;; buffer, reuse-dedicated must be t.
(eq reuse-dedicated t)))
(setq windows (cons window windows)))))
(if (eq method-buffer 'same)
;; When reusing a window on the same buffer use the lru one.
(dolist (window windows)
(setq time (window-use-time window))
(when (or (not best-window) (< time best-time))
(setq best-window window)
(setq best-time time)))
;; Otherwise, sort windows according to their use-time.
(setq windows
(sort windows
#'(lambda (window-1 window-2)
(<= (window-use-time window-1)
(window-use-time window-2)))))
(setq best-window
;; Try to get a full-width window (this is silly and can
;; get us to another frame but let's ignore these issues
;; for the moment).
(catch 'found
(dolist (window windows)
(when (window-full-width-p window)
(throw 'found window)))
;; If there's no full-width window return the lru window.
(car windows))))
(when best-window
(display-buffer-even-window-sizes best-window specifiers)
;; Never change the quit-restore parameter of a window here.
(if (eq (window-buffer best-window) buffer)
(setq display-buffer-window
(cons best-window 'reuse-buffer-window))
(setq display-buffer-window
(cons best-window 'reuse-other-window))
(unless (window-parameter best-window 'quit-restore)
;; Don't overwrite an existing quit-restore entry.
(set-window-parameter
best-window 'quit-restore
(list (window-buffer best-window) (window-start best-window)
(window-point best-window) buffer
(window-total-size best-window) (selected-window)))))
;; Reset dedicated status of best-window here.
(set-window-dedicated-p best-window nil)
(display-buffer-in-window buffer best-window specifiers))))
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated
2011-06-13 18:41 ` Drew Adams
@ 2011-06-14 9:15 ` martin rudalics
2011-06-14 20:36 ` Drew Adams
0 siblings, 1 reply; 4+ messages in thread
From: martin rudalics @ 2011-06-14 9:15 UTC (permalink / raw)
To: Drew Adams; +Cc: 8851
> I didn't download the latest source files to apply your patch, but the build I'm
> using is supposedly from today. I applied your patch manually to its source
> code, which means that I eval'ed these two updated definitions (below). That
> didn't help.
The first thing I would have to know is if `special-display-popup-frame'
gets called with your setup. If, with emacs -Q, I evaluate
(let* ((special-display-regexps '("[ ]?[*][^*]+[*]"))
(window (display-buffer (get-buffer-create "*foo*"))))
(message "%s" (cons window (window-dedicated-p window))))
here, Emacs pops up a new frame and the message tells me the window and
that that window is strongly dedicated to its buffer. If it does so on
your system, please try to step through `special-display-popup-frame'
once with your old, working Emacs and once with the latest version. The
differences in arguments and behaviors should tell us what went wrong.
martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated
2011-06-14 9:15 ` martin rudalics
@ 2011-06-14 20:36 ` Drew Adams
[not found] ` <4DFB6BBF.3080504@gmx.at>
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2011-06-14 20:36 UTC (permalink / raw)
To: 'martin rudalics'; +Cc: 8851
> here, Emacs pops up a new frame and the message tells me the
> window and that that window is strongly dedicated to its buffer.
> If it does so on your system,
It does here too.
> please try to step through `special-display-popup-frame'
> once with your old, working Emacs and once with the latest
> version. The
> differences in arguments and behaviors should tell us what went wrong.
Keep in mind that using the debugger can be problematic because buffer
*Backtrace* itself is a special-display buffer. But I was able to do so to get
some more info.
(BTW, these debugging problems are worse in the latest build - `q' does not even
exit the debugger; and when you get back to the top level buffer *Backtrace*
still contains a backtrace from execute-extended-command up through
special-display-popup-frame; etc.)
The difference is that, unlike in last week's build, in this week's build
`special-display-popup-frame' does not call the special-display function
`1on1-display-*Completions*-frame'.
Here is the call in last week's build:
* 1on1-display-*Completions*-frame(
#<buffer *Completions*>
((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100)))
* apply(1on1-display-*Completions*-frame #<buffer *Completions*>
((background-color ...)))
* (if (and args (symbolp (car args)))
(apply (car args) buffer (cdr args))
(let ((window (get-buffer-window buffer 0)))
(or (when window (let ((frame (window-frame window)))
(make-frame-visible frame)
(raise-frame frame)
window))
(when (cdr (assq (quote same-window) args))
(condition-case nil
(progn (switch-to-buffer buffer) (selected-window))
(error nil)))
(when (or (cdr (assq (quote same-frame) args))
(cdr (assq (quote same-window) args)))
(let* ((pop-up-windows t)
pop-up-frames special-display-buffer-names
special-display-regexps)
(display-buffer buffer)))
(let ((frame (with-current-buffer buffer (make-frame ...))))
(set-window-buffer (frame-selected-window frame) buffer)
(set-window-dedicated-p (frame-selected-window frame) t)
(frame-selected-window frame)))))
special-display-popup-frame(
#<buffer *Completions*>
(1on1-display-*Completions*-frame
((background-color ...)))))
* display-buffer(#<buffer *Completions*> nil nil)
And here is the call in this week's build:
Debugger entered--returning value: (background-color . "LavenderBlush2")
car(((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100)))
* (symbolp (car args))
* (and args (symbolp (car args)))
* (if (and args (symbolp (car args)))
(apply (car args) buffer (cdr args))
(let ...
IOW, what seems to be happening is that the first arg is not a symbol, so the
`if' branch that applies the special-display function (the symbol that is the
car) to its args (the cdr) is not taken at all.
The args to `special-display-popup-frame' are different in the two builds. For
last week's build, they are:
special-display-popup-frame(
#<buffer *Completions*>
(1on1-display-*Completions*-frame
((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100))))
For this week's build they are:
special-display-popup-frame(
#<buffer *Completions*>
((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100)))
However, the *Completions* frame does seem to have the correct alist (background
color etc.). That apparently happens in the other `if' branch, here:
* (append args special-display-frame-alist)
* (make-frame (append args special-display-frame-alist))
IOW, the special-display function, `1on1-display-*Completions*-frame' is not
called by `special-display-popup-frame' in the new build.
However, as I said before, `1on1-display-*Completions*-frame' is called, but
only by `display-buffer'. Here is a backtrace from debugging only entry to
`1on1-display-*Completions*-frame' (not entry to `special-display-popup-frame'):
1on1-display-*Completions*-frame(
#<buffer *Completions*>
((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100)))
* apply(
1on1-display-*Completions*-frame
#<buffer *Completions*>
((background-color . "LavenderBlush2")
(mouse-color . "VioletRed")
(cursor-color . "VioletRed")
(menu-bar-lines . 0)
(tool-bar-lines . 0)
(width . 100)))
display-buffer(#<buffer *Completions*> nil nil)
internal-temp-output-buffer-show(#<buffer *Completions*>)
minibuffer-completion-help()
completion--do-completion()
minibuffer-complete()
That call to `1on1-display-*Completions*-frame' does do (set-window-dedicated-p
#<window 48 on *Completions*> t). And in the debugger evaluating
(window-dedicated-p (get-buffer-window "*Completions*" 0)) returns t. And also
this gets evaluated (to nil), with *Completions* as the selected frame:
* (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)
So I don't really understand what the problem is. In any case, it's clear that
the first branch of the `if' in `special-display-popup-frame' is not being
taken, and that `1on1-display-*Completions*-frame' is getting called by
`display-buffer' before it even calls `special-display-popup-frame'.
It took me a long time to get this far. I hope you can take it from here.
In any case, I gave you a complete recipe. You can do exactly what you asked me
to do just now. See for yourself what the problems are. You need only download
the two files I mentioned, oneonone.el and hexrgb.el.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-06-19 19:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-13 17:43 bug#8856: 24.0.50; regression: `special-display-popup-frame' broken Drew Adams
2011-06-14 9:15 ` martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2011-06-13 16:08 bug#8851: 24.0.50; regression: special-display-frame is no longer dedicated Drew Adams
2011-06-13 18:00 ` martin rudalics
2011-06-13 18:41 ` Drew Adams
2011-06-14 9:15 ` martin rudalics
2011-06-14 20:36 ` Drew Adams
[not found] ` <4DFB6BBF.3080504@gmx.at>
2011-06-17 15:51 ` Drew Adams
2011-06-17 17:48 ` bug#8856: " Drew Adams
[not found] ` <4DFE09A7.10500@gmx.at>
2011-06-19 14:43 ` Drew Adams
2011-06-19 17:26 ` Drew Adams
2011-06-19 18:40 ` martin rudalics
2011-06-19 19:34 ` bug#8856: 24.0.50; regression: `special-display-popup-frame' broken Drew Adams
2011-06-19 19:52 ` Drew Adams
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.