Re: display-buffer-alist simplifications

[martin rudalics]

>>  > Yes.  And this is a feature, not just an absurd consequence.
>>  >
>>  > Just changing the value of option `pop-up-frames' makes
>>  > Emacs magically use another frame by default wherever it
>>  > would normally use another window by default.  Pretty good
>>  > stuff, IMHO.
>>
>> Pretty heavy stuff, IMHO.
>
> Dunno what that means.  But the ability to make Emacs use other-frame rather
> than other-window by default, just by toggling a variable value, is a definite
> plus, and in the spirit of both Emacs and Lisp.

Toggling the variable value changes the semantics of the command
`foo-other-window' to that of `foo-other-frame' iff the
`foo-other-window' command invokes `display-buffer'.  If it doesn't, it
might do anything it wants.  The semantics of "-other-window" is nowhere
defined within Emacs.  `org-switch-to-buffer-other-window', for example,
specially binds `pop-up-frames' to nil in order to achieve its "other
window" behavior.

And the definite plus is a definite minus for those who document the
behavior.  Take these (obviously wrong) excerpts from the Emacs manual:

  20.4 Displaying in Another Window
  =================================

  `C-x 4' is a prefix key for commands that select another window
  (splitting the window if there is only one) and select a buffer in that
  window.  Different `C-x 4' commands have different ways of finding the
  buffer to select.

or

     `C-x 4 f' (`find-file-other-window') is like `C-x C-f' except that
  the buffer containing the specified file is selected in another window.
  The window that was selected before `C-x 4 f' continues to show the
  same buffer it was already showing.  If this command is used when only
  one window is being displayed, that window is split in two, with one
  window showing the same buffer as before, and the other one showing the
  newly requested file.

>> Then we could easily imagine users who usually work with multiple
>> frames and occasionally want to pop up a window to show a file in
>> the same frame.  But C-x 4 f doesn't work for them in this case.
>> That's what I consider absurd.
>
> Correct.  That reasoning I understand.
>
> All I can say is that in practice, and speaking for myself, I don't miss it.
> Whenever I want a new window in the same frame I use C-x 2 etc.

Adopting your reasoning we could simply bind C-x 5 to `make-frame' and
do away with the entire C-x 5 map and the associated descriptions.

> (But I will add
> that there are still some hard-coded Emacs pop-up windows that do not pop up 
as
> a separate frame, even when `pop-up-frames' is non-nil.)

Are you sure it's not rebound by the application in these cases?

> But I probably would not oppose making this reciprocal: When `pop-up-frames' 
is
> non-nil, then `C-x 5' would use other-window instead of other-frame.  My guess
> is that this has never come up because no one who uses non-nil `pop-up-frames'
> (and we are probably few) really misses it.  But why not?

;-)

> And if possible, in the end I would like to see something very simple like
> `pop-up-frames' that lets a user simply convert Emacs magically to using 
frames
> by default - as before.  That simplicity for a user is a real plus.  If we 
have
> to sacrifice that simplicity, it will be too bad.
>
> And personally, FWIW, I am in _favor_ of being able to dynamically let-bind
> (some) variables to change behavior at a distance.  That is useful for users 
of
> all kinds, at all levels.  Having to fiddle with things inside the details of
> function bodies - changing args in calling sequences etc. is not what Emacs 
(and
> Lisp, in general) is about.

We can leave in any magic people are used to.  But then you won't find
anyone who implements things like showing the ispell buffer in a
separate frame or removing the frame showing dired's marked files when
it's no more needed.  Which means that the current `split-window' or
`save-window-excursion' based code is effectively carved in stone.

martin