RE: display-buffer-alist simplifications

[Drew Adams]

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

>  I can see two types of users:
> 
> - Those who don't work with multiple frames never use C-x 5 and don't
>    use `find-file-other-frame'.

Why?  Unless by "don't work with multiple frames" you mean _never_ use more than
one frame.  If you don't really mean that, then I don't see why a user who
generally prefers other-window would not occasionally want other-frame.

I don't understand your reasoning here.  C-x 5 has been there since Emacs
supported frames (AFAIK).  What makes you think no one uses it?  I'm surprised
that you don't use it yourself occasionally.  Don't you ever use `C-x 5 2'?

> Now maybe there are users out there who usually work in a single frame
> and occasionally want to show a file in another frame via C-x 5 f.

I would expect that to be most users.  Maybe 95%.  No, I have no reason to back
that up - just a guess.

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

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?

>  >> 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.
>  >
>  > 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?
> 
> No.  Because when I type C-x 4 f, I might not have the slightest idea
> that `find-file-other-window' ends up calling `display-buffer' and
> `pop-up-frames' will affect the placement of the window.

All you're saying there is that it is not obvious which commands use
`display-buffer'.  The point is that the `pop-up-frames' doc is clear about what
it does.  It does not list every command that is affected (i.e. those that call
`display-buffer'), that's all.

> But do we really need two different keymaps [`C-x 4' and `C-x 5']?
> If the intention was to confuse users sure, but ...

As a user of non-nil `pop-up-frames', I would not care, personally.

But I would be surprised if many (some?) people who use nil `pop-up-frames' do
not occasionally use `C-x 5'.  Very surprised.  Most people use nil, and `C-x 5'
has been there since the beginning of Emacs frame support.  What makes you think
`C-x 5' is an unused feature?

(BTW, even I use `C-x 5 2', since there is no `C-x 4 2'.)

A priori (but I'd have to think more about it, or hear more discussion), I
disagree with Stefan's proposal to just "have C-x 4 and C-x 5 as prefix commands
that modify the way the subsequent command works".  The ability to bind keys
separately in these two maps is, I think, useful.  (Not that I actually take
advantage of it... ;-) )

I don't see why we shouldn't have two different keymaps here.  What's the harm?
It's been that way for a very long time, and (as Eli likes to say) no one has
complained about it.  And I don't see the user confusion that you claim here.
Especially if, as you think, no one who has nil `pop-up-frames' ever uses `C-x
5'!  Where's the problem (for users)?

>  > 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,
> 
> What's needed?

Hm.  I cited specific sections of the manual and said what could be added (see
"See above", above).  What didn't you get?

We should "mention...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'."  That's missing (the latter part), AFAICT.

> All you say is true.  But to implement frames well you have 
> to interact with window managers and if you follow Jan's
> conversations with various users you will see that this is a
> bottomless endeavour.

Dunno what conversations you're referring to, but sure, when dealing with frames
people might run into some different behavior on different platforms.  That's
already the case.  Emacs does the best it can, and a pretty good job AFAIK.  I
don't think the problems I referred lie there.

I know, for example, that my own code that deals with frames is used on multiple
platforms.  I get input from Mac users, for instance, input that I've used to
make my frame-fitting code take into account certain Mac-specific things.
AFAIK, that code is used in Aquamacs, though I've never tried the code on Mac
myself.  The point is that most Emacs frame stuff does, I think, work across
platforms.

For the most part, it is within Emacs itself that frames are not handled well.
It's not generally a platform problem, I think, but a problem of lack of
attention by Emacs Dev to making interaction with frames work.

Do you remember my saying that as far as I recall I used Epoch seamlessly wrt a
standalone minibuffer frame, etc.?  I admit that I don't remember it well -
perhaps someone else does, but my recollection is that it just worked, out of
the box, with a standalone minibuffer frame.

Granted, I was using UNIX at the time, and maybe it didn't work on other
platforms.  Dunno.  But my point is that because Epoch was intended to use a
standalone minibuffer frame as its normal (usual, default) case, the developers
made it work.

If Emacs Dev made `pop-up-frames' non-nil by default, or (better experiment)
just hard-coded the behavior to non-nil, not allowing anyone to change it, Emacs
Dev would soon see the various problems, and they would no doubt soon be
corrected.  IIRC, Epoch was minibuffer frame-oriented from the get-go, so what
you got out of the box was something that worked.

Disclaimer: I might be misremembering Epoch (hell, it was 20 years ago).
Googling a bit gives me the impression that my recollection is correct, but I'm
ready to be corrected.  I see this, for example:

"Epoch supports two different kinds of minibuffers. The default is a non-local
minibuffer, which is displayed in its own distinct screen; this is what Epoch
has traditionally done. The alternative is to have minibuffer windows local to
each edit screen; this is similar to traditional GNU Emacs. In the case of
non-local minibuffers, there will always be exactly one minibuffer screen, and
one or more edit screens; a single edit screen and minibuffer screen together
act similarly to normal GNU Emacs. For local minibuffers, the real minibuffer
will be located at the bottom of the current edit screen."

http://www.cs.utah.edu/dept/old/texinfo/epoch/epoch.html

I don't claim (don't remember at all) that Epoch acted _in general_ the same as
non-nil `pop-up-frames'.  It is particularly the standalone minibuffer that I
remember.

And trying to have a standalone minibuffer frame is a major nose bleed for GNU
Emacs users who try it.  If Emacs Dev used one themselves, then the
*Completions* redirection stuff etc. would be taken care of once and for all,
I'm convinced.  It's pretty clear that Emacs developers have hardly tried using
a standalone minibuffer themselves, or if they have they gave up soon.

Stefan is an exception, I guess, but any taming of the problems that he might
have done in his own setup apparently hasn't yet made it into Emacs itself.
It's still not trivial for a user to have a standalone minibuffer frame (which
works).

And I am not convinced that this kind of thing has much, if anything, to do with
multiple platforms.  I use my own code on Windows and GNU/Linux (yes, sometimes,
but Emacs 21 unfortunately) - no big deal.

> your use case is the only one that disregards all other
> features: It either produces a window or it fails.
> Disregarding the murked translation of the call within 
> `special-display-popup-frame' it is also the only change to
> the special-display stuff I consider reasonable and that's
> why I tried to 1-to-1 mirror it via the `function'
> specifier of `display-buffer-alist'.

And I thank you for that!

> It is "complex" because it is one of the few uses case I'm aware of
> where something special like a function is needed.  You can't do what
> you want by using the other buffer display options of Emacs 23 alone.

I see.

> But let's agree on one thing: There are few users who want to 
> _and_ know how to use this feature.

Probably so.

Thanks again for your work on this, and thanks to others for the discussion.
Let's continue to take the time to get it right.  Again, I would like to see us
_first_ (a) be able to handle all of the various cases correctly, and only
_secondarily_ (b) simplify the way users (including programmers) do things, if
possible.  I don't want to see use cases thrown out of the window just because
we think maybe no one uses them.  Imagine if that were your use case that
someone just tossed willy nilly. ;-)

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.

Richard's argument in favor of keeping dynamic scoping was valid then and is
valid now.  That argument is no doubt not original with him alone, but it is
well presented by him wrt the context (design, use) of Emacs.

http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 (which I'm sure
everyone is familiar with, but which is always worth citing, just in case)

That said, I fully recognize the value of lexical scoping as well.  I support
Emacs moving toward a Common-Lisp type of design: special (dynamic) variables,
lexical scoping by default, etc.

What I do not think would be appropriate would be making it harder for users and
user code to do something like make Emacs more frames-oriented at the drop of a
hat.  `pop-up-frames' is simple and powerful.  I'm hoping that whatever replaces
it will be simple and powerful also.

IIUC, Martin (and others discussing this) are, in a way, attempting (perhaps not
as the main goal, but as a side effect?) to provide, for buffer/window display,
something analogous to custom/color themes for appearance.  That I support.

I cannot get all that I want in terms of appearance using a theme (separate
minibuffer frame appearance etc.), however, and luckily I can use Emacs-Lisp
code to do what I really want in this regard.  I hope the same will be true for
buffer/window display: "themes" (specifier alist, whatever) for users to specify
most common behavior choices, but ways to do more and better, if you want to,
using code.