RE: display-buffer-alist simplifications

["Drew Adams" <drew.adams@oracle.com>]

> The absurd consequence of this is that with `pop-up-frames' non-nil
> `ctl-x-4-map' becomes identical to `ctl-x-5-map'

Not quite.  A nitpick: It's more correct to say that every buffer-display
binding in `ctl-x-4-map' uses another frame by default instead of another window
by default - like the bindings in `ctl-x-5-map' do.

In particular, it is not the case that every `C-x 5 <something>' binding
necessarily has a `C-x 4 <something>' counterpart.  Binding `C-x 5 <f7>' to
`foobar' has no effect on `C-x 4 <f7>'.

> and `find-file-other-window' an alias for `find-file-other-frame'.

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.

> You won't find any explanation of this phenomena in the doc-strings of
> `pop-up-window' and `pop-up-frame' or in the documentation.

Not sure what you mean, but this phenomenon is clearly documented, I think.

In `(elisp) Choosing Window', the doc for `pop-up-frames' says:

 This variable specifies whether `display-buffer' should make new
 frames.  If it is non-`nil', `display-buffer' looks for a window
 already displaying...  If it finds such a window...
 Otherwise it makes a new frame...

Otherwise it makes a new frame.  Pretty clear, no?

But it would also be good (er, would have been good, before the current
deprecation of `pop-up-frames') to mention this in at least some of places in
the __Emacs__ manual.  Emacs users deserve(d) to know about it.  E.g.:

1. `(emacs) Visiting', where we describe `C-x 4 f' and `C-x 5 f', and `(emacs)
Select Buffer', where we describe `C-x 4 b' and `C-x 5 b'

2. `(emacs) Creating Frames', where we discuss both `C-x 4' and `C-x 5'

3. `(emacs) Pop Up Window', where we describe `C-x 4' as a prefix that means use
another window

We should in fact (even for Emacs 24) mention also in #3 that `C-x 5' is
analogous to `C-x 4' for another frame, and that `pop-up-frames' (or its new
equivalent) causes `C-x 4' to use another frame, like `C-x 5'.


You say that this is a feature not commonly used.  I think you're probably right
about that.  I can think of two reasons, besides a user preference that is based
on adequate knowledge:

1. Insufficient doc.  See above.  While I think the doc of `pop-up-frames' is
unambiguous, I agree that we could have advertised this feature better.  There
is _nothing_ about it in the Emacs manual, yet we bother to document
`ns-pop-up-frames' there!  This is (was) a big oversight, IMO.

2. Emacs gotchas, hurdles, and just plain bad behavior wrt frames (as opposed to
windows).  A user who tries non-nil `pop-up-frames' either abandons it quickly
when s?he encounters such obstacles, or s?he (uncommonly) digs in and tries to
tweak the code to somehow tame the behavior.  IOW, `Emacs Behaving Badly'.

Note that #2 has nothing to do with `pop-up-frames'; it is not the fault of that
option.  It is simply that the Emacs UI has never been made to work well with
frames.  IMHO.

And it's a vicious circle: because Emacs doesn't play well with frames, few
users bother to use frames (e.g. non-nil `pop-up-frames'), testing of features
wrt frames gets neglected, few improvements get made,... and 'round and 'round
we go.

You are, I would guess, the person the most knowledgable about Emacs windows and
`display-buffer' at this point, yet you yourself have been pretty virgin (I
gather) wrt using Emacs with frames.  C'est normal.

>  >> You don't know what `special-display-buffer-names' does 
>  >> unless you read the code of that function.
>  >
>  > I don't know what makes you think so.
> 
> The two weeks I spent with Drew trying to understand it.

I'm not sure what you're referring to.  If I recall (I might have forgotten),
you were at first unaware of the possibility of using FUNCTION, which is my use
case.  But that's all I remember in terms of any difficulty in understanding.
And that is in the doc string - no need to consult the code.

The doc of `special-display-buffer-names' has always seemed pretty clear to me.
I'm sure that you see and understand more cases than I do, which is perhaps
where the complexity comes in, but it didn't take me long to understand how to
use `special-display-buffer-names' for my use case (FUNCTION), and I never had
to look at its code for that - the doc sufficed.

IOW, the doc suffices for understanding the FUNCTION use case.  Perhaps the doc
does not suffice for understanding `special-display-buffer-names' completely.  I
can't speak to that.  But for Drew's use case, which is what you reference
above, I think the doc suffices and it doesn't take two weeks to understand.

I get the impression that you are pointing to my use of these things as somehow
inherently complex.  I think rather it is only that my use case (i.e., FUNCTION)
was unknown to you at first, and it is no doubt not a common use case.  But an
uncommon use case does not mean a complex use case.