bug#8856: 24.0.50; regression: `special-display-popup-frame' broken

bug#8856: 24.0.50; regression: `special-display-popup-frame' broken

[Drew Adams]

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'
 

bug#8856: 24.0.50; regression: `special-display-popup-frame' broken

[martin rudalics]

 > 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

bug#8856: 24.0.50; regression: `special-display-popup-frame' broken

[Drew Adams]

>  > This then raises the error
>  > "Buffer is read-only #<buffer *Completions*>"
> 
> It does.  But it does the same on an old verion of trunk here 
> too.  Are you sure that the version of throw-one.el you sent
> me works with your old Emacs?

Yes, I'm sure.  I just re-tested using throw-one.el with both Emacs 23.3 and
with a build from the week before your code was added, 2011-06-03.

However, I had to remove the line I had added to throw-one.el to load your
window.el, since otherwise I got an error saying that function `window-list-1'
is void.

IOW, I cannot test an older build with your new window.el, because of that
error, but I can test an older build without any of your additions. Things work
fine with the older builds, starting from emacs -Q, with throw-one.el (minus the
line loading your new window.el).

When I test using any such old builds, the minibuffer frame keeps the focus
properly, so there is no error saying that *Completions* is read-only.  IOW, the
focus redirection from the *Completions* frame to the minibuffer frame works (in
the versions prior to your addition).

> BTW, in both versions I get the error when I hit c-] already.

I do not get any error when I hit `C-]'.  Instead I get the normal behavior for
`C-]', with the message `Quit' in the echo area.  What you're seeing sounds like
another bug (even in older releases apparently), on your platform but not on
mine (Windows).  `C-]' (`abort-recursive-edit') should just exit to the top
level and print `Quit' in this case.

Maybe, if you cannot reproduce the bug I reported, it is MS Windows-specific.

> Anyway, let's see what happens.  `display-buffer' should
> execute this part...  So I can't imagine that `display-buffer'
> got anything to do with this.

I don't quite follow you here.  Was there something you wanted me to check about
that?

> However, I noticed that I have changed `pop-to-buffer'.  Does 
> it help if you use the version below?  It doesn't help here as
> I explained above.
>
> (defun pop-to-buffer...

No, that changes nothing, unfortunately.  I see exactly the same behavior (and
different behavior apparently from what you see).

This is one reason I wanted you to just load the original files I sent and see
if you could reproduce the problem, as a start.  It's looking like the bug might
be Windows-specific.

Anyway, we at least now have a pared-down file to test with.

Thx.

bug#8856: 24.0.50; regression: `special-display-popup-frame' broken

[Drew Adams]

Does it help if I give you the value of `display-buffer-alist'?

Here is the value in a test that manifests the bug (i.e., using throw-one.el and
your latest window.el), as shown by `C-h v':

Value: ((((regexp . ".*"))
  reuse-window
  (reuse-window nil same visible)
  pop-up-window
  (pop-up-window
   (largest)
   (lru))
  pop-up-frame
  (pop-up-frame)
  reuse-window
  (reuse-window nil other visible)
  (reuse-window-even-sizes . t)))

Original value was 
((((regexp . ".*"))
  reuse-window
  (reuse-window nil same visible)
  pop-up-window
  (pop-up-window
   (largest)
   (lru))
  (pop-up-window-min-height . 40)
  (pop-up-window-min-width . 80)
  reuse-window
  (reuse-window other nil nil)
  (reuse-window-even-sizes . t)))