[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications

From: martin rudalics
Subject: Re: display-buffer-alist simplifications
Date: Sat, 06 Aug 2011 15:29:04 +0200
User-agent: Thunderbird (Windows/20090302)

>> 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 
> by default - like the bindings in `ctl-x-5-map' do.

I was trying to exaggerate.

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

Pretty heavy stuff, IMHO.  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'.

- Those who do work with multiple frames set `pop-up-frames' to t and
  never use C-x 5 or `find-file-other-frame' because C-x 4 and
  `find-file-other-window' works for them as god intended.

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

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

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.

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

But do we really need two different keymaps?  If the intention was to
confuse users sure, but ...

> You say that this is a feature not commonly used.  I think you're probably 
> about that.  I can think of two reasons, besides a user preference that is 
> 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,

What's needed?

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

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.

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

I wasn't (I can easily prove that because the corresponding code was in
the trunk before your first complaint ;-)).  But I got the calling
convention wrong (and I won't comment it here because people would
immediately ban me from this list).

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

That part is in the doc-string.

> The doc of `special-display-buffer-names' has always seemed pretty clear to 
> 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.

Obviously so, because 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'.

> IOW, the doc suffices for understanding the FUNCTION use case.

It does.

> Perhaps the doc
> does not suffice for understanding `special-display-buffer-names' completely. 
> 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 
> inherently complex.  I think rather it is only that my use case (i.e., 
> 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.

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]