GNU bug report logs - #8851
24.0.50; regression: special-display-frame is no longer dedicated

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 8851 in the body.
You can then email your comments to 8851 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-frame is no longer dedicated
Date: Mon, 13 Jun 2011 09:08:05 -0700

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'
 

Message #8 received at 8851 <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
Subject: Re: bug#8851: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Mon, 13 Jun 2011 20:00:04 +0200

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

Message #11 received at 8851 <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
Subject: RE: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Mon, 13 Jun 2011 11:41:17 -0700

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

Message #14 received at 8851 <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
Subject: Re: bug#8851: 24.0.50; regression: special-display-frame is no longer
	dedicated
Date: Tue, 14 Jun 2011 11:15:13 +0200

> 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

Message #17 received at 8851 <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
Subject: RE: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Tue, 14 Jun 2011 13:36:45 -0700

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

Message #20 received at 8851 <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 #23 received at 8851 <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 #26 received at 8851 <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
Subject: RE: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Fri, 17 Jun 2011 10:48:51 -0700

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

I gave you this info in the initial bug report.  Here it is again:

> 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:
> ("[ ]?[*][^*]+[*]")
>
>  > Here is a recipe (you just need to download the same 2 
>  > files as for the recipe for bug #8856).
>
> I need a simple recipe from emacs -Q.

I gave you one.  Here it is again:

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.
> visit a file foo.el, then use `C-x 5 0' to remove its frame.

It doesn't matter what file you use here, as long as its buffer name doesn't
match `special-display-regexps'.

4.
> hit C-x C-b and get the buffer menu in a new, special-display frame.

This part is now broken also, using the window.el you sent me: the frame is not
a special-display frame anymore.

(See oneonone.el for the definition of `special-display-frame-alist' etc.)

5.
> click mouse-2 on the foo.el line to visit that file.

foo.el is displayed in the same frame and window as *Buffer List* was displayed.
That's the bug.  But now the behavior is mixed up with the new bug of not even
showing *Buffer List* in a special-display frame.

> What I need are your settings wrt special-display-... and
> the buffer in question.  Why can't you post these?

There is no particular buffer in question (do you mean foo.el?), and you have
the `special-display-regexps' setting.  Please just follow the recipe.

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 #29 received at 8851 <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
Subject: RE: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 19 Jun 2011 10:29:11 -0700

With the second new `window.el' version that you sent today, this bug appears to
be fixed.  (Bug #8856 is not yet fixed, however.)  Thx.

Message #34 received at 8851-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 8851-done <at> debbugs.gnu.org
Subject: Re: bug#8851: 24.0.50;
	regression: special-display-frame is no longer dedicated
Date: Sun, 19 Jun 2011 23:04:21 -0400

> With the second new `window.el' version that you sent today, this bug
> appears to be fixed.  (Bug #8856 is not yet fixed, however.)  Thx.

Good, thanks,


        Stefan

Previous Next

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