[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: display-buffer-alist simplifications
From: |
Drew Adams |
Subject: |
RE: display-buffer-alist simplifications |
Date: |
Fri, 5 Aug 2011 10:45:28 -0700 |
> 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.
- Re: display-buffer-alist simplifications, (continued)
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/02
- RE: display-buffer-alist simplifications, Drew Adams, 2011/08/02
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/03
- RE: display-buffer-alist simplifications, Drew Adams, 2011/08/03
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/04
- RE: display-buffer-alist simplifications, Drew Adams, 2011/08/04
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/02
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/03
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/04
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/05
- RE: display-buffer-alist simplifications,
Drew Adams <=
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/06
- RE: display-buffer-alist simplifications, Drew Adams, 2011/08/06
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/07
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/05
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/06
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/07
- Re: display-buffer-alist simplifications, Tim Cross, 2011/08/08
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/08
- RE: display-buffer-alist simplifications, Drew Adams, 2011/08/08
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/08