bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

emacs -Q
 
1. Download hexrgb.el and oneonone.el:
 
http://www.emacswiki.org/emacs/download/hexrgb.el
http://www.emacswiki.org/emacs/download/oneonone.el
 
2.runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
 
3. (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
 
4. C-h i
 
5. C-x C-f some-file-somewhere.el
 
You get the error "Cannot swith buffers in a dedicated window".
 
What should happen is that the file is visited in a separate (normal)
frame.  That is what happens in Emacs 23 (and 22...20).
 
[In releases prior to Emacs 24 you also need to do this, so that *info*
is shown in a special-display frame.  This is no longer needed or
helpful in Emacs 24.
(remove-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
]
 
In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-21 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'
 

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[martin rudalics]

 > 3. (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
 >
 > 4. C-h i
 >
 > 5. C-x C-f some-file-somewhere.el
 >
 > You get the error "Cannot swith buffers in a dedicated window".

`find-file' shouldn't call `switch-to-buffer' with FORCE-SAME-WINDOW
non-nil.

martin

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> `find-file' shouldn't call `switch-to-buffer' with FORCE-SAME-WINDOW
> non-nil.

Not sure what you're saying, Martin.  Are saying what the cause of the bug is?
Or are you saying that there is no bug and that I'm doing something wrong?  Or
something else?  Please elaborate/clarify a bit.

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[martin rudalics]

 > Not sure what you're saying, Martin.  Are saying what the cause of the bug is?
 > Or are you saying that there is no bug and that I'm doing something wrong?  Or
 > something else?  Please elaborate/clarify a bit.

According to the Elisp manual `find-file' does

           (switch-to-buffer (find-file-noselect filename nil nil wildcards))

which doesn't use the selected window if it's strongly dedicated to its buffer.

So we should either change the manual or revert the change

2011-11-07  Stefan Monnier  <monnier@iro.umontreal.ca>

	* files.el (find-file): Always use selected-window.

martin

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> According to the Elisp manual `find-file' ... doesn't use
> the selected window if it's strongly dedicated to its buffer.
> So we should either change the manual or revert the change

I see; thanks.  This is definitely a regression from all previous Emacs releases
I'm aware of.  A simpler recipe to reproduce it:

emacs -Q
C-x d some-dir
M-x set-variable pop-up-frames t
(set-window-dedicated-p (selected-window) t)
RET ; on some file name

In Emacs 24 you get the error "Cannot switch...".
In previous releases the chosen file is visited in another frame.

Dedicated windows should be primarily about making Emacs use a different
window/frame.  They should not just prevent showing the file altogether, by
raising an error.

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

> emacs -Q
> C-x d some-dir
> M-x set-variable pop-up-frames t
> (set-window-dedicated-p (selected-window) t)
> RET ; on some file name

> In Emacs 24 you get the error "Cannot switch...".

In Emacs-24 and Emacs-21 and Emacs-22.

> In previous releases the chosen file is visited in another frame.

You mean in Emacs-23 only.

> Dedicated windows should be primarily about making Emacs use a different
> window/frame.  They should not just prevent showing the file altogether, by
> raising an error.

If the user uses find-file rather than find-file-other-window, she
presumably knows what she's doing.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[martin rudalics]

 > If the user uses find-file rather than find-file-other-window, she
 > presumably knows what she's doing.

When using C-x C-f.  But what about the hundred or so calls of
`find-file' in current Emacs sources?

martin

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> > emacs -Q
> > C-x d some-dir
> > M-x set-variable pop-up-frames t
> > (set-window-dedicated-p (selected-window) t)
> > RET ; on some file name
> 
> > In Emacs 24 you get the error "Cannot switch...".
> 
> In Emacs-24 and Emacs-21 and Emacs-22.

No, only in Emacs 24 - but with my setup only, it seems (see below).

With the recipe above, you are right.  But with my setup, the original problem I
reported occurs only for (recent) Emacs 24.

Actually, with only the original recipe I gave, in the older releases *info* is
not even shown as a special-display buffer, and its window is not dedicated
(why?).  So in that regard, that original recipe was also not complete for older
versions.

With the original recipe, why *info* is not dedicated, in spite of the settings
(non-nil `pop-up-frames', `special-display-regexps' matching *info*, *info*
removed from `same-window-regexps'), I don't know and don't have time to check
now.

But in my setup that is what I see in all Emacs versions except 24: the file is
simply visited in a separate frame.  See below for the likely reason.

> > In previous releases the chosen file is visited in another frame.
> 
> You mean in Emacs-23 only.

No, I meant in all Emacs versions prior to 24 (with my setup).
And in 24 too, back when Martin's code was used.

> > Dedicated windows should be primarily about making Emacs 
> > use a different window/frame.  They should not just prevent
> > showing the file altogether, by raising an error.
> 
> If the user uses find-file rather than find-file-other-window, she
> presumably knows what she's doing.

That's why (one reason) the user set `pop-up-frames' to non-nil. ;-)
`find-file' in a non-dedicated window should use the same window.  In a
dedicated window it should (IMO) visit the file somewhere else (another window
or, if non-nil `pop-up-frames' then another frame).

What's the point of such an error message when Emacs could DTRT and show the
user the buffer s?he asked to see?

And as Martin pointed out, it is not only about C-x C-f, but `find-file' in
general.  More generally than that, it is about dedicated windows: trying to
reuse a dedicated window should (IMO) just cause another window to be used.

What's the point of such an error message?  I can imagine that there might be
special cases, e.g. the minibuffer, that would be problematic, but in general
the buffer should (IMO) be shown, but in another window/frame.  And I've had
exactly that behavior for decades, with no special-casing and no problems.

---

OK, I haven't looked in detail, but I did take a quick look, and it's likely
that my setup works the way it does because, for versions < 24, I redefine
`switch-to-buffer' so that if the current window is dedicated then another
window is used.  In Emacs 24 I haven't done that (didn't need to, so far).  Here
is the code:

(if (< emacs-major-version 24)

    ;; REPLACES ORIGINAL (built-in):
    ;; 1) Use `read-buffer' in interactive spec.
    ;; 2) If current window is dedicated, then use another window.
    ;;    NOTE: Emacs versions >= 19.34 signal error if dedicated window,
instead
    ;;          of using another one.  Don't know what the 19.28 version did.
    ;; 3) Resize frame to fit sole window if `autofit-frames-flag'
    ;;    (unless BUFFER is already the `current-buffer').
    (defun switch-to-buffer (buffer &optional norecord)
      "Select buffer BUFFER in current window, unless the window is dedicated.
If current window is dedicated (`window-dedicated-p'), then another window
is used.

BUFFER may be a buffer, a string (a buffer name), or nil.  If BUFFER
is a string that does not identify an existing buffer, then a new
buffer with that name is created.  If BUFFER is nil, then function
`other-buffer' is used to choose a buffer.

Optional second arg NORECORD non-nil means do not put BUFFER at the
front of the list of recently selected buffers.

The buffer switched to is returned.

*WARNING*: This is NOT the way to work on another buffer temporarily
within a Lisp program!  Use `set-buffer' instead, to avoid messing
with correspondences between windows and buffers.

Resize frame to fit sole window if `autofit-frames-flag'
\(unless BUFFER is already the `current-buffer')."
      (interactive
       (list (read-buffer "Switch to buffer: "
                          (if (fboundp 'another-buffer) ; In `misc-fns.el'.
                              (another-buffer nil t)
                            (other-buffer (current-buffer))))))
      ;; If string arg, convert to a buffer.  If nil, use `other-buffer'.
      (setq buffer  (if buffer (get-buffer-create buffer) (other-buffer)))
      (let ((orig-buf  (current-buffer)))
        (prog1 (if (window-dedicated-p (selected-window))
                   (switch-to-buffer-other-window buffer)
                 (old-switch-to-buffer buffer norecord))
          (and (one-window-p t)
               (not (eq buffer orig-buf)) ; Don't resize if same buffer.
               autofit-frames-flag
               (fit-frame)))))

  ;; REPLACES ORIGINAL (built-in):
  ;;
  ;; Resize frame to fit sole window if `autofit-frames-flag'
  ;; (unless BUFFER is already the `current-buffer').
  ;;
  (defun switch-to-buffer (buffer-or-name &optional norecord force-same-window)
    "Switch to buffer BUFFER-OR-NAME in the selected window.
Return the buffer switched to.

If called interactively, prompt for the buffer name using the
minibuffer.  The variable `confirm-nonexistent-file-or-buffer'
determines whether to request confirmation before creating a new
buffer.

BUFFER-OR-NAME may be a buffer, a string (a buffer name), or nil.
If BUFFER-OR-NAME is a string that does not identify an existing
buffer, create a buffer with that name.  If BUFFER-OR-NAME is nil,
switch to the buffer returned by `other-buffer'.

Optional argument NORECORD non-nil means do not put the buffer
specified by BUFFER-OR-NAME at the front of the buffer list and
do not make the window displaying it the most recently selected
one.

If FORCE-SAME-WINDOW is non-nil, BUFFER-OR-NAME must be displayed in
the selected window.  Signal an error if that is impossible (e.g. if
the selected window is minibuffer-only).  If nil, BUFFER-OR-NAME may
be displayed in another window."
    (interactive
     (list (read-buffer-to-switch "Switch to buffer: ") nil 'force-same-window))
    (let ((orig-buf    (current-buffer))
          (switch-buf  (old-switch-to-buffer
                        buffer-or-name norecord force-same-window)))
      (when (and (one-window-p t)
                 (not (eq switch-buf orig-buf)) ; Don't resize if same buffer.
                 autofit-frames-flag
                 (fit-frame)))
      switch-buf)))

---

For my part, I will try tweaking my setup to make it work with Emacs 24.  But
you might also want to consider doing what I do.  I think users would prefer to
have the buffer shown to them than to just see an error message about window
dedication.  I can at least testify that that behavior has been natural and
helpful to me, for decades now.

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

>> If the user uses find-file rather than find-file-other-window, she
>> presumably knows what she's doing.
> When using C-x C-f.  But what about the hundred or so calls of
> `find-file' in current Emacs sources?

I think at least 90% of them are bugs in any case (they're typically
wrapped in the infamous save-window-excursion) and making them pop up
a new frame is not significantly better than making them signal
an error.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> making them pop up a new frame is not significantly better
> than making them signal an error.

I can't speak to the bugs you're referring to, but my experience with my own
setup (see previous mail) is that I have never been surprised or had an
unfortunate experience by the buffer being shown in another window/frame
(instead of getting the Cannot switch error).

How about at least making that a user option?

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

>> You mean in Emacs-23 only.
> No, I meant in all Emacs versions prior to 24 (with my setup).
> And in 24 too, back when Martin's code was used.

I can't imagine how that could be the case: find-file has always used
switch-to-buffer and switch-to-buffer in Emacs<23 never did anything
else than use the selected window (and hence fail in minibuffer-only
frames and dedicated windows).

> What's the point of such an error message when Emacs could DTRT and
> show the user the buffer s?he asked to see?

The user decided to use RET rather than `o', so the user explicitly
indicated that she wants to display the buffer in the selected window
rather than in another window.  So it's not obvious that displaying
the buffer in another window is the right thing to do.

OTOH I do agree that find-file is not quite like switch-to-buffer, in
that the indication "use current window" is not as clear cut.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> >> You mean in Emacs-23 only.
> > No, I meant in all Emacs versions prior to 24 (with my setup).
                                                  ^^^^^^^^^^^^^^^
> > And in 24 too, back when Martin's code was used.
> 
> I can't imagine how that could be the case: find-file has always used
> switch-to-buffer and switch-to-buffer in Emacs<23 never did anything
> else than use the selected window (and hence fail in minibuffer-only
> frames and dedicated windows).

Did you actually read my mail?  Did you read the part about this being the case
for _my setup_ but not for emacs -Q?  Did you see where I show my redefinition
of `switch-to-buffer'?

That's the point of my clarification in that message: the new problem was with
my setup only, and I suspect (seems pretty clear, but untested) that it is due
to my not doing the same thing for Emacs 24 as I do for other versions.  I used
different code for 24 because, prior to some recent change in Emacs (?), Emacs
24 (unlike previous versions) DTRT _without_ my needing that tweak to
`switch-to-buffer' for dedicated windows.

> > What's the point of such an error message when Emacs could DTRT and
> > show the user the buffer s?he asked to see?
> 
> The user decided to use RET rather than `o', so the user explicitly
> indicated that she wants to display the buffer in the selected window
> rather than in another window.  So it's not obvious that displaying
> the buffer in another window is the right thing to do.

I agree that such should be a user choice - it's not obvious a priori what the
best thing to do is.

IOW, let users choose what Emacs should do when there is an attempt to show
another buffer in a dedicated window: raise an error or use another window.  To
me (from long use), the latter is a much better behavior, but I agree that users
should be able to decide.

I still ask the general question: What good is such an error?  What am I
missing?  For instance, why would you, as one user, prefer faising the error to
displaying the buffer in another window?  I know you're used to the error
behavior, but why, given the choice, would you actually prefer it?

> OTOH I do agree that find-file is not quite like switch-to-buffer, in
> that the indication "use current window" is not as clear cut.

`find-file' is just one example.  The point of my redefinition of
`switch-to-buffer' (besides fitting the frame) is to use another window when the
target window is dedicated.

To me that makes sense, and I've used it for a very long time now, with no
problems.  I will, as I said, try to adjust my code so it works for Emacs 24
too.

I haven't had a chance yet to check this and make that change, but assuming I'm
right about the cause of the problem then (a) you can close this bug (please
wait for me to confirm my supposition), but (b) please consider a user option to
let users get the behavior I expect: use another window when the target window
is dedicated.

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

>> making them pop up a new frame is not significantly better
>> than making them signal an error.
> I can't speak to the bugs you're referring to, but my experience with my own
> setup (see previous mail) is that I have never been surprised or had an
> unfortunate experience by the buffer being shown in another window/frame
> (instead of getting the Cannot switch error).

Under Windows, I'd expect those bugs to manifest themselves by having
a frame "flash" (because the find-file pops up a new frame which is
immediately destroyed by the save-window-excursion).
In other window managers, the behavior can be arbitrarily different
(e.g. it can prompt the user to place the new frame, not knowing that
it will be destroyed right away).


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

I reverted the code to a behavior closer to Emacs-23's behavior.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I reverted the code to a behavior closer to Emacs-23's behavior.

Using set-window-buffer has the disadvantage that now switch-to-buffer
can't be affected by display-buffer-alist (except for the
dedicated/minibuffer window case where pop-to-buffer is used).

Why not use pop-to-buffer-same-window there, rather than
set-window-buffer?

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[martin rudalics]

 >> When using C-x C-f.  But what about the hundred or so calls of
 >> `find-file' in current Emacs sources?
 >
 > I think at least 90% of them are bugs in any case (they're typically
 > wrapped in the infamous save-window-excursion)

After a short look at most 10% are within a `save-window-excursion'.
The rest is just "show me that file in some window".

 > and making them pop up
 > a new frame is not significantly better than making them signal
 > an error.

We needed some sort of advise what program modes should typically use in
this case.

martin

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[martin rudalics]

 > Under Windows, I'd expect those bugs to manifest themselves by having
 > a frame "flash" (because the find-file pops up a new frame which is
 > immediately destroyed by the save-window-excursion).

I'm missing you here.  Returning from `save-window-excursion' won't
destroy a frame created within its body.

 > In other window managers, the behavior can be arbitrarily different
 > (e.g. it can prompt the user to place the new frame, not knowing that
 > it will be destroyed right away).

martin

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

>> I reverted the code to a behavior closer to Emacs-23's behavior.
> Using set-window-buffer has the disadvantage that now switch-to-buffer
> can't be affected by display-buffer-alist (except for the
> dedicated/minibuffer window case where pop-to-buffer is used).
> Why not use pop-to-buffer-same-window there, rather than
> set-window-buffer?

It's a safer change.  Callers can use pop-to-buffer-same-window if they
like that better.  In the absence of display-buffer-alist there's also
a difference of behavior for softly-dedicated windows where
set-window-buffer will undedicate the window whereas
pop-to-buffer-same-window will use another window.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

>> Under Windows, I'd expect those bugs to manifest themselves by having
>> a frame "flash" (because the find-file pops up a new frame which is
>> immediately destroyed by the save-window-excursion).
> I'm missing you here.  Returning from `save-window-excursion' won't
> destroy a frame created within its body.

Indeed, it's not always going to flash, but those popped windows are
often dedicated in my case, and the buffer is temporary, so the frame
does get destroyed, but you're right: it's not destroyed by
save-window-excursion.


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Stefan Monnier]

> We needed some sort of advise what program modes should typically use in
> this case.

find-file-noselect (followed by pop-to-buffer or some relative if they
really want to display the buffer).


        Stefan

bug#10144: 24.0.91; `pop-up-frames' with dedicated windows is broken: `C-x C-f'

[Drew Adams]

> I will, as I said, try to adjust my code so it works for Emacs 24 too.
> 
> I haven't had a chance yet to check this and make that change,
> but assuming I'm right about the cause of the problem then
> (a) you can close this bug (please wait for me to confirm my
> supposition), but (b) please consider a user option to
> let users get the behavior I expect: use another window when 
> the target window is dedicated.

This is to confirm (a) - I've adjusted my code so it does the same thing for
Emacs 24 as for other releases: `switch-to-buffer-other-window' if the window is
dedicated.  I hadn't done that until now because previously Emacs 24 did not
need this tweak.  Now it needs it again.

Wrt (b), I filed a separate enhancement request, #10171.