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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8856 in the body.
You can then email your comments to 8856 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; regression: `special-display-popup-frame' broken
Date: Mon, 13 Jun 2011 10:43:07 -0700

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'
 

Message #8 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: `special-display-popup-frame'
	broken
Date: Tue, 14 Jun 2011 11:15:50 +0200

> 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

Message #11 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8851 <at> debbugs.gnu.org, 8856 <at> debbugs.gnu.org
Subject: RE: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Fri, 17 Jun 2011 08:51:18 -0700

> From: martin rudalics (private mail)
> I've checked in a fix that should address this issue.  I 
> attached a copy of the latest window.el.  Please report on the
> list whether it works.

Thanks for working on this.  But I'm sorry to say that no, it not only does not
help, it makes things worse.

Now, when I hit `C-x C-b' I get `*Buffer List*' in the same (regular) frame - it
just replaces the current buffer in its window. 

What should happen is that `*Buffer List*' gets popped up in its own,
special-display frame (separate frame, different frame properties from regular
frames).

Here is a recipe (you just need to download the same 2 files as for the recipe
for bug #8856).  In fact, my reply to you with the debugger info, in this #8851
thread, involves this same startup recipe.

Let me repeat the startup recipe, which holds for both of these bugs (different
symptoms), #8851 and #8856:

runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
 
Download the two files mentioned from here:
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24

For the rest of the bug #8851 recipe, see the initial bug report.

----

Wrt bug #8856 also, the same symptoms reported initially are still there (frame
selection/focus problem).

Plus, now the special-display frame that I define for `*Completions*' is not
even used.  Instead, buffer/window `*Completions*' is shown in a regular frame.

Please try the recipe for #8856, starting with the same Emacs startup recipe
shown above, and I think you will see the same things I see.  IOW, you should be
able to reproduce both problems from runemacs -Q.

Here again is that recipe (after startup as shown above):

> 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*>"

----

If you cannot reproduce these two problems then maybe there is an
MS-Windows-specific issue somewhere.  But I'm guessing that you will be able to
reproduce them from the runemacs -Q startup shown here.  Let me know if
something is not clear.
 

Message #14 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8851 <at> debbugs.gnu.org, 8856 <at> debbugs.gnu.org
Subject: Re: bug#8851: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Fri, 17 Jun 2011 18:22:23 +0200

> Now, when I hit `C-x C-b' I get `*Buffer List*' in the same (regular) frame - it
> just replaces the current buffer in its window.
>
> What should happen is that `*Buffer List*' gets popped up in its own,
> special-display frame (separate frame, different frame properties from regular
> frames).

So you somewhere have settings for this buffer in
`special-display-buffer-names' or `special-display-regexps'.  Why can't
you send me them?

> Here is a recipe (you just need to download the same 2 files as for the recipe
> for bug #8856).  In fact, my reply to you with the debugger info, in this #8851
> thread, involves this same startup recipe.

I need a simple recipe from emacs -Q.  If you use an outside function in
any of these please use a dummy function I can run on both Emacs 23 and
Emacs 24 to see the differences.  If it's already difficult for you to
go through the debugger with your functions why do you think I can do
any better?  What I need are your settings wrt special-display-... and
the buffer in question.  Why can't you post these?

> Wrt bug #8856 also, the same symptoms reported initially are still there (frame
> selection/focus problem).
>
> Plus, now the special-display frame that I define for `*Completions*' is not
> even used.  Instead, buffer/window `*Completions*' is shown in a regular frame.

Probably because `pop-up-frames' is t on your system so
`pop-up-frame-alist' prevails.  Again, what are the
special-display-... related values for *Completions*?

martin

Message #17 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Fri, 17 Jun 2011 10:48:50 -0700

>  > Wrt bug #8856 also, the same symptoms reported initially 
>  > are still there (frame selection/focus problem).
>  >
>  > Plus, now the special-display frame that I define for 
>  > `*Completions*' is not even used.  Instead, buffer/window
>  > `*Completions*' i shown in a regular frame.
> 
> Probably because `pop-up-frames' is t on your system so
> `pop-up-frame-alist' prevails.  Again, what are the
> special-display-... related values for *Completions*?

`pop-up-frames' is t, from oneonone.el.
I do not define `pop-up-frame-alist'.

I gave you the value of `special-display-regexps'.  Here it is again: ("[
]?[*][^*]+[*]"))

>  > Here again is that recipe (after startup as shown above):
>  > > 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*>"

The recipe, one more time:

runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
 
Download the two files mentioned from here:
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24

1. Load your new window.el that you just sent me (but see below).

2. (setq special-display-regexps '("[ ]?[*][^*]+[*]"))

So far, the recipe is the same for bug #8851 and #8856.  Now it changes.

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

The bug reported for #8856 is that this then raises the error
"Buffer is read-only #<buffer *Completions*>"

However, as I said, with the window.el version you just sent me there is now an
additional bug - presumably the same additional bug mentioned in #8851 (wrt
buffer `*Buffer List*'): `*Completions*' is no longer shown in a special-display
frame at all.  It is now shown in the same window of the original buffer
(`*scratch*' presumably, by default from emacs -Q).

Can you reproduce the problems?  Try first without step #1, to see the bug I
reported.  Try with step #1 to see that your fix just adds another problem.

The first step is to reproduce the problem.  Then we can try to debug it.

Message #20 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sun, 19 Jun 2011 15:26:21 +0200

> The recipe, one more time:
>
> runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
>
> Download the two files mentioned from here:
> http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
> 3F%24

I'm not going to do that.  If you can provide me a self-contained test
that doesn't require to download any files I shall follow your advices.

But I have done the check below.

When I add the name of a buffer *text* to `special-display-buffer-names'
I have three choices - a plain string, an alist of parameter value
pairs, or a function with arguments.  These give the three cases below
when evaluating (display-buffer (get-buffer-create "*text*")):

(1) special-display-buffer-names --> ("*text*")

    calls `special-display-popup-frame' with the argument

    nil

(2) special-display-buffer-names --> (("*text*" (x . 3) (y . 4)))

    calls `special-display-popup-frame' with the argument

    ((x . 3) (y . 4))

(3) special-display-buffer-names -->  (("*text*" ignore (3 4)))

    calls `special-display-popup-frame' with the argument

    (ignore (3 4))

All three cases give the same results here for `display-buffer' before
and after my changes.  If you see the same values, the handling of
special buffers is not affected by the changes.  If you see a different
behavior, please tell me what you see.

martin

Message #23 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;regression: `special-display-frame' broken
Date: Sun, 19 Jun 2011 07:31:23 -0700

[Message part 1 (text/plain, inline)]

>  > The recipe, one more time:
>  >
>  > runemacs.exe -Q --debug-init -l "hexrgb.el" -l 
>  > "oneonone.el" -f "1on1-emacs"
>  >
>  > Download the two files mentioned from here:
>  > 
>  >
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24
> 
> I'm not going to do that.  If you can provide me a self-contained test
> that doesn't require to download any files I shall follow 
> your advices.

I see.  You introduce a regression but won't click a link.

OK, in that case see attached.  These are the same two files for the recipes of
the other regressions reported.  They are not large, and they are all you need -
the recipe is a self-contained test.

> But I have done the check below.
> 
> When I add the name of a buffer *text*
> to `special-display-buffer-names'

Please follow the recipe.  As you know, buffer *Completions* is not just any
buffer - it is not *text*.  It is closely connected with the minibuffer.  And in
this case the minibuffer is in a standalone frame.  And frame focus for the
*Completions* frame is redirected to the minibuffer frame.

I have explained all of that, and it is all in the recipe code that you can
test.
  
> I have three choices - a plain string, an alist of parameter value
> pairs, or a function with arguments.  These give the three cases below
> when evaluating (display-buffer (get-buffer-create "*text*")):

Why invent?  I gave you exactly which of the three choices is used.  If you
simply look at the code or load it and use `C-h v special-display-buffer-names'
you'll see it:

Value: (("*Completions*" 1on1-display-*Completions*-frame
  ((background-color . "LavenderBlush2")
   (mouse-color . "VioletRed")
   (cursor-color . "VioletRed")
   (menu-bar-lines . 0)
   (tool-bar-lines . 0)
   (width . 100)))
 ("*Help*" 1on1-display-*Help*-frame
  ((background-color . "Thistle")
   (mouse-color . "Blue Violet")
   (cursor-color . "Blue Violet")
   (height . 40))))

> (3) special-display-buffer-names -->  (("*text*" ignore (3 4)))
>      calls `special-display-popup-frame' with the argument
> 
>      (ignore (3 4))
> 
> All three cases give the same results here for `display-buffer' before
> and after my changes.  If you see the same values, the handling of
> special buffers is not affected by the changes.  If you see a 
> different behavior, please tell me what you see.

See above.  *Completions* is not *text*.  *Completions* is tied to the
minibuffer.  The minibuffer is in a standalone frame.  The *Completions* frame
focus is redirected to the minibuffer frame.

Please try the simple (3-4 lines) recipe, using the attached code.  That's the
first step: reproduce the problem.

Then we can try to dig down to its kernel and find a solution.  You haven't even
taken the 1-2 minutes needed to see if you can reproduce it on your system.

[hexrgb.el (application/octet-stream, attachment)]

[oneonone.el (application/octet-stream, attachment)]

Message #26 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 19 Jun 2011 07:43:50 -0700

> There was a bug that caused `pop-up-frames' be processed before
> `special-display-p'.  I attach the latest version of window.el.
> 
> Please try again.

Will do.

And I will try to pare down the two files a bit for reproducing this.  But
please at least try the simple recipe using those two files (likewise the recipe
for bug #8851, using the same two files), to see if you can at least reproduce
the problem on your platform.

Message #29 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 19 Jun 2011 10:26:39 -0700

[Message part 1 (text/plain, inline)]

I've pared down the code to load.  Just load the attached and then follow the
recipe:

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 then raises the error
"Buffer is read-only #<buffer *Completions*>"

[throw-one.el (application/octet-stream, attachment)]

Message #32 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sun, 19 Jun 2011 20:40:27 +0200

> I've pared down the code to load.  Just load the attached and then follow the
> recipe:
>
> 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 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?

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

Anyway, let's see what happens.  `display-buffer' should execute this
part

      (while (and specifiers (not (window-live-p window)))
	...
	(setq window
               ... 	
	       ((eq method 'fun-with-args)
		(apply (cadr specifier) buffer (cddr specifier))))))

calling

(defun 1on1-display-*Completions*-frame (buf &optional args)
  "..."
  (let (return-window)
    (setq return-window (select-window
                         (funcall special-display-function buf args)))
    (raise-frame)
    (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)
    return-window))

returning return-window.  After that `display-buffer' leaves the loop
because return-window is hopefully live and

      (or (and (window-live-p window) window)

returns window (that is your return-window).  So I can't imagine that
`display-buffer' got anything to do with this.

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.

martin


(defun pop-to-buffer (&optional buffer-or-name specifiers norecord label)
  "..."
  (interactive "BPop to buffer:\nP")
  (let ((buffer (normalize-buffer-to-display buffer-or-name))
	(old-window (selected-window))
	(old-frame (selected-frame))
	new-window new-frame)
    (set-buffer buffer)
    (setq new-window (display-buffer buffer specifiers label))
    (unless (eq new-window old-window)
      ;; `display-buffer' has chosen another window, select it.
      (select-window new-window norecord)
      (setq new-frame (window-frame new-window))
      (unless (eq new-frame old-frame)
	;; `display-buffer' has chosen another frame, make sure it gets
	;; input focus and is risen.
	(select-frame-set-input-focus new-frame)))
    buffer))

Message #35 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'martin rudalics' <rudalics <at> gmx.at>, 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50;regression: `special-display-frame' broken
Date: Sun, 19 Jun 2011 14:50:38 -0400

"Drew Adams" <drew.adams <at> oracle.com> writes:

> I see.  You introduce a regression but won't click a link.
>
> OK, in that case see attached.  These are the same two files for the recipes of
> the other regressions reported.  They are not large, and they are all you need -
> the recipe is a self-contained test.

A test case consisting of 1600+ lines of complicated Elisp code is not a
good basis for debugging.  Since you are the one who wrote the code, you
are in the best position to try to isolate parts relevant to the recent
changes.

Message #38 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: 'martin rudalics' <rudalics <at> gmx.at>, 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;regression: `special-display-frame' broken
Date: Sun, 19 Jun 2011 11:54:22 -0700

> A test case consisting of 1600+ lines of complicated Elisp 
> code is not a good basis for debugging.  Since you are the
> one who wrote the code, you are in the best position to try
> to isolate parts relevant to the recent changes.

I did pare down the code thereafter, which took some time.

I was asking that the code be tried first as is, as the recipe is trivial and
quick.  That would at least determine whether you can reproduce it on your
(non-Windows) platform.

Message #41 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: `special-display-popup-frame' broken
Date: Sun, 19 Jun 2011 12:34:54 -0700

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

Message #44 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: `special-display-popup-frame' broken
Date: Sun, 19 Jun 2011 12:52:20 -0700

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

Message #47 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Mon, 20 Jun 2011 11:46:49 +0200

> I've pared down the code to load.  Just load the attached and then follow the
> recipe:
>
> 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 then raises the error
> "Buffer is read-only #<buffer *Completions*>"

I suppose that after "loading the attached" I have to call `1on1-emacs'
in order to set up things first.  Only then I should try the M-x f TAB
stuff.

If I do that, I can see different behaviors indeed.  I'll look into
this.

martin

Message #50 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Mon, 20 Jun 2011 06:01:22 -0700

>  > I've pared down the code to load.  Just load the attached 
>  > and then follow the recipe:
>  > 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 then raises the error
>  > "Buffer is read-only #<buffer *Completions*>"
> 
> I suppose that after "loading the attached" I have to call 
> `1on1-emacs' in order to set up things first.  Only then I should
> try the M-x f TAB stuff.
> 
> If I do that, I can see different behaviors indeed.  I'll look into
> this.

Great, thanks.

Actually, I meant that you need to do this, as stated earlier (for the earlier
load files):

runemacs.exe -Q --debug-init -l "throw-one.el" -f "1on1-emacs"

IOW, I believe that you must invoke `1on1-emacs' from the command line this way,
so it is called before any frames are displayed.

Otherwise, you will end up with two minibuffers: the standalone minibuffer frame
will not function for some things; rather, the initial minibuffer (in a normal
frame) will be used.

At least that's what I see on Windows, and I expect that it is the case for you
too.  Please run Emacs this way for testing this, so we're on the same page.

Message #53 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Tue, 21 Jun 2011 11:10:58 -0700

>  > Please run Emacs this way for testing this, so we're on 
>  > the same page.
> 
> I know what the bug is now.  The old code ran some very complicated
> raise-frame mechanism but did _not_ select the window if it already
> existed on another frame.  That's what I changed in the new 
> code to make it uniform with the pop-up-a-new-frame behavior.  
> Apparently that was a bad idea.  I now (hopefully) reverted the
> old behavior.
> 
> Attached find the latest window.el.  It only works with the latest two
> versions uploaded by Sean.  If you get any warnings or bugs 
> when loading or compiling it please tell me.

I'll give it a try and let you knonw.  Thanks for struggling with all of this,
and for trying to improve the handling of windows and frames - a daunting task,
no doubt.

> Also, `display-buffer-alist' will unlikely work with your code
> yet.  So you need to trigger 1on1 using the old options.

I'm not sure what you mean, in particular by the last sentence.  Are you
referring to how command `1on1-emacs' is invoked or to something else?

I assume that I would at least need to replace the assignment, in `1on1-emacs',
of `pop-up-frames' to `t' by something else, presumably something involving
`display-buffer-alist'.

Are you saying that there is not yet any good replacement in this case?  Will
you let me know when you have an idea what I can do, to DTRT, once the "yet" is
dealt with?

> Redirecting frame focus is not very easy to handle :-(

I am sure of that.  And most users have nil `pop-up-frames' (or equivalent), and
they never have to deal with focus redirection.  Likewise most Emacs
maintainers.

I've been trying to get Emacs Dev to think (and test!) more in terms of frames
for years.  Frames are nearly second-class citizens for Emacs.  Development and
maintenance changes have often, I think, been tested only with `pop-up-frames' =
nil.  Certainly they are more tested in that case than in the non-nil case.
Frames are almost an afterthought.

Partly this is no doubt due to frames being handled differently by different
window mgrs.  Partly it may be due to habit (Emacs had windows before frames,
most users do not use non-nil `pop-up-frames', etc.).

--

BTW, as you might have noticed in looking at command `1on1-emacs' and
`oneonone.el' generally, it presents an example of why it is wrong to think that
code should never bind or set user options.  I mention this because (you think
that) you disagree.

Emacs base code should not overrule user settings, of course.  But code that is
invoked by user choice is another story.  A user chooses to invoke a command,
just as s?he chooses option settings and other default values.

It is helpful for the command's doc in this case to mention that it temporarily
binds such-and-such user option to such-and-such value or that it sets the
option (i.e. not just temporarily), etc.

But there is no reason that a voluntarily invoked command should not alter a
user setting.  The moral obligation is to let users know just what the
consequences of invocation are, including option changes.  A user of command
`1on1-emacs' should know that it sets `pop-up-frames' to t, and that that is
precisely part of the command's raison d'etre.  You use `1on1-emacs' only if you
want non-nil `pop-up-frames'.

Emacs has always allowed for and even provided option-altering commands.  See
`customize-set-variable', `customize-set-value', and `set-variable', for
instance.

Personally, although I try to convince users to use Customize rather than just
Lisp code, I also believe it is helpful to go beyond Customize as an interactive
way to modify options and faces.

I've done that with Do Re Mi, for instance: provide commands to easily modify
option values incrementally.  Nothing wrong with that - in fact, we could use
more of it.  Nothing should limit us to the Customize UI as the only way to
interactively change user settings.

Message #56 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Tue, 21 Jun 2011 17:13:24 -0700

> I know what the bug is now.
> Attached find the latest window.el.

I tried it, using a new build from Sean (from 6/20).  I tested it with my full
setup (oneonone.el etc., not just the pared-down file I sent you).

I still see the problem reported for this bug: focus of *Completions* is not
being redirected to the minibuffer frame.  I get the same read-only error.

But now I see that problem only when the *Completions* frame is created, not
when the frame is already displayed.  That's the _opposite_ behavior from
before: Previously, if the frame was already displayed then I got the error, but
not when it was first displayed (created).

Also, now I do not get the appearance that I defined for the *Completions*
frame.  The frame background color is that of a normal frame etc.  This is true
in the latest build, whether I load your new window.el or not.

However, buffer *Help* is correctly displayed according to its special-display
function, `1on1-display-*Help*-frame' - it has the proper background color etc.

Also, when I byte-compiled the file (to test that as you requested):

1. The *Compile-Log* buffer was not displayed.  That's probably because it had
only this in it (so probably this is not a problem):
Compiling file .../window-2011-06-21a-MARTIN.el at Tue Jun 21 11:38:26 2011

2. When I click mouse-2 on buffer *Compile-Log* in the buffer list, or I use C-x
4 b to choose it, buffer *Compile-Log* is displayed in an ordinary frame, not in
a special-display frame as it should be.  This, in spite of the fact that M-:
(string-match "[ ]?[*][^*]+[*]" "*Compile-Log*") returns 0; that string is the
only one in my `special-display-buffer-regexps'.

(What's more, my automatic frame-fitting is not invoked now, so the frame is
tiny.  I'll worry about that separately, for now.)

Other buffers that should have special-display frames (e.g. whose names match
`special-display-buffer-regexps') are correctly shown in the default
special-display frames, however.

Message #59 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Tue, 21 Jun 2011 17:14:17 -0700

> I tested it with my full setup (oneonone.el etc., not just the 
> pared-down file I sent you).
> I still see the problem reported for this bug: focus of 
> *Completions* is not being redirected to the minibuffer 
> frame.  I get the same read-only error.
> But now I see that problem only when the *Completions* frame 
> is created, not when the frame is already displayed.  That's 
> the _opposite_ behavior from before...
> Also, now I do not get the appearance that I defined for the 
> *Completions* frame.  The frame background color is that of a 
> normal frame etc.  This is true in the latest build, whether 
> I load your new window.el or not.

I also tested using throw-one.el (but with the file loaded at the end being your
latest window.el, not the one from 6/19).  With that test:

1. *Completions* is shown with the proper frame background.
2. But it does not seem to be dedicated, in this sense:

If you do `M-x f TAB o TAB' everything seems fine, but if you then hit `rwa TAB'
(matching all commands that start with `forward-'), buffer *Completions* gets
replaced by buffer *scratch* in its frame.  Hitting TAB again puts *Completions*
back there, but *scratch* should never appear in that dedicated frame/window.
You can see the same thing (*scratch* replacing *Completions*) if you just type
something that has no match: `M-x f TAB qqqqqqqqq'.

However, (window-dedicated-p (get-buffer-window "*Completions*" 0)) returns t,
so officially it is dedicated.  The window, at least.  Maybe the window itself
is being replaced in that frame by another window?  No idea.

3. I do not see the read-only-error problem I reported earlier today from using
my full setup, so this pared-down test is no longer sufficient to get that.  I
also do not see that error if I use the original recipe, with just hexrgb.el and
oneonone.el.  So I'll have to start again from my full setup and pare down to
something smaller.  I cannot do that right away, however.

Thx, HTH.

Message #62 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Tue, 21 Jun 2011 17:15:10 -0700

[Message part 1 (text/plain, inline)]

> 3. I do not see the read-only-error problem I reported 
> earlier today from using my full setup, so this pared-down 
> test is no longer sufficient to get that.  I also do not see 
> that error if I use the original recipe, with just hexrgb.el 
> and oneonone.el.  So I'll have to start again from my full 
> setup and pare down to something smaller.  I cannot do that 
> right away, however.

OK, I've now pared down from my full setup again.  Took quite a while.

Use the attached file, starting Emacs, as before, this way, where the first load
file is your latest window.el:

runemacs.exe -Q --debug-init  -l "window-2011-06-21a-MARTIN.el" -l
"throw-three.el" -f "1on1-emacs"

Then, as before (but no need to exit to top level before typing more chars):

M-x f TAB o

When you hit TAB, *Completions* is shown in its frame, as expected. As soon as
you hit the second char (`o'), you get the read-only error.


Note: In the file, both of these two lines are necessary, to cause the error:

(add-hook 'post-command-hook '1on1-fit-minibuffer-frame)
(setq w32-grab-focus-on-raise    nil)

The second is of course Windows-specific.  If I comment that out then the error
is not raised, but instead when I hit `o' the focus just changes to the
minibuffer (no `o' char appears in the minibuffer at this point).

I can tell that the focus changes because the frame border shows that (the
active frame border is a diff color from inactive frame borders - this is a
window mgr thing, not an Emacs thing).

Then, if I hit `o' a second time it (a single `o' is inserted in the minibuffer.

Thx/HTH.

[throw-three.el (application/octet-stream, attachment)]

Message #65 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Thu, 23 Jun 2011 09:45:29 -0700

[Message part 1 (text/plain, inline)]

> I comment out the two lines
> ;; (load-file "c:/drews-lisp-20/hexrgb.el")
> ;; (load-file "c:/drews-lisp-20/fit-frame.el")
> at the beginning of the file.  I hope they are not needed.

Yes, that was an oversight.  They are not needed at all.

>  > Note: In the file, both of these two lines are necessary, 
>  > to cause the error:
>  > (add-hook 'post-command-hook '1on1-fit-minibuffer-frame)
>  > (setq w32-grab-focus-on-raise    nil)
> 
> Both are in here.

Yes, they are needed.

> With the `post-command-hook' active, focus remains always within the
> Minibuffer frame at the bottom of my screen, whatever silly I 
> type.  The Completions frame is never selected.  So lets hope
> this got fixed.
> 
> I attach a copy of window.el as usual.  If you think that 
> hexrgb and/or fit-frame are needed for showing the bug,
> please tell me so.

(No, those files are not needed.  You can remove those two lines.)

Testing with the latest window.el you just sent, here are the results:


THE GOOD NEWS:

With the last setup we both tried, no bug!  That is: 
runemacs.exe -Q --debug-init -l "window-2011-06-23a-MARTIN.el" -l
"throw-three.el" -f "1on1-emacs"


THE BAD NEWS:

So I pared down again.  The bug happens if you make just this change in the
definition of `1on1-emacs':

Change these lines:

(if 1on1-minibuffer-frame
    (modify-frame-parameters
      1on1-minibuffer-frame
      1on1-minibuffer-frame-alist)
 (setq 1on1-minibuffer-frame
       (make-frame 1on1-minibuffer-frame-alist)))

To these, which is really what I use:

(if 1on1-minibuffer-frame
    (modify-frame-parameters
      1on1-minibuffer-frame
      1on1-minibuffer-frame-alist)
  (setq 1on1-minibuffer-frame
        (let ((after-make-frame-functions  nil))
          (make-frame 1on1-minibuffer-frame-alist))))

IOW, the difference is that `after-make-frame-functions' is bound to nil when
`make-frame' is called.  I do that to inhibit my `fit-frame' from doing
anything.  I have `fit-frame' on `after-make-frame-functions'.

I attached the file - just do as before, using this instead of throw-three.el.

I can try removing just `fit-frame' from that hook and then restoring it.  But I
think I shouldn't have to.  I think that correct behavior should not depend on
`after-make-frame-functions'.  Don't you agree?

Can you please take a look and see why and whether it is necessary that a user
_not_ bind `after-make-frame-functions' to nil here?

Why should `after-make-frame-functions' have any effect on whether keyboard
input for *Completions* gets properly redirected to the minibuffer frame?  You
don't use `after-make-frame-functions' in your code, do you?

If so, that I think is probably a bad idea.  Such hooks should be only for
additional, user etc. things, not for necessary code for vanilla Emacs to work
normally.

Anyway, please let me know what you think.  Give it a try with that `let'
binding (just use the attached file), to confirm that you at least see the same
problem as I.  We can then worry about what to do to fix or work around the
problem.

Again, the problem happens only when the *Completions* is first created.  What
happens on MS Windows is that whenever a frame is created it gets selected (by
the OS/window mgr - there is no way around this).

And for some reason, I guess because of emptying `after-make-frame-functions',
that Windows-frame-selection-on-creation is now also selecting the
window/buffer, and in such a way that keyboard input is not being correctly
redirected to the minibuffer frame.

And as before (since you made some changes a few days ago), things do work
correctly once the *Completions* frame has been created.  If that frame is
already showing and I repeat the recipe (M-x etc.) there is no problem.

And that is true regardless of which frame is selected when I start with M-x:
the *scratch* frame, the minibuffer frame, or even the *Completions* frame.
When I hit M-x, the input is always correctly redirected to the minibuffer
frame, so there is no error saying that *Completions* is read-only.  (Again,
this is when *Completions* was already showing.)

I think (and hope) we are almost there.  Something seems to be preventing the
input-focus redirection just after the *Completions* frame is created, when
`after-make-frame-functions' is nil.

Thx - Drew

[throw-fit-1.el (application/octet-stream, attachment)]

Message #68 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Thu, 23 Jun 2011 15:06:51 -0700

Martin,

Please disregard my previous message from today completely.  Dunno what I was
seeing or thought I was seeing.  Sorry for wasting your time (and mine) with
that.

I checked again, and the same test as before, with throw-three.el, does NOT
work, i.e., the bug is still manifested.  I tested again with both the window.el
you sent yesterday and with the latest window.el you sent.  Both have the same
problem.

runemacs.exe -Q --debug-init -l "window-2011-06-21a-MARTIN.el" -l
"throw-three.el" -f "1on1-emacs"

runemacs.exe -Q --debug-init -l "window-2011-06-23a-MARTIN.el" -l
"throw-three.el" -f "1on1-emacs"

Same recipe: M-x f TAB o

When I hit the second char (`o') I get the read-only error for *Completions*.

--

(FWIW, I also checked `after-make-frame-functions' and it was anyway nil in the
tests I mentioned earlier, even without the `let' binding.  All of that was just
a wild goose chase.)

Message #71 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Fri, 24 Jun 2011 10:53:21 +0200

> I checked again, and the same test as before, with throw-three.el, does NOT
> work, i.e., the bug is still manifested.  I tested again with both the window.el
> you sent yesterday and with the latest window.el you sent.  Both have the same
> problem.
>
> runemacs.exe -Q --debug-init -l "window-2011-06-21a-MARTIN.el" -l
> "throw-three.el" -f "1on1-emacs"
>
> runemacs.exe -Q --debug-init -l "window-2011-06-23a-MARTIN.el" -l
> "throw-three.el" -f "1on1-emacs"
>
> Same recipe: M-x f TAB o
>
> When I hit the second char (`o') I get the read-only error for *Completions*.

Note that apart from the

(load-file "c:/drews-lisp-20/hexrgb.el")
(load-file "c:/drews-lisp-20/fit-frame.el")

the throw-three.el you sent me contains

(load-file "c:/drews-lisp-20/window-2011-06-21a-MARTIN.el")

which contains the old definitions which don't work in your case.  I
removed all three lines in my version.


Apart from that I can see the following:

If I do -f "1on1-emacs" from the command line I see the "bad" behavior.
But I see the same behavior if I do -f "1on1-emacs" with an old Emacs
that does NOT contain my changes.  In both cases the *Completions* frame
is selected.  So please verify that this invocation DTRT with an old
Emacs of yours.

If I omit -f "1on1-emacs" from the command line and evaluate the
expression (1on1-emacs) after my initial frame appeared I don't see the
bad behavior.

Please clarify these issues.

Thanks, martin.

Message #74 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Fri, 24 Jun 2011 14:21:31 -0700

[Message part 1 (text/plain, inline)]

Martin,

OK, I believe I've located the problem.  Sorry for all of the confusion.

However, this is not necessarily simple, and you will need to load more in order
to see it.  I spent a lot of time on this today, but I cannot easily simplify
things more.  I think you will need to look at it first, and then we'll see what
we can do together to focus in more on the problem.

But I suspect that just by looking at the problematic part of the code you will
be able to offer a suggestion that will fix things.  Hope so.  I call
`display-buffer' with the old calling sequence, and that, I imagine, is the
problem.  With a little luck you will be able to let me know what the correction
should be, and that will take care of things.

You might be able to do that without bothering to test at all - see the end of
this message.  But I suspect it might help you to see what happens, even so.

I have tested this with Emacs 23.3 and with your latest window.el (Emacs 24
build from 6/20).  Here is the startup.  File throw-10.el is attached.  It loads
Icicles.

runemacs.exe -Q --debug-init  -l "window-2011-06-23a-MARTIN.el" -l "throw-10.el"
-f "1on1-emacs"

(For Emacs 23, the startup is the same, but without the -l of your window.el
file.)

Once Emacs is started, you can test as before: `M-x f TAB o'.

But to see the problem you need to be in Icicle mode, so do this first: `M-x
icy-mode' (toggles the mode).  You can thus test with and without Icicle mode to
see the difference.  With Emacs 23, both in and out of Icicle mode work.  With
your code it works only when not in Icicle mode.

--

You will need to download all of the Icicles source files for the test.  The
attached file, throw-10.el, loads them all, but it also then simplifies the part
of the code that I think is leading to the problem.  So the code you actually
need to look at is, I think, quite focused.

These are the Icicles files, and the place to get them:
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24

icicles-mac.el
icicles-face.el
icicles-opt.el
icicles-var.el
icicles-fn.el
icicles-mcmd.el
icicles-cmd1.el
icicles-cmd2.el
icicles-mode.el
icicles.el

The code to focus on is, I believe, in test-10.el, function
`icicle-display-candidates-in-Completions'.  (This function is called a lot, in
many Icicles contexts.)

This is the part of the code that I think is problematic - marked with a
`@@@@@@@' comment:

(let ((comp-buf  (get-buffer-create "*Completions*")))
  (unless (get-buffer-window comp-buf 'visible)
    (save-selected-window
      (display-buffer comp-buf t 0) ; <== the problem, no doubt
      (deactivate-mark))))

This calls `display-buffer', but it uses the old calling sequence, which I'm
guessing is the problem.  The point of this code is just to visit display the
buffer and deactivate the mark there.

Again, sorry for the amount of work.  Hoping this will help.

Thx - Drew

[throw-10.el (application/octet-stream, attachment)]

Message #77 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sat, 25 Jun 2011 16:15:23 +0200

> These are the Icicles files, and the place to get them:
> http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
> 3F%24
>
> icicles-mac.el
> icicles-face.el
> icicles-opt.el
> icicles-var.el
> icicles-fn.el
> icicles-mcmd.el
> icicles-cmd1.el
> icicles-cmd2.el
> icicles-mode.el
> icicles.el

It's a pain to get ten files from there one by one.  Can't you pack them
and send them in an attachment together with the throw-... file?  I
suppose you have them in one and the same directory and a thing like
7-zip around.  So this should be much easier for you ...

> (let ((comp-buf  (get-buffer-create "*Completions*")))
>   (unless (get-buffer-window comp-buf 'visible)
>     (save-selected-window
>       (display-buffer comp-buf t 0) ; <== the problem, no doubt
>       (deactivate-mark))))

Could you explain what you think that happens, happens instead, or does
not happen here?  "0" won't do anything `display-buffer' without that
argument would not have done anyway: Search all visible and iconified
frames for a window showing comp-buf.  Maybe there are reasons why this
argument is needed and I should put back its semantics but I never found
one and don't find one here.

IIUC the code tests whether it finds a visible window showing comp-buf.
If it doesn't, either because the window doesn't exist or is not
visible, it tries to get one on an iconified frame or make a new frame
and deactivate the mark there.  So you probably raise the frame of
com-buf and then want to redirect focus from the comp-buf window to your
minibuffer window which probably was selected here, and finally you
reselect the minibuffer window because of the `save-selected-window'.
But for some reason the comp-buf window remains selected.  Is it that
what you see?

Note: In all examples you sent me before you didn't have a thing like
`save-selected-window' around a `display-buffer' call.

martin

Message #80 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sat, 25 Jun 2011 07:52:01 -0700

> It's a pain to get ten files from there one by one.  Can't 
> you pack them and send them in an attachment together with
> the throw-... file?  I suppose you have them in one and the
> same directory and a thing like 7-zip around.  So this
> should be much easier for you ...

There are several bulk download methods for Icicles, if you feel that
right-clicking 10 times is onerous:

http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries#toc5

Try one of the 3 download scripts (see the first two bullets).  If you don't
like any of the bulk download methods then I will send a 7zip archive to you by
mail - let me know.
 
>  > (let ((comp-buf  (get-buffer-create "*Completions*")))
>  >   (unless (get-buffer-window comp-buf 'visible)
>  >     (save-selected-window
>  >       (display-buffer comp-buf t 0) ; <== the problem, no doubt
>  >       (deactivate-mark))))
> 
> Could you explain what you think that happens, happens 
> instead, or does not happen here?  "0" won't do anything
> `display-buffer' without that argument would not have done
> anyway: Search all visible and iconified frames for a window
> showing comp-buf.

(Again, to be sure we're on the same page, this is a call to `display-buffer'
for Emacs prior to your changes.  Perhaps I need to modify it now, for Emacs
24+.)

The code above is Icicles code.  Icicles does not require users to use non-nil
`pop-up-frames' (and most do not probably).  In my own, personal setup I use
non-nil `pop-up-frames', but this code needs to work with any value of that
option.

You are the expert on `display-buffer', but this is my understanding.  From the
`display-buffer' doc string:

Emacs 20:

 If FRAME is 0, search all visible and iconified frames.
 If FRAME is nil, search only the selected frame
  (actually the last nonminibuffer frame),
  unless `pop-up-frames' is non-nil,
  which means search visible and iconified frames.

Emacs 22 says the same, but it adds "or `display-buffer-reuse-frames'" to
`pop-up-frames'.

Emacs 23 and Emacs 24 before your changes say the same as Emacs 22, but they
distinguish the `graphic-only' case of non-nil for pop-up-frames.

The Elisp manual says essentially the same thing.  The Emacs 23.3 manual says
only this about a nil value for FRAME (but it then lists a long page of other
options that also affect the behavior of `display-buffer').

 `nil' means consider windows on the selected frame.
 (Actually, the last non-minibuffer frame.)

IIUC, in the above code, I do not want nil for FRAME, because I do not want only
the selected frame checked for a *Completions* window.

> Maybe there are reasons why this argument is needed and I
> should put back its semantics but I never found one and
> don't find one here.

Do you see one now?  Am I missing something?

> IIUC the code tests whether it finds a visible window showing 
> comp-buf.  If it doesn't, either because the window doesn't
> exist or is not visible, it tries to get one on an iconified
> frame or make a new frame

New window, not new frame - no?

Unless `pop-up-frames is non-nil etc.  Again, please keep in mind that this is
general code for users with all possible values of `pop-up-frames' etc.

> and deactivate the mark there.  So you probably raise the frame of
> com-buf and then want to redirect focus from the comp-buf 
> window to your
> minibuffer window which probably was selected here, and finally you
> reselect the minibuffer window because of the `save-selected-window'.
> But for some reason the comp-buf window remains selected.  Is it that
> what you see?

I guess so.  I don't know about the explanation of why, but yes, as I described
earlier, for some reason the new *Completions* frame is getting the input
(keyboard) focus.  It is supposed to be a frame that always has its keyboard
input redirected to the minibuffer frame.

I suspect it's better to concentrate on the problem of input focus rather than
speaking only in terms of window/frame selection.  The new *Completions* frame
_appears_ selected even prior to your changes (as shown by the window mgr border
color, for instance), but the input focus is always correctly redirected to the
minibuffer frame.

That is the change (problem): the keyboard input focus.  It seems (symptom, not
explanation) as if the frame is no longer being correctly redirected, in terms
of input focus.

> Note: In all examples you sent me before you didn't have a thing like
> `save-selected-window' around a `display-buffer' call.

Not sure what you're saying there.  Is that not a good idea?

Thx - Drew

Message #83 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sat, 25 Jun 2011 08:04:34 -0700

To clarify some of what I said last -

> for some reason the new *Completions* frame is getting
> the input (keyboard) focus.  It is supposed to be a
> frame that always has its keyboard input redirected to
> the minibuffer frame.
>
> I suspect it's better to concentrate on the problem of input 
> focus rather than speaking only in terms of window/frame
> selection.

Re-reading that, it sounds a bit misleading ("always").  It is of course also
about which window/frame is selected (and a user can in fact change the input
focus to *Completions*, via a minibuffer keymap key).

I just meant that in this situation *Completions* should have the focus, and it
does not.

> The new *Completions* frame _appears_ selected even prior
> to your changes (as shown by the window mgr border
> color, for instance), but the input focus is always correctly 
> redirected to the minibuffer frame.

That was all I was trying to say above wrt "selection".  What counts here is
that *Completions* is getting the input focus and it should not be getting it.

Message #86 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sat, 25 Jun 2011 17:57:34 +0200

> That was all I was trying to say above wrt "selection".  What counts here is
> that *Completions* is getting the input focus and it should not be getting it.

I downloaded your Icicles tarball and tried with throw-10.  Everything
seems to work as expected including focus redirection and resurrection
of an iconified Completions frame.  So if you don't use any additional
strings the problem seems fixed.

I can't tell why it doesn't work on your machine.  Maybe some .el files
have to be recompiled in order to work with my later fixes so it's
likely best to wait till Sean uploads the new binaries (IIRC this
happens every Monday).  As soon as you tried with the new binaries tell
me what you get.

martin

Message #89 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sat, 25 Jun 2011 09:15:25 -0700

> I downloaded your Icicles tarball and tried with throw-10.  Everything
> seems to work as expected including focus redirection and resurrection
> of an iconified Completions frame.

There should be no iconfied Completions frame in the test I gave you.

The problem arises only when the Completions frame is newly _created_, as I
tried to explain.  If you use `M-x f TAB o' (recipe) after the frame has already
been created then the input focus is not a problem.

If you have the frame already, then please delete it and try `M-x f TAB o'
again.

> So if you don't use any additional strings the problem seems
> fixed.  I can't tell why it doesn't work on your machine.

As I said, it's possible that this is Windows-specific.  Windows is I think
(thought) a bit peculiar when it comes to its auto-selecting a new frame -  but
you said that most window mgrs do that now.  I still wonder if this isn't
Windows-specific, since you cannot reproduce it and it is systematic for me when
I follow the same recipe.

> Maybe some .el files have to be recompiled in order to work
> with my later fixes

Do you mean my .el or .el from Emacs sources?  In the files I provided for the
test, please use only .el, no .elc.

> so it's likely best to wait till Sean uploads the new binaries
> (IIRC this happens every Monday).  As soon as you tried with
> the new binaries tell me what you get.

I'll certainly do that.

But what about that `display-buffer' call in
`icicle-display-candidates-in-Completions'?  Can you suggest a change for it?
Does that code look like it _should_ work after your changes, or should it be
changed?

And you mentioned the `save-selected-window' around that `display-buffer' call.
Does that need to be changed somehow?

Message #92 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sat, 25 Jun 2011 19:00:13 +0200

>> I downloaded your Icicles tarball and tried with throw-10.  Everything
>> seems to work as expected including focus redirection and resurrection
>> of an iconified Completions frame.
>
> There should be no iconfied Completions frame in the test I gave you.

When I type foo and eventually get the sole completion footnote-mode the
Completions frame iconifies automatically.  I didn't check why that
happens, shouldn't it?  When I then type M-x f TAB again it gets orderly
resurrected.

> The problem arises only when the Completions frame is newly _created_, as I
> tried to explain.  If you use `M-x f TAB o' (recipe) after the frame has already
> been created then the input focus is not a problem.
>
> If you have the frame already,

The Completions frame?  It pops up automatically when I hit TAB and
redirects focus to the Minibuffer frame.

> then please delete it and try `M-x f TAB o'
> again.
>
>> So if you don't use any additional strings the problem seems
>> fixed.  I can't tell why it doesn't work on your machine.
>
> As I said, it's possible that this is Windows-specific.  Windows is I think
> (thought) a bit peculiar when it comes to its auto-selecting a new frame -  but
> you said that most window mgrs do that now.  I still wonder if this isn't
> Windows-specific, since you cannot reproduce it and it is systematic for me when
> I follow the same recipe.

But I test this on Windows XP.

>> Maybe some .el files have to be recompiled in order to work
>> with my later fixes
>
> Do you mean my .el or .el from Emacs sources?  In the files I provided for the
> test, please use only .el, no .elc.

From the Emacs sources.  Maybe some completions-related stuff.

>> so it's likely best to wait till Sean uploads the new binaries
>> (IIRC this happens every Monday).  As soon as you tried with
>> the new binaries tell me what you get.
>
> I'll certainly do that.

OK.

> But what about that `display-buffer' call in
> `icicle-display-candidates-in-Completions'?  Can you suggest a change for it?
> Does that code look like it _should_ work after your changes, or should it be
> changed?

It should work vacuously.  But I'd like to know why you needed it
earlier.  Earlier Emacsen had `display-buffer' do

     ((let ((frames (or frame

here frame is the value "0" you provide as argument

			(and (or use-pop-up-frames
				 display-buffer-reuse-frames
				 (not (last-nonminibuffer-frame)))
			     0)

and the "0" you see in the previous line means exactly the same.  Any
visible or iconified frame provided you use either `pop-up-frames' or
`display-buffer-reuse-frames'.  And I suppose it doesn't make sense to
use Icicles with these set to nil.  Now if you insisted on searching
only visible frames here I would see a problem ...

			(last-nonminibuffer-frame))))
	(setq window-to-use
	      (catch 'found
		;; Search frames for a window displaying BUFFER.  Return
		;; the selected window only if we are allowed to do so.
		(dolist (window (get-buffer-window-list buffer 'nomini frames))
		  (when (or can-use-selected-window
			    (not (eq (selected-window) window)))
		    (throw 'found window))))))
      ;; The buffer is already displayed in some window; use that.
      (window--display-buffer-1 window-to-use))

I can easily resurrect the old semantics of that argument for the few
values t, 0, visible and a live frame but I would first like to see a
real use case for it.

> And you mentioned the `save-selected-window' around that `display-buffer' call.
> Does that need to be changed somehow?

I'm not quite sure what you expect it to do.  IIUC you want the
Completions window selected with focus redirected to the Minibuffer
window.  Now which window is the one whose selection you want to save
here?  Anyway, it shouldn't harm so leave it alone.

martin

Message #95 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sat, 25 Jun 2011 10:48:52 -0700

>  > There should be no iconfied Completions frame in the test 
>  > I gave you.
> 
> When I type foo and eventually get the sole completion 
> footnote-mode the Completions frame iconifies automatically.
> I didn't check why that happens, shouldn't it?
> When I then type M-x f TAB again it 
> gets orderly resurrected.

Yes, that is all "normal" Emacs behavior.

But that was not the recipe.

1. I don't think you are in Icicle mode when testing.
Did you do `M-x icy-mode' at the start, to get in the mode?

I mentioned that you can try the same test (starting from Emacs startup each
time) both in and out of Icicle mode, to see the difference.  If not in Icicle
mode then you will not see the bug.

2. If you are in Icicle mode then you won't even get to `foo' after hitting `M-x
f TAB'.

After starting Emacs as I indicated and getting into Icicle mode, when you hit
`M-x f TAB' the Completions frame is created and it incorrectly gets the input
focus.  When you then hit `o' you get the read-only error.

It is important to test from scratch: no Completions frame or buffer, not even
iconified.  Then just type `M-x f TAB o'.

Note that even in Emacs 23, where there is no such bug, when you complete to
footnote-mode in Icicle mode the Completions frame is not iconified.  It is
instead deleted.

If you are seeing iconification of Completions then you are not in Icicle mode,
I think.  You can easily tell when you are in Icicle mode by looking at the mode
line - you will see `Icy' there.

FYI - The Completions frame/window removal code is in file icicles-mcmd.el,
function `icicle-remove-Completions-window', which calls
`icicle-delete-windows-on'.  In this case *Completions* is dedicated, and
`delete-frame' is called.

>  > The problem arises only when the Completions frame is 
>  > newly _created_, as I tried to explain.  If you use
>  > `M-x f TAB o' (recipe) after the frame has already
>  > been created then the input focus is not a problem.
>  >
>  > If you have the frame already,
> 
> The Completions frame?  It pops up automatically when I hit TAB and
> redirects focus to the Minibuffer frame.

Yes, it should.

>  > then please delete it and try `M-x f TAB o' again.

I was trying to direct you to follow the recipe, which starts with (a) Icicle
mode and (b) _no_ Completions frame.  Once the frame has been created you will
not see the bug.

See above for, I hope, clear instructions: Start Emacs again, get in Icicle
mode, then hit `M-x f TAB o'.  That's all there is to it.

> But I test this on Windows XP.

Ah, excellent.  I'm on XP too, so we should be able to work this out.  So far,
it seems like you did not test in Icicle mode.  Try that and see, please.

>  > But what about that `display-buffer' call in
>  > `icicle-display-candidates-in-Completions'?
> 
> It should work vacuously.  But I'd like to know why you
> needed it earlier... And I suppose it doesn't make sense to
> use Icicles with these set to nil.

Yes, it does make sense!  See my previous message.  I tried to say clearly that
Icicles has nothing to do with my personal setup where I use `pop-up-frames'
etc.  Icicles is a general package, and most of its users, I believe, do not use
non-nil `pop-up-frames' - and most certainly don't use my oneonone.el setup.

> I can easily resurrect the old semantics of that argument for the few
> values t, 0, visible and a live frame but I would first like to see a
> real use case for it.

I have a real use case for it.  See above.  My code needs to work for users who
have nil and users who have non-nil `pop-up-frames' etc.

And see what I wrote wrt the `display-buffer' doc.  For nil `pop-up-frames' etc.
an argument of 0 is not at all the same as an argument of nil, according to the
doc.  Why do you think they added the 0 value?  Why do you think it is
superfluous?  What am I missing here?

>  > And you mentioned the `save-selected-window' around that 
>  > `display-buffer' call.  Does that need to be changed somehow?
> 
> I'm not quite sure what you expect it to do.  IIUC you want the
> Completions window selected with focus redirected to the Minibuffer
> window.  Now which window is the one whose selection you want to save
> here?  Anyway, it shouldn't harm so leave it alone.

The selected window can I believe be any window, depending on the context.  It
could be the minibuffer window or another buffer window.  It could (I think,
without bothering to verify) even be the Completions window.  Thanks for
confirming that it does no harm - I will leave it.

Message #98 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sun, 26 Jun 2011 15:50:03 +0200

[Message part 1 (text/plain, inline)]

> 1. I don't think you are in Icicle mode when testing.
> Did you do `M-x icy-mode' at the start, to get in the mode?

No.

> I mentioned that you can try the same test (starting from Emacs startup each
> time) both in and out of Icicle mode, to see the difference.  If not in Icicle
> mode then you will not see the bug.
>
> 2. If you are in Icicle mode then you won't even get to `foo' after hitting `M-x
> f TAB'.
>
> After starting Emacs as I indicated and getting into Icicle mode, when you hit
> `M-x f TAB' the Completions frame is created and it incorrectly gets the input
> focus.  When you then hit `o' you get the read-only error.
>
> It is important to test from scratch: no Completions frame or buffer, not even
> iconified.  Then just type `M-x f TAB o'.

I see it now.  The Completions buffer pop ups up in a normal frame instead.

> Note that even in Emacs 23, where there is no such bug, when you complete to
> footnote-mode in Icicle mode the Completions frame is not iconified.  It is
> instead deleted.

I attached a fixed copy of window.el, please try it.  Completing now
deletes the Completions frame.  I also restored the old meaning of the
third argument of `display-buffer' for the described frame values.

martin

[window.zip (application/zip, inline)]

Message #101 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 26 Jun 2011 07:56:33 -0700

> I see it now.  The Completions buffer pop ups up in a normal 
> frame instead.  I attached a fixed copy of window.el, please try it.
> Completing now deletes the Completions frame.  I also restored the
> old meaning of the third argument of `display-buffer' for the
> described frame values.

Bravo!  And thank you.  Completions is now correctly redirected: no more
read-only error.

However, I now see this problem, which might or might not be due to this fix -
dunno.  It seems that the *Completions* window is still not a proper dedicated
window, at least some of the time (?).

`C-g' and `C-]' in Icicles during completion invoke
`icicle-abort-recursive-edit' (in file icicles-mcmd.el), which does this:

(if (not (active-minibuffer-window))
    (when (get-buffer "*Completions*")
      (kill-buffer (get-buffer "*Completions*")))
  (icicle-remove-Completions-window 'FORCE))
(abort-recursive-edit)

This should remove the *Completions* window/frame.  In the case in question, the
second branch of the `if' is taken, invoking `icicle-remove-Completions-window'
(which is also in file icicles-mcmd.el).

What is happening now is that the first `C-g' does not remove Completions (e.g.
delete the frame) - a second `C-g' is needed.

Similarly, if you do `C-x 0' in the minibuffer it should remove Completions (it
is bound to `icicle-remove-Completions-window').  That also does not work (no
matter how many times you use it in a row).

Here is what is happening, by `M-x debug-on-entry icicle-abort-recursive-edit'.

Debugger entered--returning value: nil
  window-dedicated-p(#<window 14 on *Completions*>)
* (if (window-dedicated-p (get-buffer-window "*Completions*" (quote visible)))
(progn (condition-case nil (icicle-delete-windows-on "*Completions*") (error
nil))))
* (when (window-dedicated-p (get-buffer-window "*Completions*" (quote visible)))
(condition-case nil (icicle-delete-windows-on "*Completions*") (error nil)))
* (cond ((and (get-buffer-window "*Completions*") (or force (and (window-live-p
swin) (not (eq (window-buffer swin) (get-buffer "*Completions*"))))
(interactive-p))) (condition-case nil (delete-window (get-buffer-window
"*Completions*")) (error nil)) (bury-buffer (get-buffer "*Completions*"))) ((and
(get-buffer-window "*Completions*" (quote visible)) (or force (and
(window-live-p swin) (not (eq (window-buffer swin) (get-buffer
"*Completions*")))) (interactive-p))) (when (window-dedicated-p
(get-buffer-window "*Completions*" (quote visible))) (condition-case nil
(icicle-delete-windows-on "*Completions*") (error nil))) (bury-buffer
(get-buffer "*Completions*"))))
* (let ((swin (selected-window))) (when (and (window-minibuffer-p swin) (fboundp
(quote minibuffer-selected-window))) (setq swin (minibuffer-selected-window)))
(cond ((and (get-buffer-window "*Completions*") (or force (and (window-live-p
swin) (not (eq ... ...))) (interactive-p))) (condition-case nil (delete-window
(get-buffer-window "*Completions*")) (error nil)) (bury-buffer (get-buffer
"*Completions*"))) ((and (get-buffer-window "*Completions*" (quote visible)) (or
force (and (window-live-p swin) (not (eq ... ...))) (interactive-p))) (when
(window-dedicated-p (get-buffer-window "*Completions*" (quote visible)))
(condition-case nil (icicle-delete-windows-on "*Completions*") (error nil)))
(bury-buffer (get-buffer "*Completions*")))))
* icicle-remove-Completions-window(FORCE)
* (if (not (active-minibuffer-window)) (when (get-buffer "*Completions*")
(kill-buffer (get-buffer "*Completions*"))) (icicle-remove-Completions-window
(quote FORCE)))
  icicle-abort-recursive-edit()
  call-interactively(icicle-abort-recursive-edit nil nil)

Thx - Drew

Message #104 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 26 Jun 2011 08:15:48 -0700

> What is happening now is that the first `C-g' does not remove 
> Completions (e.g. delete the frame) - a second `C-g' is needed.

And sometimes a second C-g does nothing either.
And sometimes C-g replaces buffer *Completions* in its frame with another buffer
(e.g. *scratch*), leaving the frame there.

I don't have a recipe to reproduce these latter symptoms.  But perhaps this is
all due to the window not being dedicated.

Message #107 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8856 <at> debbugs.gnu.org
Subject: Re: bug#8856: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Sun, 26 Jun 2011 17:54:34 +0200

> I don't have a recipe to reproduce these latter symptoms.  But perhaps this is
> all due to the window not being dedicated.

The window was dedicated initially but due to another `display-buffer'
call "reusing it" it became undedicated again.

Please use the `display-buffer-in-window' function below which doesn't
reset the status when the buffer remains unchanged.

martin


(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.
    (unless (eq buffer (window-buffer window))
      ;; If we show another buffer in window, undedicate it first.
      (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 (or (eq old-frame new-frame)
		(not (frame-visible-p new-frame))
		;; Assume the selected frame is already visible enough.
		(eq new-frame (selected-frame))
		;; Assume the frame from which we invoked the minibuffer
		;; is visible.
		(and (minibuffer-window-active-p (selected-window))
		     (eq new-frame
			 (window-frame (minibuffer-selected-window)))))
      (raise-frame new-frame))
    ;; Return window.
    window))

Message #110 received at 8856 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 8856 <at> debbugs.gnu.org
Subject: RE: bug#8856: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 26 Jun 2011 09:06:52 -0700

> The window was dedicated initially but due to another `display-buffer'
> call "reusing it" it became undedicated again.
> 
> Please use the `display-buffer-in-window' function below which doesn't
> reset the status when the buffer remains unchanged.

Yes, that fixes the problem.
I see no more problems for the moment.
Thanks for your help and your work in general.

Please close this bug, if you like.
I will open another if I find other problems.
Looking forward to having these fixes in the next build, hopefully.

 - Drew

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.