[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: display-buffer-alist simplifications
RE: display-buffer-alist simplifications
Wed, 3 Aug 2011 10:36:34 -0700
> > 1. `special-display-buffer-names' is _very_, very old. It
> > has been in GNU Emacs as far back as the introduction of
> > frames, I believe. Someone can check the
> > origin and the original design arguments; I'm no expert on this.
> > 2. AFAIK, from the outset it has been just as "complex" as
> > it is today - all of the possibilities have been there since
> > Day One. They were not added incrementally because someone
> > thought that it would be neat to add a bell here or a whistle
> > there. They were thought to be important by the _original
> > designers_, many, many moon ago.
> Back in the nineties the doc-string of
> `special-display-buffer-names' read as
> "*List of buffer names that should have their own
> special frames.\n\
> Displaying a buffer whose name is in this list makes a
> special frame for it\n\
> using `special-display-function'.\n\
> Instead of a buffer name, the list entries can be cons
> cells. In that\n\
> case the car should be a buffer name, and the cdr data to
> be passed as a
> second argument to `special-display-function'.\n\
> See also `special-display-regexps'.");
> The additional features inlcuding the `same-window'/`same-frame' stuff
> and the buffer specific function specification part must have been
> included somewhere around 2003 (I didn't find a useful
> ChangeLog entry). These changes introduced the bells and whistles
> I meant and do not understand.
Thanks for looking that up, and I stand corrected on my generalization.
I admitted I was no expert on the history. And I'm glad you checked it.
But AFAICT that 1990s description _does_ refer to the feature that I use, i.e.,
a cons value.
You seemed to be saying before that the complexity of the feature that I use is
one of the main difficulties, i.e., what makes things complex. You said,
"That's the kind of expressiveness Drew needs because he's got no other choice.
It's far too expressive for all other users."
But you also said that "That's the kind" here referred to "behavior for reusing
the same window, reusing some other window on the same frame, popping up a new
window, reusing a window on another frame and popping up a new frame."
That confuses me because those sound like features that I do _not_ use (AFAIK).
What I use (the only feature I use, AFAIK) is the ability to have a cons value
that includes a display function (and some frame parameters) to use for the
And that sounds like what was available in the 90s. I do not specify any
"reuse" etc. AFAIK, that is (but I don't pretend to even understand what is
involved wrt those other features, so maybe I use them somehow without knowing
The doc string you cite above is silent about the form of the cons. Did it
allow inclusion of FUNCTION? If not, then OK, the feature I use was added after
the Creation. Not clear (so far).
> > 4. Here is the _only_ use I make of it - Drew's weirdo use
> > case. I use only the form (BUFFER FUNCTION OTHER-ARGS...),...
> This means that you specifiy the function explicitly, using the
> Finally, an element of this list can be also specified as
> \(BUFFER-NAME FUNCTION OTHER-ARGS).
> bells and whistles which were not present in the original design.
1. That's not what you referred to before as the complexity. You mentioned only
"behavior for reusing the same window, reusing some other window on the same
frame, popping up a new window, reusing a window on another frame and popping up
a new frame." I do not use such features, AFAIK. I use only the cons form
2. Are you sure that the ability to specify FUNCTION in the cons was added
The doc string you quoted just says a cons, where "the car should be a buffer
name, and the cdr data to be passed as a second argument to
`special-display-function'." That does not preclude the cdr being of the form
(FUNCTION OTHER-ARGS...). It all depends what `special-display-function'
accepted as its second arg back then.
3. FWIW, I'm using Emacs 20.7 right now, in a Windows build from 2000 (long
before 2003, but admittedly after the 1990s). The doc string of
`special-display-buffer-names' specifically mentions the form (BUFFER FUNCTION
4. What's more, the doc string of `special-display-function' says this (in Emacs
"Function to call to make a new frame for a special buffer.
It is called with two arguments, the buffer and optional buffer specific
data, and should return a window displaying that buffer.
The default value makes a separate frame for the buffer,
using `special-display-frame-alist' to specify the frame parameters.
A buffer is special if its [sic] is listed in
`special-display-buffer-names' or matches a regexp in
And the default value of `special-display-function' is
`special-display-popup-frame', whose doc string says this:
"...If ARGS is a list whose car is a symbol, use (car ARGS) as a function
to do the work. Pass it BUFFER as first argument, and (cdr ARGS) as
the rest of the arguments."
5. So you might be right about the Day One definition not providing the feature
that I use (a cons with a FUNCTION), but what you've said so far does not
Anyway, the feature I use is not one of those that you said was complex and that
you said that you have trouble understanding (the "reuse" etc. stuff you cited)
- I do not use any of that (AFAIK).
And the feature I use has been around since at least 2000 and Emacs 20, whether
or not it was present at the Creation.
And as you said clearly, "That's the kind of expressiveness Drew needs because
he's got no other choice."
In particular, I need a way to redirect the *Completions* input focus to the
standalone minibuffer. The rest of what I do in my FUNCTIONs is, yes, more or
less bells and whistles, but redirecting the input is essential - a standalone
minibuffer and a pop-up *Completions* frame just don't work otherwise (AFAIK,
but we have yet to hear how Stefan handles this in his setup).
Let me be clear again that I have confidence in what you're doing, Martin. I
agree with you and others that things are currently quite complex for users, and
I'm one of those who does not yet understand how to use `display-buffer-alist'.
But I expect that with time, discussion, and experiment we can iron things out
and simplify somewhat (at least the doc, and perhaps the design/UI).
Let me be clear too that I appreciate your trying to handle the complexity, to
deal with all of the various use cases, and to maintain coherence wrt previous
I do _not_ want to see things get dumbed down just because we haven't yet found
an ideal way to present them (UI, doc). The first task should be to handle all
of the use cases. Only secondly should we try to simplify, and do so without
sacrificing use cases.
Please continue to explain patiently to us all what we don't understand, and
please continue to resist simplistic "solutions" proposed by _any_ of us who
understand this stuff less than you do. Keep up the good work, and do not hurry
or simplify prematurely or simplistically just because someone points out that
things are, so far, complex for users. There's no hurry.
- Re: display-buffer-alist simplifications, (continued)
- 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, 2011/08/05
- 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