display-buffer-alist simplifications

display-buffer-alist simplifications

[Chong Yidong]

I am concerned that `display-buffer-alist' in its current form is still
too complicated, and needs more work.  I realize this is coming a bit
late in the day, but it's important to get it right.

Here are several suggestions, and one question.

 - Instead of allowing the car of each `display-buffer-alist' element to
   be a _list_ of matchers, let it just be a matcher.  This is
   semantically cleaner, and more consistent with other facilities in
   Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
   matching conditions can just add multiple alist elements.

 - Instead of buffer matchers that are cons cells like (name . NAME),
   (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
   Strings are to be treated as regexps (if an exact match is desired,
   the caller uses regexp-quote); symbols are treated as label matchers.

 - Some of the display specifiers seem to allow contradictory meanings,
   e.g.

      (reuse-window same nil other)

   means to reuse the selected window, provided the window is not on the
   selected frame.  What does this mean?  And what happens if it's
   impossible for Emacs to meet the requirements of the specifier?  This
   is not explained in the docstring.

 - I don't like the fact that different specifiers are set up in a way
   that the meaning of each specifier depends on the presence of other
   specifiers.  For example, in the spec list

   ((reuse-window same nil nil) (reuse-window-even-sizes . t))

   the second element only has a meaning if the first element is
   present---they are not independent.  It would be cleaner to use a
   plist, like this:

    (reuse-window :window same :reuse-window-even-sizes t)

   where ALL the behaviors are grouped together.

WDYT?

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Sat, Jul 16, 2011 at 22:35, Chong Yidong <cyd@stupidchicken.com> wrote:

> Here are several suggestions, and one question.

From someone who has read the docstring of `display-buffer-alist' once
too many and gleaned way too little meaning from it (no offense,
Martin, I love your work, just not this variable's doc)...

>  - Instead of allowing the car of each `display-buffer-alist' element to
>   be a _list_ of matchers, let it just be a matcher.  This is
>   semantically cleaner, and more consistent with other facilities in
>   Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
>   matching conditions can just add multiple alist elements.

Well, perhaps. No biggie IMHO.

>  - Instead of buffer matchers that are cons cells like (name . NAME),
>   (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
>   Strings are to be treated as regexps (if an exact match is desired,
>   the caller uses regexp-quote); symbols are treated as label matchers.

Yes, though the `name' case is perhaps common and it's a bit of a PITA
having to go through `regexp-quote'.

>  - Some of the display specifiers seem to allow contradictory meanings,
>   e.g.
>
>      (reuse-window same nil other)
>
>   means to reuse the selected window, provided the window is not on the
>   selected frame.  What does this mean?  And what happens if it's
>   impossible for Emacs to meet the requirements of the specifier?  This
>   is not explained in the docstring.

Yes!

>  - I don't like the fact that different specifiers are set up in a way
>   that the meaning of each specifier depends on the presence of other
>   specifiers.  For example, in the spec list
>
>   ((reuse-window same nil nil) (reuse-window-even-sizes . t))
>
>   the second element only has a meaning if the first element is
>   present---they are not independent.  It would be cleaner to use a
>   plist, like this:
>
>    (reuse-window :window same :reuse-window-even-sizes t)
>
>   where ALL the behaviors are grouped together.

YES!!!

    Juanma

Re: display-buffer-alist simplifications

[martin rudalics]

 >>  - Instead of allowing the car of each `display-buffer-alist' element to
 >>   be a _list_ of matchers, let it just be a matcher.  This is
 >>   semantically cleaner, and more consistent with other facilities in
 >>   Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
 >>   matching conditions can just add multiple alist elements.
 >
 > Well, perhaps. No biggie IMHO.

I just took this over from `special-display-regexps',
`same-window-buffer-names' and friends.  So I'd like to have an opinion
from people with some practice in customizing these options.

 >>  - Instead of buffer matchers that are cons cells like (name . NAME),
 >>   (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
 >>   Strings are to be treated as regexps (if an exact match is desired,
 >>   the caller uses regexp-quote); symbols are treated as label matchers.
 >
 > Yes, though the `name' case is perhaps common and it's a bit of a PITA
 > having to go through `regexp-quote'.

This was an attempt to unify things like `special-display-regexps` and
`special-display-buffer-names' into one option.  Can we say, in
retrospect, that having kept these two options distinct was not TRT?

 >>  - Some of the display specifiers seem to allow contradictory meanings,
 >>   e.g.
 >>
 >>      (reuse-window same nil other)
 >>
 >>   means to reuse the selected window, provided the window is not on the
 >>   selected frame.  What does this mean?  And what happens if it's
 >>   impossible for Emacs to meet the requirements of the specifier?  This
 >>   is not explained in the docstring.
 >
 > Yes!

Hmmm...  As I tried to explain there are two types of contradictions.
Some of them are dynamic and some of them are static (and, if such a
specifier is used as argument, can be even detected at compile time).
So I do have to rewrite the doc-string.

 >>  - I don't like the fact that different specifiers are set up in a way
 >>   that the meaning of each specifier depends on the presence of other
 >>   specifiers.  For example, in the spec list
 >>
 >>   ((reuse-window same nil nil) (reuse-window-even-sizes . t))
 >>
 >>   the second element only has a meaning if the first element is
 >>   present---they are not independent.  It would be cleaner to use a
 >>   plist, like this:
 >>
 >>    (reuse-window :window same :reuse-window-even-sizes t)
 >>
 >>   where ALL the behaviors are grouped together.
 >
 > YES!!!

OK.  I'll look into this.

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 >  - Instead of allowing the car of each `display-buffer-alist' element to
 >    be a _list_ of matchers, let it just be a matcher.  This is
 >    semantically cleaner, and more consistent with other facilities in
 >    Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
 >    matching conditions can just add multiple alist elements.

I currently produce these via `display-buffer-alist-set'.  But Sam
Steingold earlier bemoaned that

 > it produces a lot of separate entries like
 >  (((name . "*acl-listener*"))
 >   fun-with-args
 >   (fun-with-args special-display-popup-frame #1#))
 >  (((name . "*scheme*"))
 >   fun-with-args
 >   (fun-with-args special-display-popup-frame #1#))
 >  (((name . "*allegro*"))
 >   fun-with-args
 >   (fun-with-args special-display-popup-frame #1#))
 >  (((name . "*cmu*"))
 >   fun-with-args
 >   (fun-with-args special-display-popup-frame #1#))
 >
 > I think it would be better to group them together like I do above.

and I think he's right.  So I'd rather keep the list approach here (but
can be easily convinced of the contrary ;-) ).

 >  - Instead of buffer matchers that are cons cells like (name . NAME),
 >    (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
 >    Strings are to be treated as regexps (if an exact match is desired,
 >    the caller uses regexp-quote); symbols are treated as label matchers.

Stefan earlier suggested something similar last year.  I can do that
easily but it somehow precludes that we add other string- or symbol-like
types later (not that I can give or even think of an example).  So if
people agree on this, I'll do it.

 >  - Some of the display specifiers seem to allow contradictory meanings,
 >    e.g.
 >
 >       (reuse-window same nil other)
 >
 >    means to reuse the selected window, provided the window is not on the
 >    selected frame.  What does this mean?

Hopefully that `display-buffer' can't find a window meeting this
specification.  It's obviously a static case which means it could be
detected at the time the user sets the customization.

 >    And what happens if it's
 >    impossible for Emacs to meet the requirements of the specifier?  This
 >    is not explained in the docstring.

It's not taken.  Like when you specify to use the selected window if it
shows the same buffer and the selected window shows another buffer.  Or
you want to split a window but `display-buffer' can't find one which is
large enough.

 >  - I don't like the fact that different specifiers are set up in a way
 >    that the meaning of each specifier depends on the presence of other
 >    specifiers.  For example, in the spec list
 >
 >    ((reuse-window same nil nil) (reuse-window-even-sizes . t))
 >
 >    the second element only has a meaning if the first element is
 >    present---they are not independent.

That's an incorrect deduction, probably because the doc-string is
written badly.  If you add

(reuse-window (reuse-window-even-sizes . t))

as last element to `display-buffer-alist' it will apply to all
reuse-window operations that don't override it.

 > It would be cleaner to use a
 >    plist, like this:
 >
 >     (reuse-window :window same :reuse-window-even-sizes t)
 >
 >    where ALL the behaviors are grouped together.

I haven't looked into how to present plists in the customization
interface.  If I find a good way to do it, I'll make that change.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> it produces a lot of separate entries like
>> (((name . "*acl-listener*"))
>> fun-with-args
>> (fun-with-args special-display-popup-frame #1#))
>> (((name . "*scheme*"))
>> fun-with-args
>> (fun-with-args special-display-popup-frame #1#))
>> (((name . "*allegro*"))
>> fun-with-args
>> (fun-with-args special-display-popup-frame #1#))
>> (((name . "*cmu*"))
>> fun-with-args
>> (fun-with-args special-display-popup-frame #1#))
>> 
>> I think it would be better to group them together like I do above.

> and I think he's right.  So I'd rather keep the list approach here (but
> can be easily convinced of the contrary ;-) ).

We can combine them with a "a\\|b\\|c" regexp.

>> - Instead of buffer matchers that are cons cells like (name . NAME),
>> (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
>> Strings are to be treated as regexps (if an exact match is desired,
>> the caller uses regexp-quote); symbols are treated as label matchers.
> Stefan earlier suggested something similar last year.  I can do that
> easily but it somehow precludes that we add other string- or symbol-like
> types later (not that I can give or even think of an example).

I don't even know why you added the `label' case, so I don't think we
should worry about adding more types.

More generally, I have the impression it's a bit overengineered.
I can't find any comment anywhere that explains/justifies
the complexity.  Could you explain it here to help us refine the design
(or to add the explanation to the code)?

AFAIK, the only feature I know to be needed compared to what was
provided in Emacs-23 is a parameter `where' to display-buffer which
generalizes the `same-frame' parameter by turning it into a value of the
`where' and allowing other values such as `same-window' or
`near-minibuffer'.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > We can combine them with a "a\\|b\\|c" regexp.

I wonder whether users who don't know much about regexps would like such
a thing but it can be obviously done.

 > I don't even know why you added the `label' case, so I don't think we
 > should worry about adding more types.

The label case would specify the calling function so users can change
the behavior if the name of the buffer is not distinctive enough.  It
can be easily removed if people think it's not needed.

 > More generally, I have the impression it's a bit overengineered.
 > I can't find any comment anywhere that explains/justifies
 > the complexity.  Could you explain it here to help us refine the design
 > (or to add the explanation to the code)?

The complexity derives from the complexity of `display-buffer' and
probably from an attempt to handle each possible variant.  Emacs 23 was
not less complex in this regard: If you wanted to display a buffer in
the same window, you had at least four options to say so, namely
`same-window-buffer-names', `same-window-regexps',
`special-display-buffer-names' and `special-display-regexps' all with a
separate documentation of the individual behavior, leaving mostly
unexplained which option prevailed.  `display-buffer-alist' provides one
specifier to do that.  Do you really think `display-buffer-alist' is
more complex than the four options listed above taken together?  I don't
know how many times I went through the code of
`special-display-buffer-names' but I know that I still don't understand
it.

 > AFAIK, the only feature I know to be needed compared to what was
 > provided in Emacs-23 is a parameter `where' to display-buffer which
 > generalizes the `same-frame' parameter by turning it into a value of the
 > `where' and allowing other values such as `same-window' or
 > `near-minibuffer'.

Admittedly, atomic windows and side windows provide some considerable
additional complexity but there have been frequent requests that putting
a buffer into a window should practically always pass through
`display-buffer'.  Although I don't necessarily share that opinion I
tried to incorporate them in the design.  And people don't have to care
about these as long as they don't need them.  But I have no problems
removing support for them either.

There have been requests that `display-buffer' should be able to set the
size of a popped-up window and optionally specify a function to set the
height by calling a function like `fit-window-to-buffer'.  These can be
easily removed and we get a doc-string that is 35 line shorter.  So
we've got plenty of room for down-engineering `display-buffer-alist'.
Just tell me what you want to remove.

martin

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Mon, Jul 18, 2011 at 20:52, martin rudalics <rudalics@gmx.at> wrote:

> The label case would specify the calling function so users can change
> the behavior if the name of the buffer is not distinctive enough.  It
> can be easily removed if people think it's not needed.

No, I think it can be a very useful last resort and would like it to be kept.

> Emacs 23 was
> not less complex in this regard: If you wanted to display a buffer in
> the same window, you had at least four options to say so, namely
> `same-window-buffer-names', `same-window-regexps',
> `special-display-buffer-names' and `special-display-regexps' all with a
> separate documentation of the individual behavior, leaving mostly
> unexplained which option prevailed.  `display-buffer-alist' provides one
> specifier to do that.  Do you really think `display-buffer-alist' is
> more complex than the four options listed above taken together?

FWIW, I couldn't agree more with this.

> Admittedly, atomic windows and side windows provide some considerable
> additional complexity but there have been frequent requests that putting
> a buffer into a window should practically always pass through
> `display-buffer'.  Although I don't necessarily share that opinion I
> tried to incorporate them in the design.  And people don't have to care
> about these as long as they don't need them.  But I have no problems
> removing support for them either.
>
> There have been requests that `display-buffer' should be able to set the
> size of a popped-up window and optionally specify a function to set the
> height by calling a function like `fit-window-to-buffer'.  These can be
> easily removed and we get a doc-string that is 35 line shorter.  So
> we've got plenty of room for down-engineering `display-buffer-alist'.
> Just tell me what you want to remove.

IMHO, you've taken a lot of time to think of this, and the added
complexity, if any, is added flexibility.  I think we should strive to
make the current funcionality of your changes clearer and better
documented. If we stat removing things now, we'll be doomed to re-add
them some day, not long, when people starts to ask for ways to make it
work like it was before (you've seen enough of my private bug reports
to know how true that is ;-)

    Juanma

RE: display-buffer-alist simplifications

[Drew Adams]

> IMHO, you've taken a lot of time to think of this, and the added
> complexity, if any, is added flexibility.  I think we should strive to
> make the current funcionality of your changes clearer and better
> documented. If we stat removing things now, we'll be doomed to re-add
> them some day, not long, when people starts to ask for ways to make it
> work like it was before (you've seen enough of my private bug reports
> to know how true that is ;-)

I tend to agree with what Juanma says here, though I'm not really able to judge
what is needed, myself.  I expect that Martin has looked at the various
requirements more than anyone else, and I imagine he has done a good job of
coming up with a coherent solution that covers them.  We definitely do not want
to start over from scratch and risk destabilizing things a great deal.

That said, there is a lot to understand, and I'm guessing that we, including
Martin, might not see clearly what TRT is until, in fact, we start trying to
explain/describe it better.

That sounds backward, I know, but for lack of a functional spec I'm guessing
that it is especially when we try to document things more clearly that we might
come up with a few ideas that could improve the design.  It can sometimes happen
that by trying to explain something you understand it better and see some
possible simplifications.

In a way, that's perhaps what Stefan is doing here: trying to fit it all
together in his mind and ask questions about how things might be made simpler.
Nothing wrong with that.  Probably Martin will be the best judge in the end,
having a better grasp of all the ramifications, but it might help Martin for
people to express other views, as Stefan has done.

I worry a bit about too much redesign destabilizing things now.  Like Juanma, I
think of all the bugs and corner cases that Martin has dealt with already,
incrementally.

I posted some questions a while back wrt documenting this stuff.  Just trying to
answer questions like those might help us see a bit more clearly.  Maybe; dunno.
http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg00677.html

I know that Martin has planned to revisit the doc, in any case.  I'm guessing
that when we start to focus on the doc/explanation we will try better to look at
things as a user (different users, with different use cases), and that might
help the design.

I'm imagining a bit of iteration on this: explanation, maybe tweak the design a
bit, explanation, tweak,...  I don't expect perfect user doc or a perfect design
the first time around the block.  Actually, we've already been around the block
a bit.  And obviously, repeating what I said above, we want to avoid thrashing
and introducing new bugs.

Dunno, but I think it might be a mistake at this time for Martin to ask Stefan &
Yidong, "I can make such-and-such a change, if that's what you want - let me
know."  I suspect that it is not yet the time to decide some of these things.

Just one opinion.

Re: display-buffer-alist simplifications

[Stefan Monnier]

[ Joining the thread after a leave of absence.  ]

>> We can combine them with a "a\\|b\\|c" regexp.
> I wonder whether users who don't know much about regexps would like such
> a thing but it can be obviously done.

If they're afraid of regexp, they'll run away screaming from
display-buffer-alist (and probably from Emacs as well).  So I'm not
too concerned.

>> I don't even know why you added the `label' case, so I don't think we
>> should worry about adding more types.
> The label case would specify the calling function so users can change
> the behavior if the name of the buffer is not distinctive enough.  It
> can be easily removed if people think it's not needed.

I can guess that from its "definition" but that doesn't tell me why you
considered it was worth adding.  That's really what I'm generally
asking: a rationale document/comment that explains for each feature why
it was added (with concrete use cases).  Without it, it's difficult for
me to understand why we have so much complexity here.

BTW, rather than select based on a `label' may we should make it
possible for the user to set parameters that depend on the caller's
params, and/or on the place where the buffer gets displayed (whether it's
reusing a window, using a new frame, ... which of course could only
apply to params that do not influence which window to use).

> The complexity derives from the complexity of `display-buffer' and
> probably from an attempt to handle each possible variant.  Emacs 23 was
> not less complex in this regard: If you wanted to display a buffer in
> the same window, you had at least four options to say so, namely
> `same-window-buffer-names', `same-window-regexps',
> `special-display-buffer-names' and `special-display-regexps' all with a
> separate documentation of the individual behavior, leaving mostly
> unexplained which option prevailed.  `display-buffer-alist' provides one
> specifier to do that.  Do you really think `display-buffer-alist' is
> more complex than the four options listed above taken together?

Of course:
- special-display-regexps is a strict superset of
  special-display-buffer-names, so we can remove
  special-display-buffer-names (modulo backward compatibility).
- same for same-window-buffer-names and same-window-regexps.
- AFAIK the same-window param of special-display-regexps also makes
  special-display-regexps a superset of same-window-regexps.
So from a complexity point of view, there are just 4 redundant ways to
do the same thing.  Whereas display-buffer-alist adds many more things
we can do, so it adds a very different kind of complexity.

The way to think about it is: imagine when you did your rewrite, the
thing to which you needed to preserve backward compatibility was not
special-display-regexps but display-buffer-alist.  That would be
insanely more difficult.

> I don't know how many times I went through the code of
> `special-display-buffer-names' but I know that I still don't
> understand it.

Yup, and your code is even more complex.

> Admittedly, atomic windows and side windows provide some considerable
> additional complexity but there have been frequent requests that putting
> a buffer into a window should practically always pass through
> `display-buffer'.

I don't know what are atomic windows, nor side windows.  I don't know
when they might be used either, nor where they've been requested.
And neither do I know why they should be introduced by display-buffer.
So, as explained above (and in my previous email), I need a rationale
giving concrete usage example for each such feature, without which this
all seems way too complex.

> There have been requests that `display-buffer' should be able to set the
> size of a popped-up window and optionally specify a function to set the
> height by calling a function like `fit-window-to-buffer'.  These can be
> easily removed and we get a doc-string that is 35 line shorter.  So
> we've got plenty of room for down-engineering `display-buffer-alist'.
> Just tell me what you want to remove.

I can't tell you that without first knowing what each thing is used for.

Eli wrote:
> A comment from a naive bystander: these values are getting more and
> more close to Lisp code than to a value of a user variable.  Aren't we

Very true.  And in the Lisp world, we generally know very well how to
solve this problem: push the complexity to the point where any Lisp is
allowed, at which point it suddenly becomes a lot simpler and powerful
since you can just say "any Lisp expression".

I suspect that such a change could tremendously simplify the design,
while making it even more powerful.

BTW, I also agree with Jury that display-buffer-alist's default value
should be nil, to make it easier to change the default behavior (which
is hence kept elsewhere) in the future.

Martin wrote:
> The question whether and how to merge such a specifier is central to the
> question whether we should change the semantics of the not-this-window
> argument of `display-buffer' at all.

I think some form of merging is indispensable, but the rule should be
simple.  I don't know in which way the needs of merging influence the
current design, so again I can't judge the current design without first
some kind of explanation showing use cases, the problems they introduce
and the solution(s) you provide.

> Since most people do find `display-buffer-alist' much too complicated
> and Stefan is apparently opposed to almost all new features it provides,

That's a misunderstanding.  I only have a gut-feeling that we can
provide the same features (or even more features) with a simpler design,
and furthermore I can't intuitively see how you got to the current
design, so I'd like to pick your brain to understand your motivations.
The end result may very well be "Aha! Yes, your design makes a lot of
sense!".

> we should seriously consider reverting the changes
> introduced by buffer display specifiers.  In this context it makes
> also sense to discuss whether the Emacs 23 system is or is
> not complicated.

I don't much like the Emacs-23 system, largely because it is not
powerful enough.  So, no, going back is not a good option either, I think.

Eli wrote:
> Alternatively, we could postpone the pretest and invest the time into
> this issue now.

Indeed, I think that's what we should do.  This is an important matter
that's been a source of problem for Emacs users such as myself for
a long time, it's time to fix it.

Chong wrote:
> Another difference is that in default-frame-alist, each stored value
> (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
> value of a frame parameter.  In display-buffer-alist, each stored value
> is a _list_ of specifiers, and each specifier has its own no-obvious
> meaning.  For example, in the specifier

Indeed.  To me that's one of the reasons why I think
display-buffer-alist needs to be improved: each param should be as
clear, simple, and independent as is the case for frame params.
Ideally that is: before deciding it's actually true, I need to understand
why it's not already the case.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >>> We can combine them with a "a\\|b\\|c" regexp.
 >> I wonder whether users who don't know much about regexps would like such
 >> a thing but it can be obviously done.
 >
 > If they're afraid of regexp, they'll run away screaming from
 > display-buffer-alist (and probably from Emacs as well).  So I'm not
 > too concerned.

Have you ever tried the customization interface of
`display-buffer-alist'?  What's so frightening about it?

 >>> I don't even know why you added the `label' case, so I don't think we
 >>> should worry about adding more types.
 >> The label case would specify the calling function so users can change
 >> the behavior if the name of the buffer is not distinctive enough.  It
 >> can be easily removed if people think it's not needed.
 >
 > I can guess that from its "definition" but that doesn't tell me why you
 > considered it was worth adding.

When labels were discussed on emacs-devel you wrote:

   I might want that, indeed, but what I wrote above is not directly
   related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
   I might like to be able to have a single entry that covers both (and
   covers the ediff-ancestor one as well).  That would naturally extend to
   a more general form of classification of buffers (e.g. `ediff' for all
   things related to ediff... I'd probably also like to be able to use
   a major-mode name as a classification).

If you meant something different than what I implemented you should tell
me (1) what you meant then and (2) how you wanted that implemented.  If
all you meant in that text was to _not_ provide labels you should simply
have said so then.

 > That's really what I'm generally
 > asking: a rationale document/comment that explains for each feature why
 > it was added (with concrete use cases).  Without it, it's difficult for
 > me to understand why we have so much complexity here.

Have you ever looked into the Elisp manual of the window-pub branch?  If
not, please take a look there and tell me what is missing.  It's
difficult to adapt a manual text to constantly changing design requests.

 > BTW, rather than select based on a `label' may we should make it
 > possible for the user to set parameters that depend on the caller's
 > params, and/or on the place where the buffer gets displayed (whether it's
 > reusing a window, using a new frame, ... which of course could only
 > apply to params that do not influence which window to use).

The current trend intitiated by Chong aims at reducing expressiveness.
How do you want me to reconcile your proposal with this trend?

 >> I don't know how many times I went through the code of
 >> `special-display-buffer-names' but I know that I still don't
 >> understand it.
 >
 > Yup, and your code is even more complex.

Let's agree to disagree on that.  `special-display-buffer-names' had
only one serious user, namely Drew Adams.  I know that because my
rewrite had a number of bugs which we eliminated in a period of two
weeks mostly by trial and error.  In all that time no one else
complained.  I suppose you use it as well but since you apparently
advice `display-buffer' (or some subset of its routines) you were not
hit by these bugs.

`special-display-buffer-names' is complex because it prescribes 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's the kind of expressiveness Drew needs
because he's got no other choice.  It's far too expressive for all other
users.

 >> Admittedly, atomic windows and side windows provide some considerable
 >> additional complexity but there have been frequent requests that putting
 >> a buffer into a window should practically always pass through
 >> `display-buffer'.
 >
 > I don't know what are atomic windows, nor side windows.  I don't know
 > when they might be used either, nor where they've been requested.
 > And neither do I know why they should be introduced by display-buffer.
 > So, as explained above (and in my previous email), I need a rationale
 > giving concrete usage example for each such feature, without which this
 > all seems way too complex.

Atomic windows were discussed in a thread on how to implement tabs in a
separate window since you were opposed to using the headerline for them.
Side windows are a first step in solving the problem of how to implement
IDE like window configurations without having to advise basic functions
like `delete-other-windows'.  Both are described in separate sections of
the manual in the window-pub branch.

 >> There have been requests that `display-buffer' should be able to set the
 >> size of a popped-up window and optionally specify a function to set the
 >> height by calling a function like `fit-window-to-buffer'.  These can be
 >> easily removed and we get a doc-string that is 35 line shorter.  So
 >> we've got plenty of room for down-engineering `display-buffer-alist'.
 >> Just tell me what you want to remove.
 >
 > I can't tell you that without first knowing what each thing is used for.

So either you read the manual from window-pub or you have to wait until
I rewrote the manual for the trunk and we continue the discussion from
there.

 > BTW, I also agree with Jury that display-buffer-alist's default value
 > should be nil, to make it easier to change the default behavior (which
 > is hence kept elsewhere) in the future.

It is nil for a couple of weeks now.

 >> The question whether and how to merge such a specifier is central to the
 >> question whether we should change the semantics of the not-this-window
 >> argument of `display-buffer' at all.
 >
 > I think some form of merging is indispensable, but the rule should be
 > simple.  I don't know in which way the needs of merging influence the
 > current design, so again I can't judge the current design without first
 > some kind of explanation showing use cases, the problems they introduce
 > and the solution(s) you provide.

The rule is simple.  You scan a list of expressions until you find the
first method specifier that delivers a result.  You scan the tail of the
list for the first additional specifier that is needed for implementing
a specific behavior like evening window sizes and use it.

 >> Since most people do find `display-buffer-alist' much too complicated
 >> and Stefan is apparently opposed to almost all new features it provides,
 >
 > That's a misunderstanding.  I only have a gut-feeling that we can
 > provide the same features (or even more features) with a simpler design,
 > and furthermore I can't intuitively see how you got to the current
 > design, so I'd like to pick your brain to understand your motivations.
 > The end result may very well be "Aha! Yes, your design makes a lot of
 > sense!".

I'd immediately jump at any suggestion that is compatible with Emacs 23
options.  Unfortunately, till now the discussion didn't get us very far
because I didn't get satisfactoy answers on how to stay compatible with
the behavior of Emacs 23.

 >> Another difference is that in default-frame-alist, each stored value
 >> (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
 >> value of a frame parameter.  In display-buffer-alist, each stored value
 >> is a _list_ of specifiers, and each specifier has its own no-obvious
 >> meaning.  For example, in the specifier
 >
 > Indeed.  To me that's one of the reasons why I think
 > display-buffer-alist needs to be improved: each param should be as
 > clear, simple, and independent as is the case for frame params.
 > Ideally that is: before deciding it's actually true, I need to understand
 > why it's not already the case.

Making a frame either succeeds or fails in one attempt.  But when one
method for displaying a buffer fails, another one must be tried ...

martin

RE: display-buffer-alist simplifications

[Drew Adams]

> `special-display-buffer-names' had only one serious user,
> namely Drew Adams.  I know that because my rewrite had a
> number of bugs which we eliminated in a period of two
> weeks mostly by trial and error.  In all that time no one else
> complained.  I suppose you use it as well but since you apparently
> advice `display-buffer' (or some subset of its routines) you
> were not hit by these bugs.
> 
> `special-display-buffer-names' is complex because it prescribes
> 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's the kind of
> expressiveness Drew needs because he's got no other choice.
> It's far too expressive for all other users.

A comment, since my case has been identified as unique -

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.

3. The point is that I did not invent `special-display-buffer-names', and it was
not invented for me. ;-)  I have made use of it for decades (since at least
Emacs 19, maybe 18, IIRC), and I have always made the _same_ use of it.

4. Here is the _only_ use I make of it - Drew's weirdo use case.  I use only the
form (BUFFER FUNCTION OTHER-ARGS...), and only for two buffers: *Help* and
*Completions*.  This is my value of `special-display-buffer-names':

(("*Completions*" 1on1-display-*Completions*-frame
  ((background-color . "LavenderBlush2")
   (mouse-color . "VioletRed")
   (cursor-color . "VioletRed")
   (menu-bar-lines . 0)
   (tool-bar-lines . 0)
   (width . 100)))
 ("*Help*" 1on1-display-*Help*-frame
  ((background-color . "Thistle")
   (mouse-color . "Blue Violet")
   (cursor-color . "Blue Violet")
   (height . 40))))

5. How does it work?  Per the definition of `special-display-buffer-names', the
alist entry for *Help* or *Completions* is used by `special-display-popup-frame'
(the default value of `special-display-function') to display the buffer.  That's
all.

IOW, *Help* is displayed by calling `1on1-display-*Help*-frame', passing the
associated background-color, etc.  Similarly, *Completions* is shown by
`1on1-display-*Completions*-frame'.

6. In sum, my use of `special-display-buffer-names' is to provide a function and
associated frame parameters for displaying buffer *Help*, likewise *Completions.
Nothing more.  No big deal, IMO.

7. For buffer *Completions*, for example, the special-display function
`1on1-display-*Completions*-frame' does all of this:

a. Display the buffer in a separate frame with the given frame parameters.  This
also includes positioning it (left or right) per a user option.

b. Zoom the buffer text per a user option (typically to show more candidates by
reducing the text size).

c. Raise the frame to the front.

d. Redirect the frame's keyboard input focus to the standalone minibuffer frame,
if there is one.


HTH.  Personally, I do not consider my use of `special-display-buffer-names' to
be strange or outlandish - it seems pretty simple to me.

If it is true that I am the only one to use this feature, so be it.  But that in
itself does not make this feature or my use of it "complex".  And I would even
guess that if more things worked better in GNU Emacs wrt frames (as opposed to
just windows) then you might see more people using this feature.

FWIW, my code for this works in Emacs 20 through 23, and it also works with
Emacs 24 after Martin's efforts to fix some initial bugs (thank you, Martin!).
And it works cross-platform, AFAIK.  Not so far out, really.



[FWIW2: IIRC, my use of a standalone minibuffer and *Help* and *Completions*
frames predates my code in GNU Emacs.  IIRC (and no, I don't remember this very
well), I had the same thing in Epoch.  And in Epoch (IIRC) it _just worked_ out
of the box to have a standalone minibuffer frame: no fiddling, no "special"
frames, no input redirection, nada!

Again, that was long ago and I do not remember it well, but I'm pretty sure that
I had the same kind of setup as now, and I did not have to jump through any
hoops to get it.  When I moved back again to GNU Emacs I tried to reproduce some
of the nice setup I had in Epoch - with difficulty.  And, IIUC, some of Epoch's
fine features are still missing from GNU Emacs...  On n'arrete pas le progres.]

Re: display-buffer-alist simplifications

[martin rudalics]

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

 > 4. Here is the _only_ use I make of it - Drew's weirdo use case.  I use only the
 > form (BUFFER FUNCTION OTHER-ARGS...), and only for two buffers: *Help* and
 > *Completions*.  This is my value of `special-display-buffer-names':
 >
 > (("*Completions*" 1on1-display-*Completions*-frame
 >   ((background-color . "LavenderBlush2")
 >    (mouse-color . "VioletRed")
 >    (cursor-color . "VioletRed")
 >    (menu-bar-lines . 0)
 >    (tool-bar-lines . 0)
 >    (width . 100)))
 >  ("*Help*" 1on1-display-*Help*-frame
 >   ((background-color . "Thistle")
 >    (mouse-color . "Blue Violet")
 >    (cursor-color . "Blue Violet")
 >    (height . 40))))

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.

martin

RE: display-buffer-alist simplifications

[Drew Adams]

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

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

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

2. Are you sure that the ability to specify FUNCTION in the cons was added
later?

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
OTHER-ARGS...).

4. What's more, the doc string of `special-display-function' says this (in Emacs
20):

"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
`special-display-regexps'."

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


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

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

[martin rudalics]

 > 2. Are you sure that the ability to specify FUNCTION in the cons was added
 > later?

I looked again.  It was added later but already in 1994 by Per Abrahamsen.

	* frame.el (special-display-popup-frame): Rename new arg to ARGS.
	Allow (FUNCTION OTHER-ARGS...) as the value of ARGS.

The same-window and the same-frame features were added in 2001.

 > 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
 > OTHER-ARGS...).

You're right.  At that time this feature existed already.

 > In particular, I need a way to redirect the *Completions* input focus to the
 > standalone minibuffer.

It would be interesting to make this work when displaying a buffer in
another frame and _not_ wanting to direct focus to that frame as in
`display-buffer-other-frame'.  Somehow the application would have to be
able to tell `display-buffer' which frame shall be focused and/or shown
in the foreground instead.  If at least a few platforms can handle that,
obviously.

martin

RE: display-buffer-alist simplifications

[Drew Adams]

> I looked again.  It was added later but already in 1994 by 
> Per Abrahamsen.

Thanks again for checking this stuff.

>  > In particular, I need a way to redirect the *Completions* 
>  > input focus to the standalone minibuffer.
> 
> It would be interesting to make this work when displaying a buffer in
> another frame and _not_ wanting to direct focus to that frame as in
> `display-buffer-other-frame'.  Somehow the application would 
> have to be able to tell `display-buffer' which frame shall be focused 
> and/or shown in the foreground instead.  If at least a few platforms
> can handle that, obviously.

Sorry, I don't understand what you say here at all.  Could you maybe rephrase
that a bit, elaborate, or provide an example?

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>>> We can combine them with a "a\\|b\\|c" regexp.
>>> I wonder whether users who don't know much about regexps would like such
>>> a thing but it can be obviously done.
>> If they're afraid of regexp, they'll run away screaming from
>> display-buffer-alist (and probably from Emacs as well).  So I'm not
>> too concerned.
> Have you ever tried the customization interface of
> `display-buffer-alist'?  What's so frightening about it?

I'm not yet concerned about the ease of customizability.  I'm concerned
about the complexity of the semantics.

And I'm concerned about the ease with which someone will be able to
replace display-buffer-alist with something better 10 years from now
while preserving the compatibility with your (then legacy) code.

> When labels were discussed on emacs-devel you wrote:

>   I might want that, indeed, but what I wrote above is not directly
>   related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
>   I might like to be able to have a single entry that covers both (and
>   covers the ediff-ancestor one as well).  That would naturally extend to
>   a more general form of classification of buffers (e.g. `ediff' for all
>   things related to ediff... I'd probably also like to be able to use
>   a major-mode name as a classification).

> If you meant something different than what I implemented you should tell
> me (1) what you meant then and (2) how you wanted that implemented.  If
> all you meant in that text was to _not_ provide labels you should simply
> have said so then.

Ah, so that's what labels are for, now that makes more sense.  But then
`switch-to-buffer' should not be a label.  The labels I want are about
the "kind of buffer", not "the command used to display it".  The reason
for such a label is that buffer-names aren't good enough.
Maybe we can rely on major and minor modes instead, BTW.

>> That's really what I'm generally
>> asking: a rationale document/comment that explains for each feature why
>> it was added (with concrete use cases).  Without it, it's difficult for
>> me to understand why we have so much complexity here.

> Have you ever looked into the Elisp manual of the window-pub branch?

No.  Any reason it's not in the trunk yet?
I had the window-pub moved to old-branches because I thought it had
been merged.

> If not, please take a look there and tell me what is missing.

I just looked at it but I don't see any rationale for the design.
I only see a description of how the specifiers work (which is fine for
the Lispref, BTW: what I'm asking is not documentation for users of the
feature, but a rationale that explains how you got to this design).

>> BTW, rather than select based on a `label' may we should make it
>> possible for the user to set parameters that depend on the caller's
>> params, and/or on the place where the buffer gets displayed (whether it's
>> reusing a window, using a new frame, ... which of course could only
>> apply to params that do not influence which window to use).
> The current trend intitiated by Chong aims at reducing expressiveness.
> How do you want me to reconcile your proposal with this trend?

As explained already, I don't understand the current design, so I'm just
throwing out random comments which shouldn't be taken too seriously.

Note that I generally try to design things to be simpler and more
expressive (I don't see a contradiction here, because the
expressiveness is obtained by adding a few "hooks" where random elisp
code can be plugged).

> weeks mostly by trial and error.  In all that time no one else
> complained.  I suppose you use it as well but since you apparently
> advice `display-buffer' (or some subset of its routines) you were not
> hit by these bugs.

No, I don't advise display-buffer, and yes I was hit by these bugs as
well but was busy with other things, and Drew took care of the bug
reporting for me ;-)

> `special-display-buffer-names' is complex because it prescribes 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's the kind of expressiveness Drew needs
> because he's got no other choice.  It's far too expressive for all other
> users.

- the same-frame and the same-window parameters are one needed
  complexity.  But these should be consolidated into a single `where'
  parameter which could specify same-frame, same-window, and many other
  things (e.g. near-minibuffer).
- I don't see how you can specify "reusing a window on another frame" in
  special-display-buffer-names.
So I don't see the enormous complexity.  It's basically just:
- pop up a new frame and mark it dedicated.
- except when `where' says otherwise.
- and except for the hook case (where you can say "use this function to
  display the buffer").
The hook case gives you a lot of expressiveness since you get complete
control, but it adds very little complexity to the design.

There is added complexity coming in with the interaction with
pop-up-frames which also causes frames to be popped up, but they are not
marked dedicated, but that's another issue.

> Atomic windows were discussed in a thread on how to implement tabs in a
> separate window since you were opposed to using the headerline for them.

I don't think we should try and provide support for atomic windows with
display-buffer.  At least not yet.  I expect that any place where we
might want to use atomic windows will need to set things up
manually anyway.

BTW, I don't see any use of this feature in the window-pub branch.
Do you have some sample code showing how it works (the minimap package
in GNU ELPA seems like a good candidate)?

Same remark (don't integrate support for it in display-buffer, yet) and
same question (do you have sample code using it, ideally some attempt at
making ECB use that feature?) for side-windows.

>>> There have been requests that `display-buffer' should be able to set the
>>> size of a popped-up window and optionally specify a function to set the
>>> height by calling a function like `fit-window-to-buffer'.  These can be
>>> easily removed and we get a doc-string that is 35 line shorter.  So
>>> we've got plenty of room for down-engineering `display-buffer-alist'.
>>> Just tell me what you want to remove.
>> I can't tell you that without first knowing what each thing is used for.
> So either you read the manual from window-pub or you have to wait until
> I rewrote the manual for the trunk and we continue the discussion from
> there.

I'm not asking for "what does it do" (that which needs to be in the
manual), but "why did you add it, which use-case prompted you to add it
and what alternative solutions did you throw out" (things which are
typically not added in a manual, but could be welcome in the Commentary
section of window.el).

To take a concrete example: what use-cases did you have in mind that
required going from the 4 different cases of the old code
(i.e. `same-frame', `same-window', `new-frame-non-dedicated' and
`new-frame-dedicated), which in my mind should be something like
4 different values of the `where' parameter, to:
- `reuse-window' with 3 extra parameters.
- `reuse-window-dedicated' (AFAIK this is only used in switch-to-buffer
  so it's not clear why it needs to be supported in display-buffer).
- `pop-up-window' with a host of different values.
- `pop-up-window-split-unsplittable'.
- `pop-up-frame'.
- ...

...[time passes]...
...[BTW, could someone rewrite the docstring of display-buffer-alist to
use things like "if it has the form (label LABEL)" rather than "if it is
a cons cell whose car is `label'"?]...

IIUC the reason why you don't have just a single `where' parameter is so
that the merge between the specifiers given in display-buffer and
display-buffer-alist can be more fine-grained, right?  What were the
use-cases where you thought that was important?

>> BTW, I also agree with Jury that display-buffer-alist's default value
>> should be nil, to make it easier to change the default behavior (which
>> is hence kept elsewhere) in the future.
> It is nil for a couple of weeks now.

Yes, I saw that, thank you.

>>> The question whether and how to merge such a specifier is central to the
>>> question whether we should change the semantics of the not-this-window
>>> argument of `display-buffer' at all.
>> I think some form of merging is indispensable, but the rule should be
>> simple.  I don't know in which way the needs of merging influence the
>> current design, so again I can't judge the current design without first
>> some kind of explanation showing use cases, the problems they introduce
>> and the solution(s) you provide.
> The rule is simple.  You scan a list of expressions until you find the
> first method specifier that delivers a result.  You scan the tail of the
> list for the first additional specifier that is needed for implementing
> a specific behavior like evening window sizes and use it.

The problem I have with it is that the specifiers thingy acts in
2 different ways:
- an alist for some kinds of parameters, like the old special-display-regexps.
- an `or' that tries elements one after the other until one succeeds.
That adds conceptual complexity.

Along the same idea, some parameters that refine the way `reuse-window'
works are passed as "args" to `reuse-window' while others are provided
separately as specifiers.  That also adds conceptual complexity.

If we're willing to use a single `where' and give up on the finer
grained merging, then the specifiers can really be an alist, the
`where' parameter can be defined to always be a function (i.e. it's
somewhat like your `function' specifier) and we can cut down the
docstring of display-buffer-alist by a crap load, it just needs to
mention typically useful values of this parameter, such as
`display-buffer-same-window', or `display-buffer-same-frame' and those
functions can then document that they understand params such as
min-height.

This is still very flexible (except for the merging, obviously), since
you can write any function you want for the `where' arg.

> I'd immediately jump at any suggestion that is compatible with Emacs 23
> options.  Unfortunately, till now the discussion didn't get us very far
> because I didn't get satisfactoy answers on how to stay compatible with
> the behavior of Emacs 23.

Compatibility seems under control (not quite perfect, but you've been
very good with fixing the issues we bump into).

> Making a frame either succeeds or fails in one attempt.  But when one
> method for displaying a buffer fails, another one must be tried ...

In my experience when the preferred method fails, it's sufficient to
fallback on the default.  Do you have use-cases where this is not true?


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > I'm not yet concerned about the ease of customizability.  I'm concerned
 > about the complexity of the semantics.

When we are concerned about frightening inexperienced users we should be
concerned about the ease of customizability just as about anything else.

 > And I'm concerned about the ease with which someone will be able to
 > replace display-buffer-alist with something better 10 years from now
 > while preserving the compatibility with your (then legacy) code.

`display-buffer-alist' has no built-in dependencies wrt `display-buffer'
like the Emacs 23 buffer display options had.  So you would have to tell
me why you're concerned: Is it the number of options the variable offers
or the "inheritance" rules?

 > Ah, so that's what labels are for, now that makes more sense.  But then
 > `switch-to-buffer' should not be a label.  The labels I want are about
 > the "kind of buffer", not "the command used to display it".  The reason
 > for such a label is that buffer-names aren't good enough.
 > Maybe we can rely on major and minor modes instead, BTW.

We can rely on anything here.  And we can omit them.

 > No.  Any reason it's not in the trunk yet?

Yes.  Whenever I start writing the ChangeLog I have to think about
changing the design of `display-buffer-alist'.

 > I had the window-pub moved to old-branches because I thought it had
 > been merged.

It had been merged but for the manual and the NEWS entries.

 > I just looked at it but I don't see any rationale for the design.
 > I only see a description of how the specifiers work (which is fine for
 > the Lispref, BTW: what I'm asking is not documentation for users of the
 > feature, but a rationale that explains how you got to this design).

It contains rationales for atomic windows and side window.  It's more
difficult to describe rationales for the remaining features.  The idea
of providing a function to adjust the size of popped-up windows, for
example, came from a comment I found in the sources and the discussion
inititated by Chong here as "Resizing windows after display-buffer".

 > Note that I generally try to design things to be simpler and more
 > expressive (I don't see a contradiction here, because the
 > expressiveness is obtained by adding a few "hooks" where random elisp
 > code can be plugged).

We have to care for people who are not able or not willing to write such
random code.

 > - the same-frame and the same-window parameters are one needed
 >   complexity.

These parameters are ill-suited for a number of reasons:

(1) They are presented as special cases within a context of
     "Alternatively, an element of this list can be specified as
     \(BUFFER-NAME FRAME-PARAMETERS), where BUFFER-NAME is a buffer ...".
     Calling them frame parameters is misleading.

(2) They are interpreted exclusively by a function ironically called
     `special-display-popup-frame'.  If the buffer is already displayed
     in some window, these options are ignored by that function.

(3) Users devising their own `special-display-function' have to ignore
     them or write their own code to handle them.

 >   But these should be consolidated into a single `where'
 >   parameter which could specify same-frame, same-window, and many other
 >   things (e.g. near-minibuffer).

This should happen at one level above that handled by
`display-buffer-alist', for example, via macro specifiers.

 > - I don't see how you can specify "reusing a window on another frame" in
 >   special-display-buffer-names.

But it is done by `special-display-popup-frame' when it finds such a
window on a visible frame.  And you can turn that off and on by using
either another function via the \(BUFFER-NAME FUNCTION OTHER-ARGS) or
another `special-display-function'.

 > So I don't see the enormous complexity.  It's basically just:
 > - pop up a new frame and mark it dedicated.
 > - except when `where' says otherwise.
 > - and except for the hook case (where you can say "use this function to
 >   display the buffer").
 > The hook case gives you a lot of expressiveness since you get complete
 > control, but it adds very little complexity to the design.

The complexity is built into the code of `special-display-popup-frame'.
You don't know what `special-display-buffer-names' does unless you read
the code of that function.  The correct doc-string of
`special-display-buffer-names' would have to explain in full what the
code of `special-display-popup-frame' does.

 >> Atomic windows were discussed in a thread on how to implement tabs in a
 >> separate window since you were opposed to using the headerline for them.
 >
 > I don't think we should try and provide support for atomic windows with
 > display-buffer.  At least not yet.  I expect that any place where we
 > might want to use atomic windows will need to set things up
 > manually anyway.

OK.  Let's remove that part.

 > BTW, I don't see any use of this feature in the window-pub branch.
 > Do you have some sample code showing how it works (the minimap package
 > in GNU ELPA seems like a good candidate)?

I was writing such code when you announced the feature freeze ;-)

 > Same remark (don't integrate support for it in display-buffer, yet) and
 > same question (do you have sample code using it, ideally some attempt at
 > making ECB use that feature?) for side-windows.

I'm stronlgy for keeping this in `display-buffer-alist'.  Personally, I
think that side windows should be used in two ways only: Either by the
user via `display-buffer' - so she can display a window showing a
specific buffer always in the same place of the frame - or by special
window managing code like that of ECB.

I have no code showing how to use it but I experimented with it by
setting `display-buffer-alist' appropriately.  I expect that people who
ask for IDE-like behavior will eventually try it and provide some
feedback.

 > I'm not asking for "what does it do" (that which needs to be in the
 > manual), but "why did you add it, which use-case prompted you to add it
 > and what alternative solutions did you throw out" (things which are
 > typically not added in a manual, but could be welcome in the Commentary
 > section of window.el).

I proceeded as follows:

- Base the design on that of `same-window-regexps' and
   `same-window-buffer-names'.

- Use one variable instead of the twenty or so options we had.

- Use a "what to do" paradigm instead of "what to avoid".

- Try to make the customization interface readable.

- Add things that have been asked for in our forums.

- Make it compatible with Emacs 23.

I don't recall what I threw out.  I had specifiers to set the maximum
size of popped-up window, adjust the size of reused windows, and tried
to improve reusing windows on other frames.

 > To take a concrete example: what use-cases did you have in mind that
 > required going from the 4 different cases of the old code
 > (i.e. `same-frame', `same-window', `new-frame-non-dedicated' and
 > `new-frame-dedicated), which in my mind should be something like
 > 4 different values of the `where' parameter, to:
 > - `reuse-window' with 3 extra parameters.

There are five basic methods: reuse-window, pop-up-window, pop-up-frame,
use-side-window and specifying a function.

`same-window' is provided as a macro specifier.  The semantics of
`same-frame' is difficult to capture as I already explained above: You
can specify it in `special-display-regexps' but if
`special-display-popup-frame' finds a window on another frame it uses
that.  Worse, same-frame will work only if I specify whether I shall
first try to reuse a window and then pop up another one and then ...  I
have same-frame-other-window as a macro specifier but am not overly
happy with it.

The difference between `new-frame-non-dedicated' and
`new-frame-dedicated' is not clear to me.  I suppose it stems mainly
from the fact that you see dedication as a way to specify what to do
with the window or frame when it's no more used.  I specially installed
the quit-restore parameter for this purpose but it's currently mostly
overridden by the dedicated status of the window.  Couldn't you try in
your private code whether you could use that parameter instead and leave
window dedication to what it should stand for according to its name:
Avoid that `display-buffer' and/or `set-window-buffer' reuse a window
for showing another buffer.

 > - `reuse-window-dedicated' (AFAIK this is only used in switch-to-buffer
 >   so it's not clear why it needs to be supported in display-buffer).

It can (and maybe should) be used for side windows where the IDE people
have that idea of windows that should always show the same buffer or one
of the same "group".

 > - `pop-up-window' with a host of different values.

The `selected' window case is obvious, I think: It allows users a basic
control where to show the buffer (largest and lru are not very suitable
for that).  `root' allows to show the buffer in a very predictable
position on some side of the frame.

Combining `selected' and `above' you can, for example, to display the
ispell window without all the tribulations of the current code plus make
it possible to show that window on a separate frame instead.

Combining `root' and `left' allows, for example, to display the speedbar
in a window on the right of the frame.

 > - `pop-up-window-split-unsplittable'.

A silly leftover from the old code, IIUC.  I'd do away with it at any
time.

 > - `pop-up-frame'.
 > - ...
 >
 > ...[time passes]...
 > ...[BTW, could someone rewrite the docstring of display-buffer-alist to
 > use things like "if it has the form (label LABEL)" rather than "if it is
 > a cons cell whose car is `label'"?]...

Yes.  I'd really love if someone did that and all associated cleanups.

 > IIUC the reason why you don't have just a single `where' parameter is so
 > that the merge between the specifiers given in display-buffer and
 > display-buffer-alist can be more fine-grained, right?  What were the
 > use-cases where you thought that was important?

You understand correctly.  Once for compatibility with Emacs 23, once
for applications, and once for people who want fine-grained control.
Abstractions (like near-minibuffer and same-frame) would be built on
top of that.

 >> The rule is simple.  You scan a list of expressions until you find the
 >> first method specifier that delivers a result.  You scan the tail of the
 >> list for the first additional specifier that is needed for implementing
 >> a specific behavior like evening window sizes and use it.
 >
 > The problem I have with it is that the specifiers thingy acts in
 > 2 different ways:
 > - an alist for some kinds of parameters, like the old special-display-regexps.
 > - an `or' that tries elements one after the other until one succeeds.
 > That adds conceptual complexity.

I can't deny that.  But that's how `display-buffer' alway worked, in a
hard-coded form.  Even if you use a rule based system, the rules must
permit to specify that I want to pop up a window first and if that fails
try reusing another one.  Or am I missing something here?

 > Along the same idea, some parameters that refine the way `reuse-window'
 > works are passed as "args" to `reuse-window' while others are provided
 > separately as specifiers.  That also adds conceptual complexity.

True.  I was too silly to do that better.  And I'm still too silly to
find a better solution.

 > If we're willing to use a single `where' and give up on the finer
 > grained merging, then the specifiers can really be an alist, the
 > `where' parameter can be defined to always be a function (i.e. it's
 > somewhat like your `function' specifier) and we can cut down the
 > docstring of display-buffer-alist by a crap load, it just needs to
 > mention typically useful values of this parameter, such as
 > `display-buffer-same-window', or `display-buffer-same-frame' and those
 > functions can then document that they understand params such as
 > min-height.

Wouldn't this move options away from the user?  I think we know now how
many people passed their own function to `special-display-popup-frame',
namely two.  I'd like to know how many people wrote their own
`special-display-function'.  And most uses of `display-buffer-function'
were intended to avoid some special cases calling `display-buffer' with
`display-buffer-function' bound to nil again.

One thing we could do is provide a second option - some form of
simplified `display-buffer-alist'.  It would take precedence over
`display-buffer-alist' and relate only macro specifiers to the user.

 > In my experience when the preferred method fails, it's sufficient to
 > fallback on the default.  Do you have use-cases where this is not true?

In Emacs 23 the preferred method is to try some five methods in the
worst case.  There's no single default fallback.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> I'm not yet concerned about the ease of customizability.  I'm concerned
>> about the complexity of the semantics.
> When we are concerned about frightening inexperienced users we should be
> concerned about the ease of customizability just as about anything else.

But I'm not concerned about either of them.  I first want to have
something that's simple and powerful, and then I'll worry about making
in usable via customize.

>> And I'm concerned about the ease with which someone will be able to
>> replace display-buffer-alist with something better 10 years from now
>> while preserving the compatibility with your (then legacy) code.
> `display-buffer-alist' has no built-in dependencies wrt `display-buffer'
> like the Emacs 23 buffer display options had.

I don't understand what you're saying here.

> So you would have to tell me why you're concerned: Is it the number of
> options the variable offers or the "inheritance" rules?

Some mix of those.  The number in and of itself is not necessarily
problematic, except that there's a lot of coupling between different
kinds of elements, so it's hard to split things.

>> Ah, so that's what labels are for, now that makes more sense.  But then
>> `switch-to-buffer' should not be a label.  The labels I want are about
>> the "kind of buffer", not "the command used to display it".  The reason
>> for such a label is that buffer-names aren't good enough.
>> Maybe we can rely on major and minor modes instead, BTW.
> We can rely on anything here.  And we can omit them.

First we need to remove the switch-to-buffer' label (and other similar
labels, if any).

>> No.  Any reason it's not in the trunk yet?
> Yes.  Whenever I start writing the ChangeLog I have to think about
> changing the design of `display-buffer-alist'.

Fair enough.

>> I had the window-pub moved to old-branches because I thought it had
>> been merged.
> It had been merged but for the manual and the NEWS entries.

Makes sense, actually.

> It contains rationales for atomic windows and side window.  It's more
> difficult to describe rationales for the remaining features.

Hmm...

>> Note that I generally try to design things to be simpler and more
>> expressive (I don't see a contradiction here, because the
>> expressiveness is obtained by adding a few "hooks" where random elisp
>> code can be plugged).
> We have to care for people who are not able or not willing to write such
> random code.

Of course, but that's trivial to do so: just provide a set of functions
they can use, with clear enough names.  They end up working just as well
as constants like `reuse-window' (they can even look identical in
Customize thanks to :tag).

Note also that there are many more people able to write Elisp code than
people who are able to combine various specifiers to get
a specific behavior.  And Elisp code is supported by various tools like
eldoc, edebug, ...

>> - the same-frame and the same-window parameters are one needed
>> complexity.
> These parameters are ill-suited for a number of reasons:

I'm not saying that their Emacs-23 shape and implementation is needed.
I'm saying that the corresponding functionality is needed.
Obviously you agree, you even provided a lot more fine-grained control
over such things in your code.

> (1) They are presented as special cases within a context of
>     "Alternatively, an element of this list can be specified as
>     \(BUFFER-NAME FRAME-PARAMETERS), where BUFFER-NAME is a buffer ...".
>     Calling them frame parameters is misleading.

Yes the name "frame parameter" is not right any more.  The doc reflects
only the original design which only considered "pop up a frame" as the
possible behaviors.

> (2) They are interpreted exclusively by a function ironically called
>     `special-display-popup-frame'.

Yes, same problem of naming and documentation as above.

>     If the buffer is already displayed in some window, these options
>     are ignored by that function.

That's often the right thing to do, so it's just a lack of flexibility
in the old code.

> (3) Users devising their own `special-display-function' have to ignore
>     them or write their own code to handle them.

I don't know of any such user, so I don't worry about them too much.

>> But these should be consolidated into a single `where'
>> parameter which could specify same-frame, same-window, and many other
>> things (e.g. near-minibuffer).
> This should happen at one level above that handled by
> `display-buffer-alist', for example, via macro specifiers.

We already have 2 ways to name particular values (via either their value
or their function cell), so hopefully we can use one of the two as
"macro specifier" without having to introduce this new concept and its
attending code.

>> - I don't see how you can specify "reusing a window on another frame" in
>> special-display-buffer-names.
> But it is done by `special-display-popup-frame' when it finds such a
> window on a visible frame.  And you can turn that off and on by using
> either another function via the \(BUFFER-NAME FUNCTION OTHER-ARGS) or
> another `special-display-function'.

So you're saying that the FUNCTION hook lets you specify endless things
including "reusing a window on another frame".  Yes, that's true.
And the great thing about it is that it's all done by just one simple
hook: there is no special code designed to see whether the user
specified "reusing a window on another frame" or not.

>> So I don't see the enormous complexity.  It's basically just:
>> - pop up a new frame and mark it dedicated.
>> - except when `where' says otherwise.
>> - and except for the hook case (where you can say "use this function to
>> display the buffer").
>> The hook case gives you a lot of expressiveness since you get complete
>> control, but it adds very little complexity to the design.

> The complexity is built into the code of `special-display-popup-frame'.

I don't find it particularly complex.  It just tries each one of
the 5 different cases in turn: use FUNCTION, already-displayed,
same-window, same-frame, pop-up-frame.

And we should remove the `same-window' and `same-frame' parameters of
special-display-regexps (these were errors and would have been better
handled as predefined functions to use as FUNCTION hooks).  Then the
resulting code is even more straightforward.

> 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 correct doc-string of `special-display-buffer-names' would have to
> explain in full what the code of `special-display-popup-frame' does.

What's missing?

>>> Atomic windows were discussed in a thread on how to implement tabs in a
>>> separate window since you were opposed to using the headerline for them.
>> I don't think we should try and provide support for atomic windows with
>> display-buffer.  At least not yet.  I expect that any place where we
>> might want to use atomic windows will need to set things up
>> manually anyway.
> OK.  Let's remove that part.

Good.

>> BTW, I don't see any use of this feature in the window-pub branch.
>> Do you have some sample code showing how it works (the minimap package
>> in GNU ELPA seems like a good candidate)?
> I was writing such code when you announced the feature freeze ;-)

Whenever you find the time, please continue your experiment.  Until we
have actual experience with that feature, it should be strongly marked
as experimental so we can easily change it.
IOW I urge you to hurry up with "writing such code" so we may have
a chance to tweak the design if needed.  Note also that minimap is not
affected by the freeze.

>> Same remark (don't integrate support for it in display-buffer, yet) and
>> same question (do you have sample code using it, ideally some attempt at
>> making ECB use that feature?) for side-windows.
> I'm stronlgy for keeping this in `display-buffer-alist'.  Personally, I
> think that side windows should be used in two ways only: Either by the
> user via `display-buffer' - so she can display a window showing a
> specific buffer always in the same place of the frame - or by special
> window managing code like that of ECB.

I can somewhat imagine using it from display-buffer-alist as
you describe.  So if that works OK, I guess we can keep support for it
in display-buffer-alist.  Tho I'd really like for it to be
more modularized.

> I proceeded as follows:
> - Base the design on that of `same-window-regexps' and
>   `same-window-buffer-names'.
> - Use one variable instead of the twenty or so options we had.
> - Use a "what to do" paradigm instead of "what to avoid".
> - Try to make the customization interface readable.
> - Add things that have been asked for in our forums.
> - Make it compatible with Emacs 23.

There's a crucial element missing: keep the design simple and modular.

>> To take a concrete example: what use-cases did you have in mind that
>> required going from the 4 different cases of the old code
>> (i.e. `same-frame', `same-window', `new-frame-non-dedicated' and
>> `new-frame-dedicated), which in my mind should be something like
>> 4 different values of the `where' parameter, to:
>> - `reuse-window' with 3 extra parameters.
> There are five basic methods: reuse-window, pop-up-window, pop-up-frame,
> use-side-window and specifying a function.

I suggest to bring this down to 1: specifying a function.
We can provide the other 4 as predefined functions to use there.

> `same-window' is provided as a macro specifier.

Using function names is just as good as a "macro specifier" I think here.

> The difference between `new-frame-non-dedicated' and
> `new-frame-dedicated' is not clear to me.

Trivial: one marks the frame's only window as dedicated, the other
doesn't.

There's really nothing more to it, tho in the old code, those two cases
are handled differently (one controlled by pop-up-frames, making
non-dedicated frames with default-frame-alist, the other controlled by
special-display-regexps making dedicated frames with
pop-up-frame-alist).  But in your code, this is more cleanly unified by
just giving a (dedicate . t) param.

> I suppose it stems mainly from the fact that you see dedication as
> a way to specify what to do with the window or frame when it's no
> more used.

It's also to force display-buffer (and switch-to-buffer when called
from Lisp packages) to use some other window/frame.  I don't want any
other buffer ever shown in my *Completions* window (which I carefully
size and place next to my minibuffer-only frame), same for my other
strongly-dedicated windows like *compilation*.

> I specially installed the quit-restore parameter for this
> purpose but it's currently mostly overridden by the dedicated status
> of the window.  Couldn't you try in your private code whether you
> could use that parameter instead and leave window dedication to what
> it should stand for according to its name: Avoid that `display-buffer'
> and/or `set-window-buffer' reuse a window for showing another buffer.

It might be an OK replacement for the soft dedication, yes.

>> - `reuse-window-dedicated' (AFAIK this is only used in switch-to-buffer
>> so it's not clear why it needs to be supported in display-buffer).
> It can (and maybe should) be used for side windows where the IDE people
> have that idea of windows that should always show the same buffer or one
> of the same "group".

Hmmm... yeah, I guess I can see how it might be useful there.
But then I'd rather keep it within the `side-window' (i.e. make it
a parameter of that display function).

>> - `pop-up-window' with a host of different values.
> The `selected' window case is obvious, I think: It allows users a basic
> control where to show the buffer (largest and lru are not very suitable
> for that).  `root' allows to show the buffer in a very predictable
> position on some side of the frame.
> Combining `selected' and `above' you can, for example, to display the
> ispell window without all the tribulations of the current code plus make
> it possible to show that window on a separate frame instead.
> Combining `root' and `left' allows, for example, to display the speedbar
> in a window on the right of the frame.

Thanks.

>> - `pop-up-window-split-unsplittable'.
> A silly leftover from the old code, IIUC.  I'd do away with it at any
> time.

You mean it's inherited from Emacs-23 or from your old code?  If it's
from your old code, then please remove it.  If it's from Emacs-23, maybe
as well, tho I'd first like to see where that feature was.

>> IIUC the reason why you don't have just a single `where' parameter is so
>> that the merge between the specifiers given in display-buffer and
>> display-buffer-alist can be more fine-grained, right?  What were the
>> use-cases where you thought that was important?
> You understand correctly.  Once for compatibility with Emacs 23,

Where does compatibility require fine-grained merging?

> once for applications,

Do you have concrete use-cases?

> and once for people who want fine-grained control.

I don't think that's a good enough justification for the complexity
(tho of course it's good to provide it if the complexity is needed for
other reasons anyway).

> Abstractions (like near-minibuffer and same-frame) would be
> built on top of that.

But you're saying that you're not satisfied with the way same-frame is
built on top of that, right?  And I don't see near-minibuffer so
I suspect you don't have experience with it either.  I think writing
a display-buffer-near-minibuffer function will be simpler/cleaner than
trying to come up with some clever way to combine various specifiers.

>> The problem I have with it is that the specifiers thingy acts in
>> 2 different ways:
>> - an alist for some kinds of parameters, like the old
>>   special-display-regexps.
>> - an `or' that tries elements one after the other until one succeeds.
>> That adds conceptual complexity.
> I can't deny that.  But that's how `display-buffer' alway worked, in a
> hard-coded form.

I don't find the two comparable because one is a piece of code which
provides one complex behavior via a simple API, whereas
display-buffer-alist provides a complex API.

> Even if you use a rule based system, the rules must permit to specify
> that I want to pop up a window first and if that fails try reusing
> another one.

No.  You just have to provide one rule which reproduces the old complex
behavior (and could use that old code to do that).  If someone wants
something else, she can write another rule with another behavior, but we
don't have to care about it nor about the interaction between different
rules as long as you restrict each rule to be used in isolation.

>> Along the same idea, some parameters that refine the way `reuse-window'
>> works are passed as "args" to `reuse-window' while others are provided
>> separately as specifiers.  That also adds conceptual complexity.
> True.  I was too silly to do that better.  And I'm still too silly to
> find a better solution.

Then let's try together.

>> If we're willing to use a single `where' and give up on the finer
>> grained merging, then the specifiers can really be an alist, the
>> `where' parameter can be defined to always be a function (i.e. it's
>> somewhat like your `function' specifier) and we can cut down the
>> docstring of display-buffer-alist by a crap load, it just needs to
>> mention typically useful values of this parameter, such as
>> `display-buffer-same-window', or `display-buffer-same-frame' and those
>> functions can then document that they understand params such as
>> min-height.
> Wouldn't this move options away from the user?

Can't think of any, no.

> I think we know now how many people passed their own function to
> `special-display-popup-frame', namely two.

I know my setup was copied by a few people back in the day when
I started using it, so I'm pretty sure there are more than 2 ;-)

> I'd like to know how many people wrote their own
> `special-display-function'.  And most uses of
> `display-buffer-function' were intended to avoid some special cases
> calling `display-buffer' with `display-buffer-function' bound to
> nil again.

Agreed.  Both should be marked obsolete.

>> In my experience when the preferred method fails, it's sufficient to
>> fallback on the default.  Do you have use-cases where this is not true?
> In Emacs 23 the preferred method is to try some five methods in the
> worst case.  There's no single default fallback.

I think we're miscommunicating here.
I'm just saying that if the caller says `same-window' and the user says
`same-frame', it's OK to just ignore the caller's specification and just
use `same-frame'.
There's no need to merge to two specs: if the user has no preference,
then obey the caller's preference, but if the user has a preference then
it's OK to just drop the caller's preference (so if the user's
preference needs to "fallback" it can fall back on the global default
rather than first trying the caller's preference).

Here's a new, minimalist starting point for display-buffer-alist:

(defvar display-buffer-alist nil
  "Specifications of how to display which buffer.
This is list where each element has the form (CONDITION . RULE) where
CONDITION is either a regular expression which is matched
  against the buffer's name or a function called with the buffer
  to be displayed (so the function can check the major-mode, ...) which
  should return non-nil if the RULE should be used.
RULE has the form (FUNCTION . ARGS) such that if CONDITION matches,
  FUNCTION is called with the buffer as first argument and with ARGS
  as subsequent arguments.  ARGS is usually an alist, but it really
  depends on FUNCTION.  FUNCTION should return the window it used.")

And display-buffer has only two args: BUFFER and RULE such that if none
of display-buffer-alist conditions applies to the buffer, then RULE is
used, otherwise it's ignored.

Then we provide a few standard functions to use in RULE to reproduce
the old Emacs-23 features:
- display-buffer-default (the good ol' code doing all the complex choice
  and used when no RULE is used).
- display-buffer-same-window (which calls display-buffer-same-frame if the
  selected window can't be used).
- display-buffer-other-window.
- display-buffer-same-frame (which calls display-buffer-default if the
  same-frame can't be used).
- display-buffer-pop-up-frame (which does what setting pop-up-frames to
  t used to do, more or less, i.e. create a non-dedicated frame with
  default-frame-alist).
- display-buffer-dedicated-frame (which pops up a new frame with
  a dedicated window obeying pop-up-frame-alist).
Plus a few new functions for new features:
- display-buffer-side-window.
- display-buffer-<something> for things like ispell or speedbar.

Such a design is at least as flexible as what we had in Emacs-23.
I think it's flexible enough to cover the cases you've mentioned.
And it's a lot simpler than the current design (maybe the total
complexity may not seem less if you consider the docstring of
display-buffer-alist together with the docstrings of all those new
standard functions, but the modularity is the key).

I'm not sure it's good enough, tho:
- does it really allow us to get rid of all the let-bindings of
  pop-up-frames and friends around calls to display-buffer?
- not sure where the behavior of "reuse existing window showing the same
  buffer" should be implemented.  In Emacs-23 this is done before
  checking any of special-display-*, which means it can only be
  controlled via display-buffer-function (which I want to obsolete), but
  I think there's a case to be made for letting RULE override it.
  One way to do that is to move this "reuse window" behavior into (all?)
  the standard functions.
- the "pop-up-window-set-height" and friends apply to several of the
  standard functions, so those functions would need to share some code,
  via something like a display-buffer-postprocess-window function.
  But I think that's not a real problem.

What problems do you guys (fore)see with such a setup?


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >> `display-buffer-alist' has no built-in dependencies wrt `display-buffer'
 >> like the Emacs 23 buffer display options had.
 >
 > I don't understand what you're saying here.

That the behavior of `display-buffer' largely depends on how it is
written and not on how the user can customize it.  Take the doc-string
of `pop-up-windows':

   "Non-nil means `display-buffer' should make a new window."

But it won't do that when `pop-up-frames' is non-nil.  The only thing
that privileges `pop-up-frames' in this regard is the way
`display-buffer' is written.  So the options obey the code and this is
the orginal sin of this function.

The absurd consequence of this is that with `pop-up-frames' non-nil
`ctl-x-4-map' becomes identical to `ctl-x-5-map' and
`find-file-other-window' an alias for `find-file-other-frame'.  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.

 > First we need to remove the switch-to-buffer' label (and other similar
 > labels, if any).

Done.

 >>> - the same-frame and the same-window parameters are one needed
 >>> complexity.
 >> These parameters are ill-suited for a number of reasons:
 >
 > I'm not saying that their Emacs-23 shape and implementation is needed.
 > I'm saying that the corresponding functionality is needed.

These are crutches to work around the built-in dependencies of buffer
display options and `display-buffer' as described above.  If
`display-buffer' had been only told what to do instead of what to avoid,
this extra functionality would not have been needed.

 > Obviously you agree, you even provided a lot more fine-grained control
 > over such things in your code.

In order to make the behavior less ambiguous, yes.

 >>     If the buffer is already displayed in some window, these options
 >>     are ignored by that function.
 >
 > That's often the right thing to do, so it's just a lack of flexibility
 > in the old code.

It shouldn't be up to the code to decide whether a window shall be
reused.

 >> (3) Users devising their own `special-display-function' have to ignore
 >>     them or write their own code to handle them.
 >
 > I don't know of any such user, so I don't worry about them too much.

So apparently users are not interested in writing their own functions.

 > We already have 2 ways to name particular values (via either their value
 > or their function cell), so hopefully we can use one of the two as
 > "macro specifier" without having to introduce this new concept and its
 > attending code.

`display-buffer-alist' already accepts both - primitive method
specifiers and macro specifiers.

 >>> - I don't see how you can specify "reusing a window on another frame" in
 >>> special-display-buffer-names.
 >> But it is done by `special-display-popup-frame' when it finds such a
 >> window on a visible frame.  And you can turn that off and on by using
 >> either another function via the \(BUFFER-NAME FUNCTION OTHER-ARGS) or
 >> another `special-display-function'.
 >
 > So you're saying that the FUNCTION hook lets you specify endless things
 > including "reusing a window on another frame".

No.  I said that "reusing a window on another frame" is already built
into `special-display-popup-frame'.  And that you can turn it OFF by
using the "FUNCTION hook".

 > Yes, that's true.
 > And the great thing about it is that it's all done by just one simple
 > hook: there is no special code designed to see whether the user
 > specified "reusing a window on another frame" or not.

In fact.  Users have to write their own function in order to _avoid_
that `display-buffer' does certain things.  It's precisely this behavior
I wanted to put an end to.

 >> The complexity is built into the code of `special-display-popup-frame'.
 >
 > I don't find it particularly complex.  It just tries each one of
 > the 5 different cases in turn: use FUNCTION,

No.  If it calls FUNCTION it won't try any of the others.

 > already-displayed,

Usually this is a NOOP since `display-buffer' did check that case
before.  So what usually happens is a needless extra call of
`get-buffer-window'.

It is, however, much more revealing what happens in the non-usual case:

- With the default value of `display-buffer-reuse-frames',
   `display-buffer' by itself does not reuse a window on another frame.
   `special-display-popup-frame' would reuse such a window.  Hence,
   `special-display-popup-frame' does not respect the user option
   `display-buffer-reuse-frames' with the consequence that this function
   is broken on systems where reusing frames doesn't work.

- The third argument of `display-buffer' can explictly name the frames
   to consider when searching for a window showing the buffer.
   `special-display-popup-frame' deliberately ignores that argument.

- `special-display-popup-frame' does ignore the second argument of
   `display-buffer'.  As a consequence, applications must bind
   `special-display-regexps' to nil in order to guarantee that the
   selected window is not reused.

So `special-display-popup-frame' silently ignores a user option and
overrides arguments in a much more aggressive and uncontrolled form than
would be possible with `display-buffer-alist'.  If its behavior were
correctly documented in the doc-strings of `display-buffer',
`display-buffer-reuse-frames', and all involved sepcial-display options
and functions, those doc-strings alone would already exceed that of
`display-buffer-alist'.

 > same-window,

Useless because overridden by `same-window-regexps' and
`same-window-buffer-names'.

 > same-frame,

Necessitated by the `pop-up-frames' overrides `pop-up-windows' paradigm
explained above.

 > pop-up-frame.

Which is the original and only reasonable motivation for
`special-display-popup-frame'.

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

 >> The correct doc-string of `special-display-buffer-names' would have to
 >> explain in full what the code of `special-display-popup-frame' does.
 >
 > What's missing?

Are the arguments above not enough?

 > There's a crucial element missing: keep the design simple and modular.

Nothing about this element is particular wrt buffer display.  If you
consider Emacs 23 options more simple or modular than
`display-buffer-alist' then you are missing one aspect: Emacs 23 doesn't
bother to explain the dependencies between options.  If you say that
`pop-up-windows' non-nil means "`display-buffer' should make a new
window" and `pop-up-frames' means "whether `display-buffer' should make
a separate frame" then you don't explain anything.

 >> There are five basic methods: reuse-window, pop-up-window, pop-up-frame,
 >> use-side-window and specifying a function.
 >
 > I suggest to bring this down to 1: specifying a function.
 > We can provide the other 4 as predefined functions to use there.
 >
 >> `same-window' is provided as a macro specifier.
 >
 > Using function names is just as good as a "macro specifier" I think here.

OK.

 >> The difference between `new-frame-non-dedicated' and
 >> `new-frame-dedicated' is not clear to me.
 >
 > Trivial: one marks the frame's only window as dedicated, the other
 > doesn't.
 >
 > There's really nothing more to it, tho in the old code, those two cases
 > are handled differently (one controlled by pop-up-frames, making
 > non-dedicated frames with default-frame-alist, the other controlled by
 > special-display-regexps making dedicated frames with
 > pop-up-frame-alist).  But in your code, this is more cleanly unified by
 > just giving a (dedicate . t) param.
 >
 >> I suppose it stems mainly from the fact that you see dedication as
 >> a way to specify what to do with the window or frame when it's no
 >> more used.
 >
 > It's also to force display-buffer (and switch-to-buffer when called
 > from Lisp packages) to use some other window/frame.  I don't want any
 > other buffer ever shown in my *Completions* window (which I carefully
 > size and place next to my minibuffer-only frame), same for my other
 > strongly-dedicated windows like *compilation*.

Why did you have to dedicate the window for this purpose?  If
`pop-up-frames' is non-nil, you get another frame before Emacs even
tries to reuse a window not showing the buffer already.

 >> I specially installed the quit-restore parameter for this
 >> purpose but it's currently mostly overridden by the dedicated status
 >> of the window.  Couldn't you try in your private code whether you
 >> could use that parameter instead and leave window dedication to what
 >> it should stand for according to its name: Avoid that `display-buffer'
 >> and/or `set-window-buffer' reuse a window for showing another buffer.
 >
 > It might be an OK replacement for the soft dedication, yes.

Then please try it by using `quit-restore-window' instead of
`quit-window'.

 >>> - `reuse-window-dedicated' (AFAIK this is only used in switch-to-buffer
 >>> so it's not clear why it needs to be supported in display-buffer).
 >> It can (and maybe should) be used for side windows where the IDE people
 >> have that idea of windows that should always show the same buffer or one
 >> of the same "group".
 >
 > Hmmm... yeah, I guess I can see how it might be useful there.
 > But then I'd rather keep it within the `side-window' (i.e. make it
 > a parameter of that display function).

Can be done.

 >>> - `pop-up-window-split-unsplittable'.
 >> A silly leftover from the old code, IIUC.  I'd do away with it at any
 >> time.
 >
 > You mean it's inherited from Emacs-23 or from your old code?  If it's
 > from your old code, then please remove it.  If it's from Emacs-23, maybe
 > as well, tho I'd first like to see where that feature was.

A frame can have the parameter unsplittable

`unsplittable'
      If non-`nil', this frame's window is never split automatically.

The specifier tells `display-buffer' to ignore that parameter.  If you
say it's useless, I'll remove it.

 >>> IIUC the reason why you don't have just a single `where' parameter is so
 >>> that the merge between the specifiers given in display-buffer and
 >>> display-buffer-alist can be more fine-grained, right?  What were the
 >>> use-cases where you thought that was important?
 >> You understand correctly.  Once for compatibility with Emacs 23,
 >
 > Where does compatibility require fine-grained merging?

In `display-buffer-normalize-default'.

 >> once for applications,
 >
 > Do you have concrete use-cases?

I would have to go through the sources to find that.

 >> and once for people who want fine-grained control.
 >
 > I don't think that's a good enough justification for the complexity
 > (tho of course it's good to provide it if the complexity is needed for
 > other reasons anyway).
 >
 >> Abstractions (like near-minibuffer and same-frame) would be
 >> built on top of that.
 >
 > But you're saying that you're not satisfied with the way same-frame is
 > built on top of that, right?

Because it's too coarse-grained for my taste.

 > And I don't see near-minibuffer so
 > I suspect you don't have experience with it either.

`near-minibuffer' is even worse in this regard.  You can always try
splitting the root window - it will get you a window just above the
minibuffer, if there's room for it.  If you use bottom side windows you
can specify the slot for the window which gives you quite good control.
Anything else is unreliable - the window above the minibuffer might be
the window that contains the most important information for the user at
that moment - reusing it would be very strange, at least.

 > I think writing
 > a display-buffer-near-minibuffer function will be simpler/cleaner than
 > trying to come up with some clever way to combine various specifiers.

Any such function would run into just the same problems as
`special-display-popup-frame'.  I won't deny that such functions are
useful for a small set of users.  Their usual fate is that people always
want to add just this tiny but very important functionality.

 >> I can't deny that.  But that's how `display-buffer' alway worked, in a
 >> hard-coded form.
 >
 > I don't find the two comparable because one is a piece of code which
 > provides one complex behavior via a simple API, whereas
 > display-buffer-alist provides a complex API.

I suppose you really intended to write "whereas display-buffer-alist
provides one simple behavior via a complex API" here ;-)

 >> Even if you use a rule based system, the rules must permit to specify
 >> that I want to pop up a window first and if that fails try reusing
 >> another one.
 >
 > No.  You just have to provide one rule which reproduces the old complex
 > behavior (and could use that old code to do that).

For this purpose I would have to leave in and document the old options
forever.

 >  If someone wants
 > something else, she can write another rule with another behavior, but we
 > don't have to care about it nor about the interaction between different
 > rules as long as you restrict each rule to be used in isolation.

We'd get two, three, many instances of `special-display-popup-frame'.

martin

RE: display-buffer-alist simplifications

[Drew Adams]

> 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

[martin rudalics]

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

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

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

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

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

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

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

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.

martin

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.

Re: display-buffer-alist simplifications

[martin rudalics]

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

Toggling the variable value changes the semantics of the command
`foo-other-window' to that of `foo-other-frame' iff the
`foo-other-window' command invokes `display-buffer'.  If it doesn't, it
might do anything it wants.  The semantics of "-other-window" is nowhere
defined within Emacs.  `org-switch-to-buffer-other-window', for example,
specially binds `pop-up-frames' to nil in order to achieve its "other
window" behavior.

And the definite plus is a definite minus for those who document the
behavior.  Take these (obviously wrong) excerpts from the Emacs manual:

   20.4 Displaying in Another Window
   =================================

   `C-x 4' is a prefix key for commands that select another window
   (splitting the window if there is only one) and select a buffer in that
   window.  Different `C-x 4' commands have different ways of finding the
   buffer to select.

or

      `C-x 4 f' (`find-file-other-window') is like `C-x C-f' except that
   the buffer containing the specified file is selected in another window.
   The window that was selected before `C-x 4 f' continues to show the
   same buffer it was already showing.  If this command is used when only
   one window is being displayed, that window is split in two, with one
   window showing the same buffer as before, and the other one showing the
   newly requested file.

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

Adopting your reasoning we could simply bind C-x 5 to `make-frame' and
do away with the entire C-x 5 map and the associated descriptions.

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

Are you sure it's not rebound by the application in these cases?

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

;-)

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

We can leave in any magic people are used to.  But then you won't find
anyone who implements things like showing the ispell buffer in a
separate frame or removing the frame showing dired's marked files when
it's no more needed.  Which means that the current `split-window' or
`save-window-excursion' based code is effectively carved in stone.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

> The absurd consequence of this is that with `pop-up-frames' non-nil
> `ctl-x-4-map' becomes identical to `ctl-x-5-map' and
> `find-file-other-window' an alias for `find-file-other-frame'.  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.

This just goes back to the problem of code let-binding pop-up-<foo>
instead of providing a SPECIFIER/RULE argument to display-buffer.

Fixing this is indeed (for me) the main goal of buffer-display-alist.

>> First we need to remove the switch-to-buffer' label (and other similar
>> labels, if any).
> Done.

Thanks.

>>> If the buffer is already displayed in some window, these options
>>> are ignored by that function.
>> That's often the right thing to do, so it's just a lack of flexibility
>> in the old code.
> It shouldn't be up to the code to decide whether a window shall be
> reused.

I already said that same-frame and same-window parameters in
special-display-regexps were mistakes, so there's no point complaining much
more about their quirks.

>>> (3) Users devising their own `special-display-function' have to ignore
>>> them or write their own code to handle them.
>> I don't know of any such user, so I don't worry about them too much.
> So apparently users are not interested in writing their own functions.

I tend to read it in another way: users are not interested in changing
this part of the behavior because it's good enough (and also the
FUNCTION of special-display-regexps provides the same flexibility, tho
in a typically more convenient way).

>> We already have 2 ways to name particular values (via either their value
>> or their function cell), so hopefully we can use one of the two as
>> "macro specifier" without having to introduce this new concept and its
>> attending code.
> `display-buffer-alist' already accepts both - primitive method
> specifiers and macro specifiers.

But it doesn't get it for free: it needs extra code to handle those,
plus extra documentation to explain what they do and how to use them.

>> Yes, that's true.
>> And the great thing about it is that it's all done by just one simple
>> hook: there is no special code designed to see whether the user
>> specified "reusing a window on another frame" or not.
> In fact.  Users have to write their own function in order to _avoid_
> that `display-buffer' does certain things.  It's precisely this behavior
> I wanted to put an end to.

If you oppose the FUNCTION hook, then we're in an irreconcilable disagreement.

I'm not sure why you choose to interpret it as a way to "avoid that
display-buffer does certain things" rather than, like any other Emacs
hooks, a way to override the default.

As a matter of fact, all my uses of FUNCTION (and I think Drew's as
well) are designed to make display-buffer do things that it otherwise
never does (e.g. redirect focus).

Of course, among all the things you can do with a hook, some of them are
to do less than the default.

>>> The complexity is built into the code of `special-display-popup-frame'.
>> I don't find it particularly complex.  It just tries each one of
>> the 5 different cases in turn: use FUNCTION,
> No.  If it calls FUNCTION it won't try any of the others.

If FUNCTION is not provided, it will try the others, so clearly it
tries the cases in turn.

I feel like you're tremendously defensive here, probably because you
feel like your work is being criticized.  I'm sorry you feel that way.
I really appreciate all the work you've put into it.

I like a lot of what I see.  But yes, I want to throw out a large part
of buffer-display-alist.  I know this is hard to take, but it's part of
the normal experiment/design/experiment/design cycle and it doesn't mean
your work was wasted, only that it was instrumental in coming up with
the final design, rather than the final code.  And still, most of the
code you wrote won't be affected, so we're only talking about
a small portion.

>> already-displayed,

> Usually this is a NOOP since `display-buffer' did check that case
> before.  So what usually happens is a needless extra call of
> `get-buffer-window'.

I'm not sure why you're so concerned about this reuse-window behavior of
special-display-popup-frame.  Ignoring the failed same-frame and
same-window parameters, you'll see that this reuse-window is almost
always the right thing to do: display-buffer would display the buffer in
a new dedicated frame, so if it's already displayed it's presumably in
a dedicated frame built previous with the same params and it would be
bad to create a second dedicated frame showing the same thing.

As for "calling get-buffer-window redundantly":
- I wouldn't worry about the redundancy performancewise.
- It's not always redundant.
- You're talking about the Emacs-23 implementation, whereas I'm
  concerned (and I'm talking here only) about the API.

> - With the default value of `display-buffer-reuse-frames',
>   `display-buffer' by itself does not reuse a window on another frame.
>   `special-display-popup-frame' would reuse such a window.  Hence,
>   `special-display-popup-frame' does not respect the user option
>   `display-buffer-reuse-frames' with the consequence that this function
>   is broken on systems where reusing frames doesn't work.

I have no interest in defending the Emacs-23 behavior here.  I only want
to streamline buffer-display-alist.
This said, I wonder which systems you're thinking of where "reusing
[dedicated] frames doesn't work".  I added [dedicated] since it's 99%
sure that the frame is dedicated in the scenario you're talking about.

> So `special-display-popup-frame' silently ignores a user option and
> overrides arguments in a much more aggressive and uncontrolled form than
> would be possible with `display-buffer-alist'.

Right, to some extent it sucks.  To some extent it provides
a good default.  Still: irrelevant to the design of buffer-display-alist.

Maybe the issue is that you want to be able to reproduce every detail of
the previous behavior in buffer-display-alist, whereas I don't.

>> same-window,
> Useless because overridden by `same-window-regexps' and
> `same-window-buffer-names'.

No: the whole point of `same-window' was to unify everything into
special-display-regexps and make the same-window-* horrors obsolete,
just like you're trying to unify everything under buffer-display-alist.

>> same-frame,
> Necessitated by the `pop-up-frames' overrides `pop-up-windows' paradigm
> explained above.

No: added because pop-up-frames applies to all buffers whereas we're
taking here about options which depend on the buffer name.

>> pop-up-frame.
> Which is the original and only reasonable motivation for
> `special-display-popup-frame'.

The already-displayed is intricately linked to the pop-up-frame because
the frame is dedicated.  That's why the already-displayed behavior has
been in special-display-popup-frame from the very beginning.

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

If there's complexity it's not really in special-display-buffer-names but
in how it sometimes behave similarly to (yet subtly differently from)
the rest of display-buffer.
And from where I stand the complexity is on the display-buffer side
rather than the special-display-buffer-names ;-)

In any case it's still not relevant to streamlining buffer-display-alist.

>>> The correct doc-string of `special-display-buffer-names' would have to
>>> explain in full what the code of `special-display-popup-frame' does.
>> What's missing?
> Are the arguments above not enough?

So, IIUC the missing parts are:
- the third arg of display-buffer is ignored.
- the second arg of display-buffer is ignored.
- it reuses windows regardless of (the ill-named) display-buffer-reuse-frames.
The first is a largely irrelevant bug since that arg is pretty much
never used (and your new code indeed gets rid of it).
The second is a real bug.  We don't usually document bugs.
The third is a pretty logically-evident behavior (tho only if you
ignore the same-frame and same-window failures), but sure, feel free to
document it.  Still a far cry from the complexity of buffer-display-alist.

>> It's also to force display-buffer (and switch-to-buffer when called
>> from Lisp packages) to use some other window/frame.  I don't want any
>> other buffer ever shown in my *Completions* window (which I carefully
>> size and place next to my minibuffer-only frame), same for my other
>> strongly-dedicated windows like *compilation*.
> Why did you have to dedicate the window for this purpose?  If
> `pop-up-frames' is non-nil, you get another frame before Emacs even
> tries to reuse a window not showing the buffer already.

A lot of code uses switch-to-buffer, kill-buffer, bury-buffer, ...

>>> I specially installed the quit-restore parameter for this
>>> purpose but it's currently mostly overridden by the dedicated status
>>> of the window.  Couldn't you try in your private code whether you
>>> could use that parameter instead and leave window dedication to what
>>> it should stand for according to its name: Avoid that `display-buffer'
>>> and/or `set-window-buffer' reuse a window for showing another buffer.
>> It might be an OK replacement for the soft dedication, yes.
> Then please try it by using `quit-restore-window' instead of
> `quit-window'.

I pretty much never use quit-window.

>>>> - `pop-up-window-split-unsplittable'.
>>> A silly leftover from the old code, IIUC.  I'd do away with it at any
>>> time.
>> You mean it's inherited from Emacs-23 or from your old code?  If it's
>> from your old code, then please remove it.  If it's from Emacs-23, maybe
>> as well, tho I'd first like to see where that feature was.

> A frame can have the parameter unsplittable

> `unsplittable'
>      If non-`nil', this frame's window is never split automatically.

I do know that part, yes.

> The specifier tells `display-buffer' to ignore that parameter.  If you
> say it's useless, I'll remove it.

The old code never ignored that parameter, right?  So I don't think we
should add a special feature to ignore that parameter, because I haven't
heard any request for such a feature.

>>>> IIUC the reason why you don't have just a single `where' parameter is so
>>>> that the merge between the specifiers given in display-buffer and
>>>> display-buffer-alist can be more fine-grained, right?  What were the
>>>> use-cases where you thought that was important?
>>> You understand correctly.  Once for compatibility with Emacs 23,
>> Where does compatibility require fine-grained merging?
> In `display-buffer-normalize-default'.

I don't mean "where in the code", but "in which concrete case".

OK, after thinking a tiny bit I see one case where "merging" might be
needed: the Emacs-23 `not-this-window' specifier (the only possible
specifier in Emacs-23) should preferably not be overruled by
display-buffer-alist.

OK, so that breaks my "RULE argument is only used if
buffer-display-alist doesn't specify it own RULE".

Hmm... so that means that the `not-this-window' arg is a constraint
imposed by the caller and that the user should not be able to override
(or close enough).  Not sure how to reconcile this with my design, indeed.

>>> once for applications,
>> Do you have concrete use-cases?
> I would have to go through the sources to find that.

That would be very helpful.

> `near-minibuffer' is even worse in this regard.  You can always try
> splitting the root window - it will get you a window just above the
> minibuffer, if there's room for it.  If you use bottom side windows you
> can specify the slot for the window which gives you quite good control.
> Anything else is unreliable - the window above the minibuffer might be
> the window that contains the most important information for the user at
> that moment - reusing it would be very strange, at least.

Oh yes.  And then there's the minibuffer-only frame case ;-)
But that's OK: it would have to be a best-effort in any case and the
user can override it.

>> I think writing a display-buffer-near-minibuffer function will be
>> simpler/cleaner than trying to come up with some clever way to
>> combine various specifiers.
> Any such function would run into just the same problems as
> `special-display-popup-frame'.

I do not regard those problems as significant.

>>> I can't deny that.  But that's how `display-buffer' alway worked, in a
>>> hard-coded form.
>> I don't find the two comparable because one is a piece of code which
>> provides one complex behavior via a simple API, whereas
>> display-buffer-alist provides a complex API.
> I suppose you really intended to write "whereas display-buffer-alist
> provides one simple behavior via a complex API" here ;-)

Hmm... let me think .. no ;-)

>>> Even if you use a rule based system, the rules must permit to specify
>>> that I want to pop up a window first and if that fails try reusing
>>> another one.
>> No.  You just have to provide one rule which reproduces the old complex
>> behavior (and could use that old code to do that).
> For this purpose I would have to leave in and document the old options
> forever.

That's OK.  They're written already.

>> If someone wants something else, she can write another rule with
>> another behavior, but we don't have to care about it nor about the
>> interaction between different rules as long as you restrict each rule
>> to be used in isolation.

> We'd get two, three, many instances of `special-display-popup-frame'.

Look more closely.  It'd be like:
- removing same-frame and same-window from special-display-popup-frame.
- removing the "ignore the 3rd arg of display-buffer" bug because we
  removed that 3rd arg.
- removing the "ignore the 2nd arg of display-buffer" bug because we
  redefined how it works.
- at this point special-display-popup-frame is limited to
  - reuse a window that shows the given buffer.
  - otherwise create a new frame with the provided params.
  I.e. as clean as it started, trivial to document and code.
- then, yes, provide multiple instances of such simple and clean things.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >> The absurd consequence of this is that with `pop-up-frames' non-nil
 >> `ctl-x-4-map' becomes identical to `ctl-x-5-map' and
 >> `find-file-other-window' an alias for `find-file-other-frame'.  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.
 >
 > This just goes back to the problem of code let-binding pop-up-<foo>
 > instead of providing a SPECIFIER/RULE argument to display-buffer.

Unfortunately not.  An OTHER-WINDOW argument must sill be interpreted
consistently with what the user expects.  The
other-window-means-other-frame specifier I use is a gross hack in this
regard.  I suppose that if I had known about this issue from the very
beginning, I would never have started to rewrite `display-buffer' which
would have spared us the present discussion.

 > Fixing this is indeed (for me) the main goal of buffer-display-alist.
 >
 >>>> If the buffer is already displayed in some window, these options
 >>>> are ignored by that function.
 >>> That's often the right thing to do, so it's just a lack of flexibility
 >>> in the old code.
 >> It shouldn't be up to the code to decide whether a window shall be
 >> reused.
 >
 > I already said that same-frame and same-window parameters in
 > special-display-regexps were mistakes, so there's no point complaining much
 > more about their quirks.

This is not about the same-frame and same-window parameters.  It's about
the reuse-window-already-showing-the-buffer part.

 > I tend to read it in another way: users are not interested in changing
 > this part of the behavior because it's good enough (and also the
 > FUNCTION of special-display-regexps provides the same flexibility, tho
 > in a typically more convenient way).

OK.  Let's hope that your view is correct.

 >> In fact.  Users have to write their own function in order to _avoid_
 >> that `display-buffer' does certain things.  It's precisely this behavior
 >> I wanted to put an end to.
 >
 > If you oppose the FUNCTION hook, then we're in an irreconcilable disagreement.

Isn't the function specifier of `display-buffer-alist' enough argument
that I'm in favor of such a hook?  What I said was that users should not
have to write a function in order to make `display-buffer' _not_ behave
in a certain way.  They should write functions because that's how they
want `display-buffer' to behave like.

 > I'm not sure why you choose to interpret it as a way to "avoid that
 > display-buffer does certain things" rather than, like any other Emacs
 > hooks, a way to override the default.

Read for example the posts about `split-window-sensibly' on emacs-help.
All people ask for is how to avoid that Emacs splits the window
horizontally and how to turn it off.  I want a default that doesn't
provoke users to ask how to turn something off that's bad for them.  I
want a default that provokes users to ask how to turn something on
that's good for them.

 > As a matter of fact, all my uses of FUNCTION (and I think Drew's as
 > well) are designed to make display-buffer do things that it otherwise
 > never does (e.g. redirect focus).

I never disputed that.

 > Of course, among all the things you can do with a hook, some of them are
 > to do less than the default.

Ideally, this should not be necessary.  The default should be the
minimum.

 > But yes, I want to throw out a large part
 > of buffer-display-alist.  I know this is hard to take,

Not at all.  Personally, I would take out much more than anyone on this
list.  But I hate the idea that someone will put them in again ...

 > but it's part of
 > the normal experiment/design/experiment/design cycle and it doesn't mean
 > your work was wasted, only that it was instrumental in coming up with
 > the final design, rather than the final code.

Don't be concerned about this.  The only extra thing I'd ask you to
spare is the side-window stuff simply because I don't have a better idea
to ask people to experiment with it.

 >>>> The complexity is built into the code of `special-display-popup-frame'.
 >>> I don't find it particularly complex.  It just tries each one of
 >>> the 5 different cases in turn: use FUNCTION,
 >> No.  If it calls FUNCTION it won't try any of the others.
 >
 > If FUNCTION is not provided, it will try the others, so clearly it
 > tries the cases in turn.

This wasn't my point: If FUNCTION is provided and doesn't produce a
result, the other cases are ignored.  If any of the others is present
and doesn't produce a result, the remaining cases are processed.

 > I'm not sure why you're so concerned about this reuse-window behavior of
 > special-display-popup-frame.

Because I had some very hard time here discussing this with a user who
can't live with such behavior.

 > Ignoring the failed same-frame and
 > same-window parameters, you'll see that this reuse-window is almost
 > always the right thing to do: display-buffer would display the buffer in
 > a new dedicated frame, so if it's already displayed it's presumably in
 > a dedicated frame built previous with the same params and it would be
 > bad to create a second dedicated frame showing the same thing.
 >
 > As for "calling get-buffer-window redundantly":
 > - I wouldn't worry about the redundancy performancewise.
 > - It's not always redundant.

In the cases where it's not redundant it violates either an argument or
a user setting.

 > - You're talking about the Emacs-23 implementation, whereas I'm
 >   concerned (and I'm talking here only) about the API.

The discussion was about whether we need a fine-grained interface.  The
interface provided by `special-display-popup-frame' is coarse-grained.

 > This said, I wonder which systems you're thinking of where "reusing
 > [dedicated] frames doesn't work".  I added [dedicated] since it's 99%
 > sure that the frame is dedicated in the scenario you're talking about.

The emacs-devel thread is called

"[display-buffer] a way to make it behave as before?"

 >> So `special-display-popup-frame' silently ignores a user option and
 >> overrides arguments in a much more aggressive and uncontrolled form than
 >> would be possible with `display-buffer-alist'.
 >
 > Right, to some extent it sucks.  To some extent it provides
 > a good default.  Still: irrelevant to the design of buffer-display-alist.
 >
 > Maybe the issue is that you want to be able to reproduce every detail of
 > the previous behavior in buffer-display-alist, whereas I don't.

I have to deal with the complaints that something doesn't work as
before.

 >>> same-window,
 >> Useless because overridden by `same-window-regexps' and
 >> `same-window-buffer-names'.
 >
 > No: the whole point of `same-window' was to unify everything into
 > special-display-regexps and make the same-window-* horrors obsolete,
 > just like you're trying to unify everything under buffer-display-alist.

Ahh ...  yet an another failed attempt to unify things.  Since
`special-display-regexps' was my reference point for
`display-buffer-alist' history repeats itself.

 >>> same-frame,
 >> Necessitated by the `pop-up-frames' overrides `pop-up-windows' paradigm
 >> explained above.
 >
 > No: added because pop-up-frames applies to all buffers whereas we're
 > taking here about options which depend on the buffer name.

Almost precisely what I meant for ".*".

 >>> pop-up-frame.
 >> Which is the original and only reasonable motivation for
 >> `special-display-popup-frame'.
 >
 > The already-displayed is intricately linked to the pop-up-frame because
 > the frame is dedicated.  That's why the already-displayed behavior has
 > been in special-display-popup-frame from the very beginning.

I don't dispute that all this works for you.  But if we want to
generalize this concept we have to deal with users who don't want to
`display-buffer-reuse-frames' and with applications that insist on
`NOT-THIS-WINDOW'.

 >>>> 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.
 >
 > If there's complexity it's not really in special-display-buffer-names but
 > in how it sometimes behave similarly to (yet subtly differently from)
 > the rest of display-buffer.
 > And from where I stand the complexity is on the display-buffer side
 > rather than the special-display-buffer-names ;-)

Because too much has been built into `display-buffer' already.  Agreed.

 > In any case it's still not relevant to streamlining buffer-display-alist.
 >
 >>>> The correct doc-string of `special-display-buffer-names' would have to
 >>>> explain in full what the code of `special-display-popup-frame' does.
 >>> What's missing?
 >> Are the arguments above not enough?
 >
 > So, IIUC the missing parts are:
 > - the third arg of display-buffer is ignored.
 > - the second arg of display-buffer is ignored.
 > - it reuses windows regardless of (the ill-named) display-buffer-reuse-frames.
 > The first is a largely irrelevant bug since that arg is pretty much
 > never used (and your new code indeed gets rid of it).
 > The second is a real bug.  We don't usually document bugs.
 > The third is a pretty logically-evident behavior (tho only if you
 > ignore the same-frame and same-window failures), but sure, feel free to
 > document it.  Still a far cry from the complexity of buffer-display-alist.

Let's disagree ;-)

 >> Why did you have to dedicate the window for this purpose?  If
 >> `pop-up-frames' is non-nil, you get another frame before Emacs even
 >> tries to reuse a window not showing the buffer already.
 >
 > A lot of code uses switch-to-buffer, kill-buffer, bury-buffer, ...

I lost you here.  If it goes through `display-buffer', all you need is
`pop-up-frames'.  If it doesn't, `display-buffer-mark-dedicated' won't
have any effect.

 >>>> I specially installed the quit-restore parameter for this
 >>>> purpose but it's currently mostly overridden by the dedicated status
 >>>> of the window.  Couldn't you try in your private code whether you
 >>>> could use that parameter instead and leave window dedication to what
 >>>> it should stand for according to its name: Avoid that `display-buffer'
 >>>> and/or `set-window-buffer' reuse a window for showing another buffer.
 >>> It might be an OK replacement for the soft dedication, yes.
 >> Then please try it by using `quit-restore-window' instead of
 >> `quit-window'.
 >
 > I pretty much never use quit-window.

What do you use then?

 >>>>> - `pop-up-window-split-unsplittable'.
 >>>> A silly leftover from the old code, IIUC.  I'd do away with it at any
 >>>> time.
 >>> You mean it's inherited from Emacs-23 or from your old code?  If it's
 >>> from your old code, then please remove it.  If it's from Emacs-23, maybe
 >>> as well, tho I'd first like to see where that feature was.
 >
 >> A frame can have the parameter unsplittable
 >
 >> `unsplittable'
 >>      If non-`nil', this frame's window is never split automatically.
 >
 > I do know that part, yes.
 >
 >> The specifier tells `display-buffer' to ignore that parameter.  If you
 >> say it's useless, I'll remove it.
 >
 > The old code never ignored that parameter, right?  So I don't think we
 > should add a special feature to ignore that parameter, because I haven't
 > heard any request for such a feature.

With `display-buffer-alist' a user can override everything that impedes
her to do something on a lower level (like strongly dedicated windows or
unsplittable frames).  This is part of giving the user special rights
wrt the behavior of `display-buffer'.  I have no problems throwing these
out.  The consequence is, however, that applications have to be more
conservative about using them in order to not step on the users' toes.
With my approach there's always one trivial advice: If you don't like
what I do, you can override it in `display-buffer-alist'.

 >>> I think writing a display-buffer-near-minibuffer function will be
 >>> simpler/cleaner than trying to come up with some clever way to
 >>> combine various specifiers.
 >> Any such function would run into just the same problems as
 >> `special-display-popup-frame'.
 >
 > I do not regard those problems as significant.

I do.  I wouldn't bother otherwise.

 > Look more closely.  It'd be like:
 > - removing same-frame and same-window from special-display-popup-frame.
 > - removing the "ignore the 3rd arg of display-buffer" bug because we
 >   removed that 3rd arg.
 > - removing the "ignore the 2nd arg of display-buffer" bug because we
 >   redefined how it works.

Which is not entirely trivial since we have to pass this as an argument.
If we remove `special-display-function' this might be OK.  Now if we
find someone out there who does we can pass that argument only to
`special-display-popup-frame' ...

 > - at this point special-display-popup-frame is limited to
 >   - reuse a window that shows the given buffer.

As soon as we have resolved the question whether this may reuse a window
on another frame.  Please read the thread mentioned above and consult
with its author if possible.

 >   - otherwise create a new frame with the provided params.
 >   I.e. as clean as it started, trivial to document and code.
 > - then, yes, provide multiple instances of such simple and clean things.

Sounds good.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>> The absurd consequence of this is that with `pop-up-frames' non-nil
>>> `ctl-x-4-map' becomes identical to `ctl-x-5-map' and
>>> `find-file-other-window' an alias for `find-file-other-frame'.  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.
>> This just goes back to the problem of code let-binding pop-up-<foo>
>> instead of providing a SPECIFIER/RULE argument to display-buffer.
> Unfortunately not.  An OTHER-WINDOW argument must sill be interpreted
> consistently with what the user expects.

I don't know what you mean, here.

> The other-window-means-other-frame specifier I use is a gross hack in
> this regard.  I suppose that if I had known about this issue from the
> very beginning, I would never have started to rewrite `display-buffer'
> which would have spared us the present discussion.

I don't know when/why other-window would mean other-frame.

>>> It shouldn't be up to the code to decide whether a window shall be
>>> reused.
>> I already said that same-frame and same-window parameters in
>> special-display-regexps were mistakes, so there's no point complaining much
>> more about their quirks.
> This is not about the same-frame and same-window parameters.  It's about
> the reuse-window-already-showing-the-buffer part.

[TOBEFILLED]

>> I tend to read it in another way: users are not interested in changing
>> this part of the behavior because it's good enough (and also the
>> FUNCTION of special-display-regexps provides the same flexibility, tho
>> in a typically more convenient way).
> OK.  Let's hope that your view is correct.

We can mark special-display-function obsolete right now.

>>> In fact.  Users have to write their own function in order to _avoid_
>>> that `display-buffer' does certain things.  It's precisely this behavior
>>> I wanted to put an end to.
>> If you oppose the FUNCTION hook, then we're in an
>> irreconcilable disagreement.
> Isn't the function specifier of `display-buffer-alist' enough argument
> that I'm in favor of such a hook?  What I said was that users should not
> have to write a function in order to make `display-buffer' _not_ behave
> in a certain way.  They should write functions because that's how they
> want `display-buffer' to behave like.

The difference between the two is only philosophical, from where I stand.

>> I'm not sure why you choose to interpret it as a way to "avoid that
>> display-buffer does certain things" rather than, like any other Emacs
>> hooks, a way to override the default.
> Read for example the posts about `split-window-sensibly' on
> emacs-help.  All people ask for is how to avoid that Emacs splits the
> window horizontally and how to turn it off.  I want a default that
> doesn't provoke users to ask how to turn something off that's bad for
> them.  I want a default that provokes users to ask how to turn
> something on that's good for them.

You're in for a big disappointment, then.  Users, especially in response
to changes, will by and large either be pleased and say nothing or else
ask for "how do I turn this thing off to get back the old behavior".

That has nothing to do with the actual behavior they want or the
behavior they don't want.  It's just how humans work: it's much easier
to see a behavior you don't like and point it out, then to imagine a new
behavior you'd like (and of course, we don't help by forcing users to
report feature requests through M-x report-emacs-bug).

So if you want to avoid questions about how to avoid something or how to
turn it off, your best bet is to revert to the Emacs-23 code.

>> Of course, among all the things you can do with a hook, some of them are
>> to do less than the default.
> Ideally, this should not be necessary.  The default should be the minimum.

While you don't hear them, a majority of users like the new features we
enable in each Emacs release.  So, even if keeping the default
minimalistic would satisfy the few people who complain, it would not
satisfy the silent majority (who otherwise might not even have known
that such a feature could exist).

>> but it's part of the normal experiment/design/experiment/design cycle
>> and it doesn't mean your work was wasted, only that it was
>> instrumental in coming up with the final design, rather than the
>> final code.
> Don't be concerned about this.  The only extra thing I'd ask you to
> spare is the side-window stuff simply because I don't have a better idea
> to ask people to experiment with it.

Sounds good.  Tho, I'd suggest we only document it in the NEWS (and the
docstrings, but not the lispref&manual) and mark it as experimental in
the NEWS.
It looks fairly promising, but I'd like to try and keep it open
for tweaking in the future.

>>>>> The complexity is built into the code of `special-display-popup-frame'.
>>>> I don't find it particularly complex.  It just tries each one of
>>>> the 5 different cases in turn: use FUNCTION,
>>> No.  If it calls FUNCTION it won't try any of the others.
>> If FUNCTION is not provided, it will try the others, so clearly it
>> tries the cases in turn.
> This wasn't my point: If FUNCTION is provided and doesn't produce a
> result, the other cases are ignored.  If any of the others is present
> and doesn't produce a result, the remaining cases are processed.

That's a nitpick.  From where I stand the only problem is that the
docstring does not say what FUNCTION should return.

>> I'm not sure why you're so concerned about this reuse-window behavior of
>> special-display-popup-frame.
> Because I had some very hard time here discussing this with a user who
> can't live with such behavior.

And yet he wants to use dedicated frames?  Can you give some more
details, because that sounds pretty odd.

>> This said, I wonder which systems you're thinking of where "reusing
>> [dedicated] frames doesn't work".  I added [dedicated] since it's 99%
>> sure that the frame is dedicated in the scenario you're talking about.
> The emacs-devel thread is called
> "[display-buffer] a way to make it behave as before?"

I don't understand: this seems to be a discussion about your new code,
not about special-display-popup-frame and its reuse-window behavior.
As a matter of fact he's asking to recover the old behavior.

>> Maybe the issue is that you want to be able to reproduce every detail of
>> the previous behavior in buffer-display-alist, whereas I don't.
> I have to deal with the complaints that something doesn't work as before.

Use the old code whenever possible, rather than trying to reproduce the
old behavior by re-implementing it.

>> No: the whole point of `same-window' was to unify everything into
>> special-display-regexps and make the same-window-* horrors obsolete,
>> just like you're trying to unify everything under buffer-display-alist.

> Ahh ...  yet an another failed attempt to unify things.  Since
> `special-display-regexps' was my reference point for
> `display-buffer-alist' history repeats itself.

The main reason why my attempt failed is because I did not mark
same-window-* as obsolete, and that I didn't mark it as obsolete because
I did not dare to turn the NOT-THIS-WINDOW into a SPECIFIER/RULE
argument which could then make same-window-* really obsolete.

So I think this time around we're in a better position.  But we still
have to take it for granted that the old settings will be with us for
a long time.  All we can do with them is mark them obsolete, provide
similar replacement behavior in the new settings and only use the old
settings by calling the old code which we might even want to move to
lisp/obsolete a some point.

>>>> pop-up-frame.
>>> Which is the original and only reasonable motivation for
>>> `special-display-popup-frame'.
>> The already-displayed is intricately linked to the pop-up-frame because
>> the frame is dedicated.  That's why the already-displayed behavior has
>> been in special-display-popup-frame from the very beginning.
> I don't dispute that all this works for you.  But if we want to
> generalize this concept we have to deal with users who don't want to
> `display-buffer-reuse-frames' and with applications that insist on
> `NOT-THIS-WINDOW'.

In my paper design, the equivalent to the "default
special-display-regexp behavior" (which is the one that includes the
"forcefully reuse-window regardless of display-buffer-reuse-frames")
would be implemented by the display-buffer-dedicated-frame, so (just as
in the original special-display-regexp design) it would only apply to
buffers which are configured to be displayed in dedicated frames.
For those rare users where this is a problem, we can provide some other
function, or some special arg to that function to turn off the "reuse
window" part of the behavior, but that part of the behavior will stay as
the default, because it's the one that makes sense in 99% of the cases.

>>> Why did you have to dedicate the window for this purpose?  If
>>> `pop-up-frames' is non-nil, you get another frame before Emacs even
>>> tries to reuse a window not showing the buffer already.
>> A lot of code uses switch-to-buffer, kill-buffer, bury-buffer, ...
> I lost you here.  If it goes through `display-buffer', all you need is
> `pop-up-frames'.  If it doesn't, `display-buffer-mark-dedicated' won't
> have any effect.

Marking a window dedicated is done in display-buffer but has later on an
effect on what happens in switch-to-buffer, in kill-buffer, in
bury-buffer, ...
I don't set the windows as dedicated to influence display-buffer, but to
influence those other functions.

>>>> It might be an OK replacement for the soft dedication, yes.
>>> Then please try it by using `quit-restore-window' instead of
>>> `quit-window'.
>> I pretty much never use quit-window.
> What do you use then?

I iconify the window, I kill the buffer, I use a command which deletes
the frame and (if it's the last window displaying that buffer) kills the
displayed buffer, I use some other command that ends up calling
kill-buffer or bury-buffer, ...

> With `display-buffer-alist' a user can override everything that
> impedes her to do something on a lower level (like strongly dedicated
> windows or unsplittable frames).  This is part of giving the user
> special rights wrt the behavior of `display-buffer'.  I have no
> problems throwing these out.

Then let's throw them out.

> The consequence is, however, that applications have to be more
> conservative about using them in order to not step on the users' toes.

Not at all: the user can still override them by using the FUNCTION form.
If/when such overrides become common because code starts to use those
things more often, then we can provide the override option in a more
direct way than through FUNCTION, but right now it's not clear it'll
ever be needed.

>> Look more closely.  It'd be like:
>> - removing same-frame and same-window from special-display-popup-frame.
>> - removing the "ignore the 3rd arg of display-buffer" bug because we
>> removed that 3rd arg.
>> - removing the "ignore the 2nd arg of display-buffer" bug because we
>> redefined how it works.
> Which is not entirely trivial since we have to pass this as an argument.
> If we remove `special-display-function' this might be OK.  Now if we
> find someone out there who does we can pass that argument only to
> `special-display-popup-frame' ...

special-display-function is part of the old obsolete interface.  I don't
think we need to worry too much about how it might fail.

>> - at this point special-display-popup-frame is limited to
>>   - reuse a window that shows the given buffer.
> As soon as we have resolved the question whether this may reuse a window
> on another frame.  Please read the thread mentioned above and consult
> with its author if possible.

I don't have time to read the whole thread, but from my cursory look,
I really don't see anything that is a cause for concern since that
"reuse-window" would only be implemented in
special-display-dedicated-frame (which basically be a new name for the
trimmed down special-display-popup-frame).


        Stefan

Re: display-buffer-alist simplifications

[Tim Cross]

On Mon, Aug 8, 2011 at 12:41 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> While you don't hear them, a majority of users like the new features we
> enable in each Emacs release.  So, even if keeping the default
> minimalistic would satisfy the few people who complain, it would not
> satisfy the silent majority (who otherwise might not even have known
> that such a feature could exist).
>

While I agree with much of what you say regarding change and the
associated difficulties that come with it, I think the above is more
wishful thinking than anything else. The silent majority, by
definition, is silent. You do not know whether they liked the change
and cannot assume so. They may like it, they may dislike it, but don't
see any point in saying anything or more likely, are blissfully
unaware anything has changed. To assume the silent majority is in
favour tends to paint those who raise objection as nothing more than a
complaining minority who don't like change. While this may sometimes
be true, it is not always true. Those who dislike the change may
simply be those who are directly affected by it and in fact, may be
the majority who are directly affected. In some cases, change is
justified on the basis that in the long-term it will produce a better
outcome for everyone. However, this does not mean those who seem
resistant can just be ignored as a noisy minority. Those making the
changes need to demonstrate who those affected will have their needs
met and if they won't, why the change will be beneficial, even if
initially accompanied by some discomfort.

On something more specific to display-buffer-alist, I just looked at
the doc string again and either I'm getting use to it, or it has
improved from the last time I tried to digest it. I now *think* I may
understand how to use it (at least for the simple cases where I
need/want to). However, I still think a doc string of over 280 lines
is excessive and wonder if part of the reason people have trouble
understanding it is that there are conflicting objectives in the
string. On one hand, trying to be very concise and on the other,
trying to explain something potentially complex.

Perhaps it would be better to be extremely brief and provide a link to
the relevant section of the elisp reference. Those reading the doc
string who need a quick reference/memory jog will be happy and those
needing more will know they have to follow the link to the reference
and be less likely to believe they really understand the variables
purpose just by the doc string.

Tim

Re: display-buffer-alist simplifications

[martin rudalics]

 >> Unfortunately not.  An OTHER-WINDOW argument must sill be interpreted
 >> consistently with what the user expects.
 >
 > I don't know what you mean, here.

`other-frame' if `pop-up-frames' is non-nil, `same-frame-other-window'
if `pop-up-frames' is nil.

 >> The other-window-means-other-frame specifier I use is a gross hack in
 >> this regard.  I suppose that if I had known about this issue from the
 >> very beginning, I would never have started to rewrite `display-buffer'
 >> which would have spared us the present discussion.
 >
 > I don't know when/why other-window would mean other-frame.

See above, the thread I recommended earlier, and what Drew said in this
thread.

 > We can mark special-display-function obsolete right now.

It was so a couple of weeks ago.

 >> Isn't the function specifier of `display-buffer-alist' enough argument
 >> that I'm in favor of such a hook?  What I said was that users should not
 >> have to write a function in order to make `display-buffer' _not_ behave
 >> in a certain way.  They should write functions because that's how they
 >> want `display-buffer' to behave like.
 >
 > The difference between the two is only philosophical, from where I stand.

It is philosophical from where I stand.  What made you use the term
"only" here?

 >> Read for example the posts about `split-window-sensibly' on
 >> emacs-help.  All people ask for is how to avoid that Emacs splits the
 >> window horizontally and how to turn it off.  I want a default that
 >> doesn't provoke users to ask how to turn something off that's bad for
 >> them.  I want a default that provokes users to ask how to turn
 >> something on that's good for them.
 >
 > You're in for a big disappointment, then.  Users, especially in response
 > to changes, will by and large either be pleased and say nothing or else
 > ask for "how do I turn this thing off to get back the old behavior".

They get the old behavior, presently.  If what you say here were valid,
I'd be pleased if users continued to be pleased and said nothing.

 > That has nothing to do with the actual behavior they want or the
 > behavior they don't want.  It's just how humans work: it's much easier
 > to see a behavior you don't like and point it out, then to imagine a new
 > behavior you'd like (and of course, we don't help by forcing users to
 > report feature requests through M-x report-emacs-bug).
 >
 > So if you want to avoid questions about how to avoid something or how to
 > turn it off, your best bet is to revert to the Emacs-23 code.

Not really.  The questions are still raised for Emacs-23.

 > While you don't hear them, a majority of users like the new features we
 > enable in each Emacs release.  So, even if keeping the default
 > minimalistic would satisfy the few people who complain, it would not
 > satisfy the silent majority (who otherwise might not even have known
 > that such a feature could exist).

That's precisely what distinguishes the philosophy of a maintainer from
that of a person who just happens to contribute code.  The former has to
make and deal with compromises.  I don't envy you for that.

 >> Don't be concerned about this.  The only extra thing I'd ask you to
 >> spare is the side-window stuff simply because I don't have a better idea
 >> to ask people to experiment with it.
 >
 > Sounds good.  Tho, I'd suggest we only document it in the NEWS (and the
 > docstrings, but not the lispref&manual) and mark it as experimental in
 > the NEWS.
 > It looks fairly promising, but I'd like to try and keep it open
 > for tweaking in the future.

OK.

 >>> I'm not sure why you're so concerned about this reuse-window behavior of
 >>> special-display-popup-frame.
 >> Because I had some very hard time here discussing this with a user who
 >> can't live with such behavior.
 >
 > And yet he wants to use dedicated frames?  Can you give some more
 > details, because that sounds pretty odd.

That person can't use `special-display-popup-frame' because it doesn't
work correctly on his system.  Drew uses `special-display-popup-frame'
without dedicating frames IIRC.  The only person insisting on the
dedicated feature is you.  And you still didn't give me an answer why
you need it.

 >> The emacs-devel thread is called
 >> "[display-buffer] a way to make it behave as before?"
 >
 > I don't understand: this seems to be a discussion about your new code,
 > not about special-display-popup-frame and its reuse-window behavior.
 > As a matter of fact he's asking to recover the old behavior.

It's about the reuse-window behavior in general.  The one of
`special-display-popup-frame' is a special case.

 > Use the old code whenever possible, rather than trying to reproduce the
 > old behavior by re-implementing it.

The old code is inherently tied to rebinding variables around
`display-buffer' calls.  We wanted to replace the rebindings with an
argument.

 > The main reason why my attempt failed is because I did not mark
 > same-window-* as obsolete, and that I didn't mark it as obsolete because
 > I did not dare to turn the NOT-THIS-WINDOW into a SPECIFIER/RULE
 > argument which could then make same-window-* really obsolete.
 >
 > So I think this time around we're in a better position.  But we still
 > have to take it for granted that the old settings will be with us for
 > a long time.  All we can do with them is mark them obsolete, provide
 > similar replacement behavior in the new settings and only use the old
 > settings by calling the old code which we might even want to move to
 > lisp/obsolete a some point.

Sure.  But using the old code _as is_ is impossible if you want "to turn
the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make
same-window-* really obsolete".

 > In my paper design, the equivalent to the "default
 > special-display-regexp behavior" (which is the one that includes the
 > "forcefully reuse-window regardless of display-buffer-reuse-frames")
 > would be implemented by the display-buffer-dedicated-frame, so (just as
 > in the original special-display-regexp design) it would only apply to
 > buffers which are configured to be displayed in dedicated frames.

And I'm still asking why frames must be dedicated.  It's just as if you
wanted to reperesent one of those users who want the old behavior back.
What would happen in your setup if a frame were not dedicated?

 > For those rare users where this is a problem, we can provide some other
 > function, or some special arg to that function to turn off the "reuse
 > window" part of the behavior, but that part of the behavior will stay as
 > the default, because it's the one that makes sense in 99% of the cases.

In 100% of the cases because this function is not useful for people who
can't reuse a window on another frames.

 > Marking a window dedicated is done in display-buffer but has later on an
 > effect on what happens in switch-to-buffer, in kill-buffer, in
 > bury-buffer, ...
 > I don't set the windows as dedicated to influence display-buffer, but to
 > influence those other functions.

Unfortunately so.  Suppose you removed the dedicatedness setting from
`special-display-popup-frame' for a moment and told me about the ensuing
disasters.

 >>> I pretty much never use quit-window.
 >> What do you use then?
 >
 > I iconify the window, I kill the buffer, I use a command which deletes
 > the frame and (if it's the last window displaying that buffer) kills the
 > displayed buffer, I use some other command that ends up calling
 > kill-buffer or bury-buffer, ...

Fine.  All these should work with the quit-restore window parameter.
And as a plus you should get it right when you just reused a window
showing another buffer on the same frame.  If any of these doesn't work
please complain.  I intended this as one of the features the majority
could like ...

martin

RE: display-buffer-alist simplifications

[Drew Adams]

>  >>> I'm not sure why you're so concerned about this 
>  >>> reuse-window behavior of special-display-popup-frame.
>  >>
>  >> Because I had some very hard time here discussing this 
>  >> with a user who can't live with such behavior.
>  >
>  > And yet he wants to use dedicated frames?  Can you give some more
>  > details, because that sounds pretty odd.
> 
> That person can't use `special-display-popup-frame' because it doesn't
> work correctly on his system.  Drew uses `special-display-popup-frame'
> without dedicating frames IIRC.  The only person insisting on the
> dedicated feature is you.  And you still didn't give me an answer why
> you need it.

I'm not following this too well; sorry.

Not sure what you mean by Drew not dedicating frames, in the context of
`special-display-popup-frame'.  I thought special-display buffers were always,
by default, displayed in dedicated windows.  AFAIK, I don't change that default
behavior.  And I do want all of my special-display windows/frames to be
dedicated.

I use `special-display-buffer-names' for two particular buffers (*Help*,
*Completions*).  In addition, I have `special-display-regexps' set to ("[
]?[*][^*]+[*]"), so buffers named *...* are all special-display.  Their
windows/frames are always dedicated.

Maybe what you meant was not in the context of special display?  It is true that
for ordinary (non special-display) buffers I do not use dedicated
windows/frames.  (IIUC, that is different from what Stefan does.)

(Ignore if this reply isn't helpful - I'm not sure I understand what's being
discussed here.  Just trying to clarify what I do in my code.)

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> We can mark special-display-function obsolete right now.
> It was so a couple of weeks ago.

Yes, and I asked you to remove the obsolete signs, but now I realize
that the one for special-display-function should have stayed.

>>>> I'm not sure why you're so concerned about this reuse-window behavior of
>>>> special-display-popup-frame.
>>> Because I had some very hard time here discussing this with a user who
>>> can't live with such behavior.
>> And yet he wants to use dedicated frames?  Can you give some more
>> details, because that sounds pretty odd.
> That person can't use `special-display-popup-frame' because it doesn't
> work correctly on his system.

Again, I don't know where in that thread he says that nor why.
All I saw was requests to get back the Emacs-23 behavior (tho I don't
really understand what was different there either).

> Drew uses `special-display-popup-frame' without dedicating frames IIRC.

I don't think so.

> The only person insisting on the dedicated feature is you.
> And you still didn't give me an answer why you need it.

I did: so that kill-buffer, bury-buffer, switch-to-buffer, and friends
"do the right thing" (i.e. prefer to delete or iconify the window, or
use some other frame, rather than show me some unrelated buffer in the
selected window).
And also so that display-buffer doesn't reuse that window.

>>> The emacs-devel thread is called
>>> "[display-buffer] a way to make it behave as before?"
>> I don't understand: this seems to be a discussion about your new code,
>> not about special-display-popup-frame and its reuse-window behavior.
>> As a matter of fact he's asking to recover the old behavior.
> It's about the reuse-window behavior in general.  The one of
> `special-display-popup-frame' is a special case.

Than I'm lost.  Not sure if it matters, tho.

>> So I think this time around we're in a better position.  But we still
>> have to take it for granted that the old settings will be with us for
>> a long time.  All we can do with them is mark them obsolete, provide
>> similar replacement behavior in the new settings and only use the old
>> settings by calling the old code which we might even want to move to
>> lisp/obsolete a some point.
> Sure.  But using the old code _as is_ is impossible if you want "to turn
> the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make
> same-window-* really obsolete".

Maybe not absolutely "as is", but it should be possible to keep most of
the code unchanged, I think.

>> In my paper design, the equivalent to the "default
>> special-display-regexp behavior" (which is the one that includes the
>> "forcefully reuse-window regardless of display-buffer-reuse-frames")
>> would be implemented by the display-buffer-dedicated-frame, so (just as
>> in the original special-display-regexp design) it would only apply to
>> buffers which are configured to be displayed in dedicated frames.
> And I'm still asking why frames must be dedicated.

They don't.  But based on the fact that `same-frame' and `same-window'
params only appeared "recently" and that FUNCTION is only used by
a minority of users, then the vast majority of users of
special-display-regexps use it to get dedicated frames.

Now maybe they don't really want dedicated frames, they just want some
way to say that some special buffers should be displayed in some
separate frame, but since Emacs-20 this has made those windows/frames
dedicated (and it made the code reuse any existing window) without
hearing too many complaints about it.

So I think it's a useful feature which we will want to provide through
something like display-buffer-dedicated-frame which users will be free
to use or not.

> It's just as if you wanted to reperesent one of those users who want
> the old behavior back.  What would happen in your setup if a frame
> were not dedicated?

It all depends, but when your code recently failed to mark windows as
dedicated, I pretty quickly noticed it because I ended up accumulating
lots of frames showing the same buffer (often a buffer I didn't even
ask to see).

>> I iconify the window, I kill the buffer, I use a command which deletes
>> the frame and (if it's the last window displaying that buffer) kills the
>> displayed buffer, I use some other command that ends up calling
>> kill-buffer or bury-buffer, ...
> Fine.  All these should work with the quit-restore window parameter.

Oh, that's nice.

> And as a plus you should get it right when you just reused a window
> showing another buffer on the same frame.  If any of these doesn't work
> please complain.

It'll take me a while to change my setup to avoid dedicating windows, so
don't hold your breath,


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >>>>> I'm not sure why you're so concerned about this reuse-window behavior of
 >>>>> special-display-popup-frame.
 >>>> Because I had some very hard time here discussing this with a user who
 >>>> can't live with such behavior.
 >>> And yet he wants to use dedicated frames?  Can you give some more
 >>> details, because that sounds pretty odd.
 >> That person can't use `special-display-popup-frame' because it doesn't
 >> work correctly on his system.
 >
 > Again, I don't know where in that thread he says that nor why.

The author said

 > > The main reason I want to do all within the current frame is because
 > > Emacs doesn't raise a hidden frame.  On cygwin (I use it in the office)
 > > and on Fedora 14 Linux (I use it in home), Emacs puts a newly created
 > > frame on the top of the screen, but it doesn't for a frame that exists
 > > but is hidden.
 > >
 > > As for Fedora 14, I use an external program called `wmctrl' to make
 > > `raise-frame' work, but it has no effect on cygwin.  Cf.
 > > http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg01117.html

 > All I saw was requests to get back the Emacs-23 behavior (tho I don't
 > really understand what was different there either).

The difference was that I interpreted `pop-up-frames' non-nil as the
user's agreement to reuse a window on another frame.  The same
interpretation is implicit whenever a user adds a buffer to
`special-display-regexps' making `special-display-popup-frame' search
all visible frames.

 >> Sure.  But using the old code _as is_ is impossible if you want "to turn
 >> the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make
 >> same-window-* really obsolete".
 >
 > Maybe not absolutely "as is", but it should be possible to keep most of
 > the code unchanged, I think.

For some value of "most".

 >> It's just as if you wanted to reperesent one of those users who want
 >> the old behavior back.  What would happen in your setup if a frame
 >> were not dedicated?
 >
 > It all depends, but when your code recently failed to mark windows as
 > dedicated, I pretty quickly noticed it because I ended up accumulating
 > lots of frames showing the same buffer (often a buffer I didn't even
 > ask to see).

IIUC, dedicated frames make sense in one and only one constellation:

(1) `pop-up-frames' is nil.

(2) Not all windows get a special frame.

(3) You are in a special frame and a `display-buffer' for some other
     buffer than the one shown there happens.

This is the only scenario I can think of that should cause troubles when
the frame of (3) is not dedicated.  But the buffer shown instead should
be a buffer the user asked to see.  So what you report above indicates
the existence of a bug elsewhere.  As soon as you have the time please
look into this again and report such behavior.

 > It'll take me a while to change my setup to avoid dedicating windows, so
 > don't hold your breath,

There's one thing that won't work for you: `bury-buffer' doesn't iconify
the frame but deletes it.  Iconification would need some extra work.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

> The difference was that I interpreted `pop-up-frames' non-nil as the
> user's agreement to reuse a window on another frame.  The same
> interpretation is implicit whenever a user adds a buffer to
> `special-display-regexps' making `special-display-popup-frame' search
> all visible frames.

For special-display-regexps it makes sense because those frames are
marked dedicated.
This said, his case is pretty unusual, AFAIK, so I'm not too worried
about it: as long as the new setup lets him specify explicitly that he
wants this, it's OK if the default does something else.

>> It'll take me a while to change my setup to avoid dedicating windows, so
>> don't hold your breath,
> There's one thing that won't work for you: `bury-buffer' doesn't iconify
> the frame but deletes it.

I'd hate that (at least as much as Drew hates iconification).

> Iconification would need some extra work.

Hopefully I'll be up to it.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >> There's one thing that won't work for you: `bury-buffer' doesn't iconify
 >> the frame but deletes it.
 >
 > I'd hate that (at least as much as Drew hates iconification).

Both, deletion+recreation and iconification/deiconification have their
pros and cons.  We should provide both.

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

> What problems do you guys (fore)see with such a setup?

Let's see how such a setup serves some specific test-cases:

1. The user should be able to specify whether to display the buffer
in the same window or in another window and which window
to select after displaying the buffer in another window.

Currently these differences are encoded in function names:

  `switch-to-buffer' - display buffer in the selected window
  `pop-to-buffer' - display buffer and select its window
  `display-buffer' - display buffer, but don't select its window

and they are used quite inconsistently in applications.
For instance, to display the "*vc-diff*" buffer,
`vc-diff-internal' calls (pop-to-buffer "*vc-diff*"),
but `vc-annotate-show-diff-revision-at-line-internal'
calls (switch-to-buffer "*vc-diff*").

How the user can override these application defaults?

To display the "*vc-diff*" buffer in the selected window
(like `switch-to-buffer'):

  (setq display-buffer-alist '(
    ("*vc-diff*" display-buffer-same-window)))

To display the "*vc-diff*" buffer and not select its window:

  (setq display-buffer-alist '(
    ("*vc-diff*" display-buffer-other-window)))

To display the "*vc-diff*" buffer and select its window
(like `pop-to-buffer'):

  (setq display-buffer-alist '(
    ("*vc-diff*" display-buffer-pop-to-buffer)))

2. How the user can override the global defaults?

For instance, I want to display the *Help* buffer in the selected window.
But when it's already displayed in another window, then prefer reusing
another window (because otherwise two windows will be displayed with the
same buffer).  And not reuse a window on another frame.

Should I write a new function and use it like:

  (setq display-buffer-alist '(
    ("*Help*" display-buffer-other-window-same-frame-or-same-window)))

Or provide additional arguments to the predefined functions like:

  (setq display-buffer-alist '(
    ("*Help*" display-buffer-same-window reuse-other-window-same-frame)))

Or

  (setq display-buffer-alist '(
    ("*Help*" display-buffer-same-window (reuse-window . same-frame))))

3. How applications can override the global default?

For instance, what to do to fit the command `info-other-window':

  (defun info-other-window (&optional file-or-node)
    "Like `info' but show the Info buffer in another window."
    (interactive (if current-prefix-arg
                     (list (read-file-name "Info file name: " nil nil t))))
    (let (same-window-buffer-names same-window-regexps (pop-up-windows t))
      (info file-or-node)))

info the new setup?  Maybe something like this:

(defalias 'info-other-window 'info)

;;;###autoload (add-hook 'display-buffer-alist
;;;###autoload           '(info-check-command-name display-buffer-pop-to-buffer))

(defun info-check-command-name (buffer-name)
  (and (eq this-command 'info-other-window)
       (string-match-p "\\*info\\*\\(\\|<[0-9]+>\\)" buffer-name)))

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> What problems do you guys (fore)see with such a setup?
> Let's see how such a setup serves some specific test-cases:
> 1. The user should be able to specify whether to display the buffer
> in the same window or in another window and which window
> to select after displaying the buffer in another window.

Hmm... please use your words carefully.  I recommend you use "user" for
the guy who sets up buffer-display-alist (via Customize) and "caller" for
the guys who write the code that calls display-buffer.

> Currently these differences are encoded in function names:

>   `switch-to-buffer' - display buffer in the selected window
>   `pop-to-buffer' - display buffer and select its window
>   `display-buffer' - display buffer, but don't select its window

pop-to-buffer just calls display-buffer and then selects the chosen
window, so it's can be ignored.

switch-to-buffer would either use set-window-buffer (and circumvent the
whole display-buffer business) or call pop-to-buffer with
a '(display-buffer-same-window) RULE argument, which can then be
overridden by buffer-display-alist.

> and they are used quite inconsistently in applications.

And there's not much we can do about it, other than try and provide good
new functionality to encourage coders to do it better in the future.

> For instance, to display the "*vc-diff*" buffer,
> `vc-diff-internal' calls (pop-to-buffer "*vc-diff*"),
> but `vc-annotate-show-diff-revision-at-line-internal'
> calls (switch-to-buffer "*vc-diff*").

> How the user can override these application defaults?

All those cases can be overridden by buffer-display-alist.

> To display the "*vc-diff*" buffer in the selected window
> (like `switch-to-buffer'):

>   (setq display-buffer-alist '(
>     ("*vc-diff*" display-buffer-same-window)))

> To display the "*vc-diff*" buffer and not select its window:

>   (setq display-buffer-alist '(
>     ("*vc-diff*" display-buffer-other-window)))

Ah, so your point is that the user should also have control over the
window selection? I think this is outside the scope of the current
design (changing the selected window returned by switch-to-buffer,
pop-to-buffer, and display-buffer would break too much code).

So the same-window vs other-window controls where the buffer is
displayed but not which window ends up selected in the end.

> 2. How the user can override the global defaults?

> For instance, I want to display the *Help* buffer in the selected window.
> But when it's already displayed in another window, then prefer reusing
> another window (because otherwise two windows will be displayed with the
> same buffer).  And not reuse a window on another frame.

> Should I write a new function and use it like:

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-other-window-same-frame-or-same-window)))

Yes, I think that would be the answer.

> Or provide additional arguments to the predefined functions like:

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-same-window reuse-other-window-same-frame)))

> Or

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-same-window (reuse-window . same-frame))))

We could provide a fancy-display.el package defining a magical
display-buffer-according-to-specifiers which would interpret its
parameters in a similar way to what is now done in Martin's
buffer-display-alist.

> 3. How applications can override the global default?

> For instance, what to do to fit the command `info-other-window':

>   (defun info-other-window (&optional file-or-node)
>     "Like `info' but show the Info buffer in another window."
>     (interactive (if current-prefix-arg
>                      (list (read-file-name "Info file name: " nil nil t))))
>     (let (same-window-buffer-names same-window-regexps (pop-up-windows t))
>       (info file-or-node)))

> into the new setup?

This question is orthogonal to the current debate about how to
streamline buffer-display-alist, I think.  But I think the answer would
be to provide an `info-internal' function which takes a DISPLAY-RULE
param and then rewrite `info' and `info-other-window' in terms of that
new function.

I know this won't satisfy everyone, but let-binding as is done above has
too many problems of its own.  Maybe we could have a new
display-buffer-default-rule variable (not a user option) such that
display-buffer uses this variable when its RULE arg is nil, so
info-other-window could do

  (let ((display-buffer-default-rule '(display-buffer-other-window)))
    (info ...))

A related issue: I tend to dislike the *-other-(frame|window) commands
and would rather have C-x 4 and C-x 5 as prefix commands that modify the
way the subsequent command works.  Not sure how best to get this behavior.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

> display-buffer-according-to-specifiers which would interpret its
> parameters in a similar way to what is now done in Martin's
> buffer-display-alist.

I expect this eventually will turn `display-buffer-alist' into

  (("\\*\\(vc-\\)?diff*"
    display-buffer-according-to-specifiers (spec . val))
   ("\\*\\(compilation\\|grep\\)\\*"
    display-buffer-according-to-specifiers (spec . val))
   ...)

because predefined spec values are easier to customize.

> I know this won't satisfy everyone, but let-binding as is done above has
> too many problems of its own.  Maybe we could have a new
> display-buffer-default-rule variable (not a user option) such that
> display-buffer uses this variable when its RULE arg is nil, so
> info-other-window could do
>
>   (let ((display-buffer-default-rule '(display-buffer-other-window)))
>     (info ...))

Yes, a single variable would be enough to override the display-buffer's arg
(maybe a better name would be `display-buffer-specifiers').

> A related issue: I tend to dislike the *-other-(frame|window) commands
> and would rather have C-x 4 and C-x 5 as prefix commands that modify the
> way the subsequent command works.  Not sure how best to get this behavior.

Then for completeness there should be a key prefix to force displaying the
buffer in the same window (when the default behavior is to display it
in another window).

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> display-buffer-according-to-specifiers which would interpret its
>> parameters in a similar way to what is now done in Martin's
>> buffer-display-alist.

> I expect this eventually will turn `display-buffer-alist' into

>   (("\\*\\(vc-\\)?diff*"
>     display-buffer-according-to-specifiers (spec . val))
>    ("\\*\\(compilation\\|grep\\)\\*"
>     display-buffer-according-to-specifiers (spec . val))
>    ...)

> because predefined spec values are easier to customize.

Easier than what?

>> I know this won't satisfy everyone, but let-binding as is done above has
>> too many problems of its own.  Maybe we could have a new
>> display-buffer-default-rule variable (not a user option) such that
>> display-buffer uses this variable when its RULE arg is nil, so
>> info-other-window could do
>> 
>> (let ((display-buffer-default-rule '(display-buffer-other-window)))
>> (info ...))
> Yes, a single variable would be enough to override the display-buffer's arg
> (maybe a better name would be `display-buffer-specifiers').

In my proposal, these things are called "rule", where RULE has the form
(FUNCTION . ARGS).

>> A related issue: I tend to dislike the *-other-(frame|window) commands
>> and would rather have C-x 4 and C-x 5 as prefix commands that modify the
>> way the subsequent command works.  Not sure how best to get this behavior.
> Then for completeness there should be a key prefix to force displaying the
> buffer in the same window (when the default behavior is to display it
> in another window).

Great minds think alike,


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

> You can already do that since Emacs-20 by setting special-display-regexp
> to something like
>
>   (add-to-list 'special-display-regexps
>                '("\\*Completions\\*" my-display-completions))
>
> Tho I haven't seen any sample "my-display-completions" yet.

A possible explanation is that users don't like to write functions
to specify buffer-displaying behavior :)

>> I expect this eventually will turn `display-buffer-alist' into
>
>>   (("\\*\\(vc-\\)?diff*"
>>     display-buffer-according-to-specifiers (spec . val))
>>    ("\\*\\(compilation\\|grep\\)\\*"
>>     display-buffer-according-to-specifiers (spec . val))
>>    ...)
>
>> because predefined spec values are easier to customize.
>
> Easier than what?

Selecting from the set of predefined values is easier than
writing a new function to customize the buffer-displaying behavior.

>> Yes, a single variable would be enough to override the display-buffer's arg
>> (maybe a better name would be `display-buffer-specifiers').
>
> In my proposal, these things are called "rule", where RULE has the form
> (FUNCTION . ARGS).

In classical logic, necessary part of "rule" is "condition".
So "rule" is rather such an element if `display-buffer-alist':

  ("*Completions*" display-buffer-according-to-specifiers (spec . val))

But since "condition" part is unnecessary in the call of `display-buffer',
what remains is just specifiers.

According to your earlier proposals such specifiers should be
as short as possible like:

  (display-buffer buffer 'same-frame)
  (display-buffer buffer 'same-window)
  (display-buffer buffer 'other-window)
  (display-buffer buffer 'nearby)
  (display-buffer buffer 'near-minibuffer)
  (display-buffer buffer 'below-selected)
  (display-buffer buffer 'side-window)

But now you propose to use function names. So it seems that instead of

  (display-buffer buffer 'reuse-window)
  (display-buffer buffer 'pop-up-window)

using function names as an argument of `display-buffer'
would look very weird:

  (display-buffer buffer 'display-buffer-reuse-window)
  (display-buffer buffer 'display-buffer-pop-up-window)

It will cause the callers to ask the questions like
why this can't be written simply as:

  (display-buffer-reuse-window buffer)
  (display-buffer-pop-up-window buffer)

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> You can already do that since Emacs-20 by setting special-display-regexp
>> to something like
>> (add-to-list 'special-display-regexps
>> '("\\*Completions\\*" my-display-completions))
>> Tho I haven't seen any sample "my-display-completions" yet.
> A possible explanation is that users don't like to write functions
> to specify buffer-displaying behavior :)

Most likely, especially functions such as the my-display-completions you
described, which is pretty difficult to write.

>>> I expect this eventually will turn `display-buffer-alist' into
>> 
>>> (("\\*\\(vc-\\)?diff*"
>>> display-buffer-according-to-specifiers (spec . val))
>>> ("\\*\\(compilation\\|grep\\)\\*"
>>> display-buffer-according-to-specifiers (spec . val))
>>> ...)
>> 
>>> because predefined spec values are easier to customize.
>> Easier than what?
> Selecting from the set of predefined values is easier than
> writing a new function to customize the buffer-displaying behavior.

My proposal to only use FUNCTION in the API does not mean we wouldn't
provide a choice of alternatives in the Custom UI.  I fully intend to
have the same kind of "select behavior from a set of predefined values"
as we have now.  It's just that the values you choose are functions, so
while the :tag may say "same frame" the value will be the
`display-buffer-same-frame' function rather than a `same-frame' symbol.
And in the docstring of buffer-display-alist we would include links to
those predefined functions.
And the args to those function would still be your usual ALISTs with
symbols as keys.

>>> Yes, a single variable would be enough to override the display-buffer's arg
>>> (maybe a better name would be `display-buffer-specifiers').
>> In my proposal, these things are called "rule", where RULE has the form
>> (FUNCTION . ARGS).
> In classical logic, necessary part of "rule" is "condition".

I don't care about which name is used.  I didn't choose SPECIFIER
because that's already used in this discussion for the same purpose but
with a different representation and the whole point of this discussion
is to figure out which representation to use.

> So "rule" is rather such an element if `display-buffer-alist':
>   ("*Completions*" display-buffer-according-to-specifiers (spec . val))
> But since "condition" part is unnecessary in the call of `display-buffer',
> what remains is just specifiers.

My suggestion was to have display-buffer-alist be a list of (CONDITION
. RULE).  If you don't like those names, then please read my messages
through a transcriptor.  I don't think "RULE" appeared with any other
meaning within this thread, so the transcription is unambiguous.

> According to your earlier proposals such specifiers should be
> as short as possible like:

>   (display-buffer buffer 'same-frame)
>   (display-buffer buffer 'same-window)
>   (display-buffer buffer 'other-window)
>   (display-buffer buffer 'nearby)
>   (display-buffer buffer 'near-minibuffer)
>   (display-buffer buffer 'below-selected)
>   (display-buffer buffer 'side-window)

I don't know if I was worried about size, but right now I'm not too
worried about size, no.

> It will cause the callers to ask the questions like
> why this can't be written simply as:

>   (display-buffer-reuse-window buffer)
>   (display-buffer-pop-up-window buffer)

Easy: so display-buffer-alist may override it.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

>>> In my proposal, these things are called "rule", where RULE has the form
>>> (FUNCTION . ARGS).
>> In classical logic, necessary part of "rule" is "condition".
>
> I don't care about which name is used.  I didn't choose SPECIFIER
> because that's already used in this discussion for the same purpose but
> with a different representation and the whole point of this discussion
> is to figure out which representation to use.

I agree that SPECIFIER doesn't say that it's a function call.
Actually in logic, second part of the rule is called ACTION.
Moreover, a function call is a typical case of ACTION.

So let's be clear in the terminology from the beginning
to avoid the mess and misunderstandings later:

  RULE   ::= (CONDITION . ACTION)
  ACTION ::= (FUNCTION . ARGS)

> My suggestion was to have display-buffer-alist be a list of
> (CONDITION . RULE).

Sorry, it hurts my brains to read (CONDITION . RULE).  When I try to
expand RULE whose first part should be CONDITION according to its
classical definition, with (CONDITION . (CONDITION . (CONDITION . ...)))
I'm going into infinite recursion :)

>>   (display-buffer buffer 'same-frame)
>>   (display-buffer buffer 'same-window)
>>   (display-buffer buffer 'other-window)
>>   (display-buffer buffer 'nearby)
>>   (display-buffer buffer 'near-minibuffer)
>>   (display-buffer buffer 'below-selected)
>>   (display-buffer buffer 'side-window)
>
> I don't know if I was worried about size, but right now I'm not too
> worried about size, no.

I'm worried about size, but with your design this problem could be later
mitigated with something like this in `display-buffer':

  (let ((function (intern (format "display-buffer-%s" (car specifiers)))))
    (if (functionp function)
        (apply function args)))

Re: display-buffer-alist simplifications

[Stefan Monnier]

> I agree that SPECIFIER doesn't say that it's a function call.
> Actually in logic, second part of the rule is called ACTION.

In my world, none of the logics we use has such "actions", but I can
definitely live with ACTION instead of RULE.

> I'm worried about size, but with your design this problem could be later
> mitigated with something like this in `display-buffer':

>   (let ((function (intern (format "display-buffer-%s" (car specifiers)))))
>     (if (functionp function)
>         (apply function args)))

Yuck!


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > Most likely, especially functions such as the my-display-completions you
 > described, which is pretty difficult to write.

What's so difficult about it?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> Most likely, especially functions such as the my-display-completions you
>> described, which is pretty difficult to write.
> What's so difficult about it?

As you pointed out, creating a full-width bottom window in any Emacs
other than the very latest, can be somewhere between tricky
and impossible.


        Stefan

Re: display-buffer-alist simplifications

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Should I write a new function and use it like:
>
>>   (setq display-buffer-alist '(
>>     ("*Help*" display-buffer-other-window-same-frame-or-same-window)))
>
> Yes, I think that would be the answer.

Except that this should be a list of rules, because you don't want to
force users to define a new function each time they want to "chain" two
rules together.  So this becomes

  (setq display-buffer-alist
    '(("*Help*" rule-1 rule-2)))

But if you want to be able to pass extra parameters to the rule
functions (so that you don't have to define a new function for every
combination of window-choosing behaviors), you can generalize this to
something like

  (setq display-buffer-alist
    '(("*Help*" (rules rule-1 rule-2)
                (param-1 foo)
                (param-2 bar))))

which is basically the same scheme I suggested earlier.

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>> Should I write a new function and use it like:
>>> (setq display-buffer-alist '(
>>> ("*Help*" display-buffer-other-window-same-frame-or-same-window)))
>> Yes, I think that would be the answer.
> Except that this should be a list of rules, because you don't want to
> force users to define a new function each time they want to "chain" two
> rules together.

I don't know how important it is in practice.

>   (setq display-buffer-alist
>     '(("*Help*" (rules rule-1 rule-2)
>                 (param-1 foo)
>                 (param-2 bar))))

So you're suggesting I extend my scheme from

   display-buffer-alist ::= list of (CONDITION . RULE)
   RULE                 ::= (FUNCTION . ALIST)
to
   display-buffer-alist ::= list of (CONDITION . RULE)
   RULE                 ::= (FUNCTIONS . ALIST)
   FUNCTIONS            ::= list of FUNCTION

so you'd run it as (run-hook-with-args-until-success FUNCTION BUFFER ALIST)?
And we could accept a single function for FUNCTIONS (i.e. allow both of
the above forms).

That's still fairly simple and clean, so I'm OK with it, although
it may impact the choice of predefined functions we provide in a way
that will make it more complicated for the user to setup (rather than
just display-buffer-same-window, she may have to choose a list of
functions, specifying explicitly what to do when same-window doesn't
work).

But I guess it would let us form both FUNCTIONS and ALIST by
concatenating the various FUNCTIONS and ALIST provided by the default,
the caller, the user, and any potential override.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

> So you're suggesting I extend my scheme from
>
>    display-buffer-alist ::= list of (CONDITION . RULE)
>    RULE                 ::= (FUNCTION . ALIST)
> to
>    display-buffer-alist ::= list of (CONDITION . RULE)
>    RULE                 ::= (FUNCTIONS . ALIST)
>    FUNCTIONS            ::= list of FUNCTION
>
> so you'd run it as (run-hook-with-args-until-success FUNCTION BUFFER ALIST)?
> And we could accept a single function for FUNCTIONS (i.e. allow both of
> the above forms).
>
> That's still fairly simple and clean, so I'm OK with it, although
> it may impact the choice of predefined functions we provide in a way
> that will make it more complicated for the user to setup (rather than
> just display-buffer-same-window, she may have to choose a list of
> functions, specifying explicitly what to do when same-window doesn't
> work).
>
> But I guess it would let us form both FUNCTIONS and ALIST by
> concatenating the various FUNCTIONS and ALIST provided by the default,
> the caller, the user, and any potential override.

I think it would be good to implement this powerful and flexible scheme
(modulo terminology :)

Re: display-buffer-alist simplifications

[martin rudalics]

 >    It would be cleaner to use a
 >    plist, like this:
 >
 >     (reuse-window :window same :reuse-window-even-sizes t)
 >
 >    where ALL the behaviors are grouped together.

With the current `display-buffer-alist' writing

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window nil same)
     (reuse-window other)
     (reuse-window-even-sizes . t))))

means to (1) try finding any window on the selected frame that shows the
buffer already, or (2) reuse any but the selected window on the selected
frame, evening out window sizes in both cases, if applicable.

A naive rewrite of this specifier according to your proposal would yield

(setq
  display-buffer-alist
  '(".*"
    (reuse-window :buffer same)
    (reuse-window :window other)
    (reuse-window :even-sizes t)))

The problem here is that the (reuse-window :window other) specifier
would change the semantics of the (reuse-window :buffer same) specifier
to _not reuse_ the selected window even if it shows the buffer.  Hence
the entry is not semantically equivalent to the former one.

There are various ways to achieve equivalence, neither of them entirely
satisfactory:

(1) Use a list as value for the method specifier similar to the
     current approach, for example

(setq
  display-buffer-alist
  '(".*"
    (reuse-window :which '(nil same))
    (reuse-window :which '(other))
    (reuse-window :even-sizes t)))


(2) Require that an entry for :window is present for any reuse-window
     method specifier, so we'd have to write

(setq
  display-buffer-alist
  '(".*"
    (reuse-window :window nil :buffer same :frame nil)
    (reuse-window :window other :buffer nil :frame nil)
    (reuse-window :even-sizes t)))


(3) Disallow lookup for further occurrences of the same specifier.
     This implies that we'd have to write

(setq
  display-buffer-alist
  '(".*"
    (reuse-window :buffer same :even-sizes t)
    (reuse-window :window other :even-sizes t)))

Which one would you prefer?  Any other suggestions?

martin

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> Date: Sat, 23 Jul 2011 09:56:45 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> (setq
>   display-buffer-alist
>   '((((regexp . ".*"))
>      (reuse-window nil same)
>      (reuse-window other)
>      (reuse-window-even-sizes . t))))
> [...]
> (setq
>   display-buffer-alist
>   '(".*"
>     (reuse-window :buffer same)
>     (reuse-window :window other)
>     (reuse-window :even-sizes t)))
> [...]
> (setq
>   display-buffer-alist
>   '(".*"
>     (reuse-window :which '(nil same))
>     (reuse-window :which '(other))
>     (reuse-window :even-sizes t)))
> [...]
> (setq
>   display-buffer-alist
>   '(".*"
>     (reuse-window :window nil :buffer same :frame nil)
>     (reuse-window :window other :buffer nil :frame nil)
>     (reuse-window :even-sizes t)))
> [...]
> (setq
>   display-buffer-alist
>   '(".*"
>     (reuse-window :buffer same :even-sizes t)
>     (reuse-window :window other :even-sizes t)))

A comment from a naive bystander: these values are getting more and
more close to Lisp code than to a value of a user variable.  Aren't we
burdening users with too much Lisp-like structures for options that
are supposed to be easily customizable by people who don't know Lisp?
I mean, using a single level of parentheses around some list, or the
`setq' syntax, is one thing -- users can still form some simple mental
model of that which doesn't require understanding of Lisp.  But the
above is something else: they are nested, with some lists requiring
'() quoting, others not, some members use `:', others don't, some are
cons cells, others lists; etc.

If we cannot find a simpler syntax, perhaps we should provide an
interactive function for customizing display-buffer's behavior, some
kind of wizard that would lead the user through a series of questions
with detailed description of the result of each setting, and in the
end generate the value needed for the user-specified behavior.  (The
series of questions could be expressed as a nifty GUI dialog with
check-boxes in GUI sessions.)

Re: display-buffer-alist simplifications

[martin rudalics]

 > A comment from a naive bystander: these values are getting more and
 > more close to Lisp code than to a value of a user variable.  Aren't we
 > burdening users with too much Lisp-like structures for options that
 > are supposed to be easily customizable by people who don't know Lisp?
 > I mean, using a single level of parentheses around some list, or the
 > `setq' syntax, is one thing -- users can still form some simple mental
 > model of that which doesn't require understanding of Lisp.  But the
 > above is something else: they are nested, with some lists requiring
 > '() quoting, others not, some members use `:', others don't, some are
 > cons cells, others lists; etc.
 >
 > If we cannot find a simpler syntax, perhaps we should provide an
 > interactive function for customizing display-buffer's behavior, some
 > kind of wizard that would lead the user through a series of questions
 > with detailed description of the result of each setting, and in the
 > end generate the value needed for the user-specified behavior.  (The
 > series of questions could be expressed as a nifty GUI dialog with
 > check-boxes in GUI sessions.)

Most of these are completely hidden by the customization interface.  In
particular, the user of the latter should not be aware of the underlying
Lisp-like structures, cons cells, lists, `:'.  Maybe you could try
customizing `display-buffer-alist' at least once just in order to tell
me how a naive bystander might react.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> (1) try finding any window on the selected frame that shows the buffer
> already, or (2) reuse any but the selected window on the selected
> frame, evening out window sizes in both cases, if applicable.
>
> (setq
>  display-buffer-alist
>  '(".*"
>    (reuse-window :buffer same)
>    (reuse-window :window other)
>    (reuse-window :even-sizes t)))
>
> The problem here is that the (reuse-window :window other) specifier
> would change the semantics of the (reuse-window :buffer same) specifier
> to _not reuse_ the selected window even if it shows the buffer.

No.  Each specifier must not affect the behavior of the other specifiers
in the list.  As soon as one specifier triggers, the following
specifiers must be ignored.  That is, the specifier list should be an OR
list, not some complicated combination of AND and OR.

If you wanted the first specifier to never reuse the selected window
even if it shows the buffer, the alist should be something like

 (setq
  display-buffer-alist
  '(".*"
    (reuse-window :buffer same :window other)
    (reuse-window :window other)

One more thing.  Put the even-sizes option into the specifier, not in
its own entry, like this:

 (setq
  display-buffer-alist
  '(".*"
    (reuse-window :buffer same :even-sizes t)
    (reuse-window :window other :even-sizes t)))

Re: display-buffer-alist simplifications

[martin rudalics]

 > No.  Each specifier must not affect the behavior of the other specifiers
 > in the list.  As soon as one specifier triggers, the following
 > specifiers must be ignored.  That is, the specifier list should be an OR
 > list, not some complicated combination of AND and OR.
 >
 > If you wanted the first specifier to never reuse the selected window
 > even if it shows the buffer, the alist should be something like
 >
 >  (setq
 >   display-buffer-alist
 >   '(".*"
 >     (reuse-window :buffer same :window other)
 >     (reuse-window :window other)
 >
 > One more thing.  Put the even-sizes option into the specifier, not in
 > its own entry, like this:
 >
 >  (setq
 >   display-buffer-alist
 >   '(".*"
 >     (reuse-window :buffer same :even-sizes t)
 >     (reuse-window :window other :even-sizes t)))

So you mean to choose the third proposal

(3) Disallow lookup for further occurrences of the same specifier.
     This implies that we'd have to write

(setq
  display-buffer-alist
  '(".*"
    (reuse-window :buffer same :even-sizes t)
    (reuse-window :window other :even-sizes t)))

from my earlier list ;-)

This has the disadvantage that Lisp users would have to set the value of
every specifier like even-sizes unless it's nil.  In practice, this
means that you have to repeat the values of min-height and min-width for
pop-up-windows and the value of pop-up-frame-alist for each and every
entry that wants to use them.  This can be done but it's tedious and
contradicts Emacs 23 practice where things like `pop-up-frame-alist' and
`special-display-frame-alist' are specified once only.

The major problem with this approach, however, is an inconsistency when
handling specifiers passed by the application.  Currently, these
specifiers are merged into the user's specifiers.  Suppose I write

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window nil same)
     (reuse-window-even-sizes . t))))

(display-buffer "*scratch*" '((reuse-window other)))

then the `display-buffer' call does even window sizes because it's
specified in `display-buffer-alist'.  What would you propose here?

A similar issue occurs when merging in specifiers corresponding to Emacs
23 options.  Currently, the reuse-window-even-sizes specifier is set for
all buffers from the value of `even-window-heights' which is t by
default.  This produces a normalized specifier which is respected
whenever a window is reused but not written into `display-buffer-alist'.
How should I proceed here?

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> This has the disadvantage that Lisp users would have to set the value
> of every specifier like even-sizes unless it's nil.  In practice, this
> means that you have to repeat the values of min-height and min-width
> for pop-up-windows and the value of pop-up-frame-alist for each and
> every entry that wants to use them.

This is not important.  If this is an issue, it would be cleaner to use
global variables to specify defaults.

> The major problem with this approach, however, is an inconsistency
> when handling specifiers passed by the application.  Currently, these
> specifiers are merged into the user's specifiers.  Suppose I write
>
> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window nil same)
>     (reuse-window-even-sizes . t))))
>
> (display-buffer "*scratch*" '((reuse-window other)))
>
> then the `display-buffer' call does even window sizes because it's
> specified in `display-buffer-alist'.  What would you propose here?

IIUC, the current system also has a limitation: there is no way to use
display-buffer-alist to tell Emacs to apply even-sizes selectively,
e.g. only when reusing a window already containing the buffer.

I think this indicates that the idea of "merging" specifiers is flawed.
display-buffer-alist is trying to serve two purposes: "merging"
specifiers passed to display-buffer, and "overriding" them completely.
That makes it very complicated to use/understand.

Why not let display-buffer-alist exclusively perform the "override"
case---i.e. let it take precedence over display-buffer's argument
specifiers?

As for the "merge" functionality, some of it is already handled using
global variables, like `even-window-heights'.  In the future, we could
provide a more versatile way to do merging (e.g.  provide an abnormal
hook that accepts the display specifier that Emacs is told to use, and
return a modified specifier for it to actually use).  But I think we can
defer that part to post-24.1.

Re: display-buffer-alist simplifications

[martin rudalics]

 > This is not important.  If this is an issue, it would be cleaner to use
 > global variables to specify defaults.

FWIW, that's the Emacs 23 way of handling this.  The global variables
are `pop-up-windows' or `split-height-threshold' and to override them
you can use `special-display-regexps' with a user defined function.  The
problem with such an approach is that you have to explain precedence in
the doc-strings like that from `special-display-regexps' saying

   If this variable appears \"not to work\", because you added a
   name to it but the corresponding buffer is displayed in the
   selected window, look at the values of `same-window-buffer-names'
   and `same-window-regexps'.  Those variables take precedence over
   this one.

or leave things completely unexplained as for `pop-up-windows'

   Non-nil means `display-buffer' should make a new window.

failing to mention that this is overridden by practically all other
options.

Not to mention that global options inevitably provoked two developments:
Applications overriding them in all sorts of ways and users asking for
adding more and more options like `display-buffer-reuse-frames' -
apparently a workaround for Emacs' inability to raise frames with some
window managers - or `split-window-preferred-function' with people
asking over and over again how to turn off horizontal splitting.

 > IIUC, the current system also has a limitation: there is no way to use
 > display-buffer-alist to tell Emacs to apply even-sizes selectively,
 > e.g. only when reusing a window already containing the buffer.

Did you tried doing

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window other same)
     (reuse-window-even-sizes . t)
     (reuse-window other other)
     (reuse-window-even-sizes . nil))))

It works for me here.  That is, if I want to display *scratch* and
another window shows it already, window sizes are evened out.  If no
other window shows it, window sizes are left alone.

Things like reuse-window-even-sizes are relicts from the days when most
users were happy to accomodate two windows within a frame.  It's hardly
suited for frames showing more than two windows.  Anyway, it comes from
a global option, currently enabled by default, so I have to respect it
for compatibility reasons.  It's hardly justifiable to bother users with
repeating their settings for all `pop-up-window' specifiers, though.

 > I think this indicates that the idea of "merging" specifiers is flawed.

Hopefully not.  IMHO not merging specifiers would be a real pain.  You
couldn't manage the size of `display-buffer-alist' after a few months.

 > display-buffer-alist is trying to serve two purposes: "merging"
 > specifiers passed to display-buffer, and "overriding" them completely.
 > That makes it very complicated to use/understand.

Merging should be the rule.  Overriding should happen only in a few
cases, when a user is completely dissatisfied with the application's
specifier.  In practice, this means that we can either tell a user on
Emacs-devel something like "this should get fixed by the application
soon, meanwhile try to override this by ..." or "the behavior you want
is very unusual so could you please try overriding it by ...".

 > Why not let display-buffer-alist exclusively perform the "override"
 > case---i.e. let it take precedence over display-buffer's argument
 > specifiers?

Impossible.  The first consequence of this would be applications
rebinding `display-buffer-alist' to nil around `display-buffer' calls.
How would you implement `info-other-window' or `find-file-other-frame'
when the user has a `display-buffer-alist' entry for *Info* or the file
in question?

 > As for the "merge" functionality, some of it is already handled using
 > global variables, like `even-window-heights'.  In the future, we could
 > provide a more versatile way to do merging (e.g.  provide an abnormal
 > hook that accepts the display specifier that Emacs is told to use, and
 > return a modified specifier for it to actually use).  But I think we can
 > defer that part to post-24.1.

These Emacs 23 options are converted to buffer display specifiers which
`display-buffer' handles just like any other display specifiers supplied
by `display-buffer-alist' or the application.  The main idea of
`display-buffer-alist' is to obsolete all these "global variables" in
favor of one.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window other same)
>     (reuse-window-even-sizes . t)
>     (reuse-window other other)
>     (reuse-window-even-sizes . nil))))

This is not clean.  The specifiers interact with one another, and their
ordering affects the behavior of other specifiers.  Semantically it is
even more complicated than font-lock-keywords---which isn't even
user-customizable.

>> display-buffer-alist is trying to serve two purposes: "merging"
>> specifiers passed to display-buffer, and "overriding" them completely.
>> That makes it very complicated to use/understand.
>
> Merging should be the rule.  Overriding should happen only in a few
> cases, when a user is completely dissatisfied with the application's
> specifier.  In practice, this means that we can either tell a user on
> Emacs-devel something like "this should get fixed by the application
> soon, meanwhile try to override this by ..." or "the behavior you want
> is very unusual so could you please try overriding it by ...".

Getting this to work right seems complicated.  If you can provide a
*specific* example of how you intend merging to work, maybe it will make
it clearer for me.

For example, suppose I want Emacs to (i) always avoid displaying in the
current window first, even if the display-buffer specifier says so; (ii)
when trying to reuse a window that already has the desired buffer on the
current frame, also try looking in other frames at the same time; and
(iii) if all other specifiers fail, fall back on using the current
window.  How is that done?

>> Why not let display-buffer-alist exclusively perform the "override"
>> case---i.e. let it take precedence over display-buffer's argument
>> specifiers?
>
> Impossible.  The first consequence of this would be applications
> rebinding `display-buffer-alist' to nil around `display-buffer' calls.
> How would you implement `info-other-window' or `find-file-other-frame'
> when the user has a `display-buffer-alist' entry for *Info* or the file
> in question?

Isn't that what you introduced labels for?

Re: display-buffer-alist simplifications

[martin rudalics]

 >> (setq
 >>  display-buffer-alist
 >>  '((((regexp . ".*"))
 >>     (reuse-window other same)
 >>     (reuse-window-even-sizes . t)
 >>     (reuse-window other other)
 >>     (reuse-window-even-sizes . nil))))
 >
 > This is not clean.  The specifiers interact with one another, and their
 > ordering affects the behavior of other specifiers.

The ordering is important, yes.  But the ordering is fully controlled by
the user.  With Emacs 23 the ordering was implicily specified by the
coding and was explained only in the Elisp manual.  Despite the fact
that Eli spent some time writing the documentation, we had complaints
that it still left out many things.

 > Semantically it is
 > even more complicated than font-lock-keywords---which isn't even
 > user-customizable.

The semantics of `display-buffer-alist' are certainly cleaner than the
semantics of Emacs 23 options.  With `display-buffer-alist' you only
specify what _shall_ be done.  You don't care about what shall be
avoided.  OTOH Emacs 23 options provide a mixture of what should be done
and what should be avoided.

For example, Emacs 23 doesn't allow the user to directly specify that a
buffer should not go to the selected window.  The not-this-window
argument was provided specifically for applications to state that fact.
Users had to write a special-display function to do that.

 > For example, suppose I want Emacs to (i) always avoid displaying in the
 > current window first, even if the display-buffer specifier says so;

Please don't use the formulation "avoid" with `display-buffer-alist'.
Try to formulate in a positive sense: Which window shall be reused
instead when the application's specifer says to use the selected one?

 > (ii)
 > when trying to reuse a window that already has the desired buffer on the
 > current frame, also try looking in other frames at the same time;

This is not very clear (and was even less so in Emacs 23, but that's a
separate story).  Please say which frames it should investigate in which
order - "at the same time" is too vague.  Also say whether in (ii) you
would still insist on using another window but the selected one.

 > and
 > (iii) if all other specifiers fail, fall back on using the current
 > window.  How is that done?

Tell me what's missing in the form

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window other nil 0)
     (override . t)
     (reuse-window same))))

for a call like

(display-buffer "*scratch*" 'same-window)

 >> Impossible.  The first consequence of this would be applications
 >> rebinding `display-buffer-alist' to nil around `display-buffer' calls.
 >> How would you implement `info-other-window' or `find-file-other-frame'
 >> when the user has a `display-buffer-alist' entry for *Info* or the file
 >> in question?
 >
 > Isn't that what you introduced labels for?

Labels should be used when the application proposes to do something
special for a specific command or function but theuser wants it to do
something different.  If everything the user specifies already means to
do something different, we would have to invert the meaning of labels in
the sense of "if the label matches don't do something different but do
what the application wants".

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 > Tell me what's missing in the form
 >
 > (setq
 >  display-buffer-alist
 >  '((((regexp . ".*"))
 >     (reuse-window other nil 0)
 >     (override . t)
 >     (reuse-window same))))
 >
 > for a call like
 >
 > (display-buffer "*scratch*" 'same-window)

But maybe you rather meant something like

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     ;; Reuse another window on any visible frame showing the buffer
     ;; already, overriding application supplied specifiers.
     (reuse-window other same 0)
     ;; Reuse another window on the same frame showing another buffer,
     ;; overriding application supplied specifiers.
     (reuse-window other other)
     (override . t)
     ;; Reuse the same window.
     (reuse-window same))))

for a call like

(display-buffer "*scratch*" 'same-window)

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> This is not clean.  The specifiers interact with one another, and
>> their ordering affects the behavior of other specifiers.
>
> The ordering is important, yes.  But the ordering is fully controlled
> by the user.
>
> The semantics of `display-buffer-alist' are certainly cleaner than the
> semantics of Emacs 23 options.  With `display-buffer-alist' you only
> specify what _shall_ be done.  You don't care about what shall be
> avoided.  OTOH Emacs 23 options provide a mixture of what should be
> done and what should be avoided.

The topic at hand is whether `display-buffer-alist' should "merge" into
the display specifier supplied to `display-buffer'.  Let's put aside the
question of whether the Emacs 23 system is or is not complicated.

> Tell me what's missing in the form
>
> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window other nil 0)
>     (override . t)
>     (reuse-window same))))
>
> for a call like
>
> (display-buffer "*scratch*" 'same-window)

So, IIUC, this converts the same-window specifier

  ((reuse-window same nil nil))

to

  ((reuse-window other nil 0)
   (reuse-window same nil nil)
   (reuse-window same))

Right?  This form of "merging" can be eliminated by providing a
`display-buffer-fallback-alist', removing the need for (override . t)
and one source of unwanted interaction between specifiers.


Here is the basic point.  You're arguing for a buffer display specifier
syntax that consists of interacting elements, because this syntax allows
`display-buffer-alist' to "merge with" or "influence" the specifiers
supplied to `display-buffer'.  Having gone through these examples, I am
convinced that the cost of this design outweighs the benefits.

It is far more important to use a syntax that is easy to understand.
If I have a list of specifiers

  (A B C ...)

that should mean "try A; if that fails, try B; if that fails, try C".

And not a situation where certain B's are not things to try, but instead
are tags that modify how A behaves, or tags that say how to merge this
list with the argument to `display-buffer', etc.  This kind of
pseudo-programming language is not a good fit to the Emacs concept of
customizable options; the traditional way of providing customizable
programming logic is with hooks and abnormal hooks.


>>> Impossible.  The first consequence of this would be applications
>>> rebinding `display-buffer-alist' to nil around `display-buffer' calls.
>>> How would you implement `info-other-window' or `find-file-other-frame'
>>> when the user has a `display-buffer-alist' entry for *Info* or the file
>>> in question?
>>
>> Isn't that what you introduced labels for?
>
> Labels should be used when the application proposes to do something
> special for a specific command or function but the user wants it to do
> something different.

The point is that `info-other-window' can call display-buffer as

  (display-buffer buf specifiers 'info-other-window)

so the user could override this with

  (setq display-buffer-alist
        '((info-other-window replacement-spec)))

This obviates the need to provide the specifier merging functionality,
without forcing Lisp code like `info-other-window' to bind
display-buffer-alist to nil.

Re: display-buffer-alist simplifications

[martin rudalics]

 > The topic at hand is whether `display-buffer-alist' should "merge" into
 > the display specifier supplied to `display-buffer'.  Let's put aside the
 > question of whether the Emacs 23 system is or is not complicated.

The question whether and how to merge such a specifier is central to the
question whether we should change the semantics of the not-this-window
argument of `display-buffer' at all.  If we prefer to not do that, then
I should be able to provide a working version of `display-buffer' from
last autumn which might be quite usable as fallback.  Since most people
do find `display-buffer-alist' much too complicated and Stefan is
apparently opposed to almost all new features it provides, we should
seriously consider reverting the changes introduced by buffer display
specifiers.  In this context it makes also sense to discuss whether the
Emacs 23 system is or is not complicated.

 > So, IIUC, this converts the same-window specifier
 >
 >   ((reuse-window same nil nil))
 >
 > to
 >
 >   ((reuse-window other nil 0)
 >    (reuse-window same nil nil)
 >    (reuse-window same))
 >
 > Right?

Although I'd formulate it the other way round I can live with your
interpretation.

 > This form of "merging" can be eliminated by providing a
 > `display-buffer-fallback-alist', removing the need for (override . t)
 > and one source of unwanted interaction between specifiers.

First of all you would have to give me some idea of what
`display-buffer-fallback-alist' should look like.  Should it be
constructed from the same associations as `display-buffer-alist'?  If
so, then why do you think it's better to pay for removing the (override
. t) entries (which should be fairly rare BTW) with another variable and
a doc-string that would either have to refer to that of
`display-buffer-alist' or replicate most of the latter.

 > Here is the basic point.  You're arguing for a buffer display specifier
 > syntax that consists of interacting elements, because this syntax allows
 > `display-buffer-alist' to "merge with" or "influence" the specifiers
 > supplied to `display-buffer'.

Yes.  The design is still that of Emacs 23 where the `not-this-window'
argument gets interpreted by `display-buffer' as (1) reuse another
window with the value of `even-window-heights' merged in, (2) pop up a
new window with the values of `split-window-preferred-function' merged
in and that of `split-...-threshold' influencing it, or (3) pop up a
frame with the value of `pop-up-frame-alist' merged in.

 > Having gone through these examples, I am
 > convinced that the cost of this design outweighs the benefits.

Can you tell me what you mean by "cost of the design" and how exactly
you want to avoid that cost.  You cannot avoid merging specifiers unless
you duplicate each and every component like `even-sizes' in each and
every specifier.  In the latter case the cost of maintaining an option
like `display-buffer-alist' would clearly outweigh any benefits gained
by making the design less expensive.

 > It is far more important to use a syntax that is easy to understand.
 > If I have a list of specifiers
 >
 >   (A B C ...)
 >
 > that should mean "try A; if that fails, try B; if that fails, try C".

Nothing in the current design prevents you from writing precisely that.

 > And not a situation where certain B's are not things to try, but instead
 > are tags that modify how A behaves, or tags that say how to merge this
 > list with the argument to `display-buffer', etc.  This kind of
 > pseudo-programming language is not a good fit to the Emacs concept of
 > customizable options; the traditional way of providing customizable
 > programming logic is with hooks and abnormal hooks.

It's completely up to the users whether they want that or not.  Users
who don't want a certain B to modify how A behaves can include in A all
necessary ingredients to make sure that B never affects the behavior of
A.  But why should other users who do want B to affect the behavior of A
pay for that by being forced to replicate all these specifiers in A?

 > The point is that `info-other-window' can call display-buffer as
 >
 >   (display-buffer buf specifiers 'info-other-window)
 >
 > so the user could override this with
 >
 >   (setq display-buffer-alist
 >         '((info-other-window replacement-spec)))
 >
 > This obviates the need to provide the specifier merging functionality,
 > without forcing Lisp code like `info-other-window' to bind
 > display-buffer-alist to nil.

Sigh.  You wanted the specifiers of `display-buffer-alist' to always
override those provided by the application.  If a user's
`display-buffer-alist' contains a regexp entry for *info* buffers
telling to display them always in the same window, the label passed by
`info-other-window' won't have any effect and the buffer will be shown
in the same window.  So the user, in addition, has to provide a
`display-buffer-alist' entry based on the `info-other-window' label
which does nothing but replicate what is said in the argument, namely
"yes, please do display the buffer in another window".  Which means that
users who dare to specify a regexp entry for `display-buffer-alist' also
have to specify an entry for each and every `display-buffer' call with
an application provided argument.


Now shouldn't we rather back out all buffer display changes I've applied
recently and revert to using the old Emacs 23 options?  I could easily
incorporate the changes Stefan mentioned earlier and shortly sketched in

http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00461.html

and we'd forget about the whole new semantics of the second argument of
`display-buffer' and more sophisticated ways to tweak `display-buffer'.
Eventually somebody could quietly look into this and apply whatever
people find more suitable and you could quietly go on with the pretest.

martin, who begins feeling to weak to delve into this subject again.

Re: display-buffer-alist simplifications

[Štěpán Němec]

On Monday, 25.07.2011, martin rudalics wrote: 

> martin, who begins feeling to weak to delve into this subject again.

Not that it probably matters at all, but let me express my sincere
appreciation for all your work on making `display-buffer' and friends
suck less. I do hope the outcome of this discussion won't be sticking
with the Emacs 23 state of things.

I think the objections raised by other developers might largely stem
from their insufficient understanding of the new semantics, which in
itself might largely stem from its documentation not being good enough?

I tend to agree with Drew here -- let's first try to improve the docs so
we all understand Martin's proposed changes well enough, before
rejecting them or trying to improve upon them.

So I'd think at this point questions of the form "How do I get this
specific behaviour I want with your new system?" are more useful than
"Why not redesign it like this?" or "Why not drop these parts of the new
design?".

-- 
Štěpán

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Mon, Jul 25, 2011 at 11:29, Štěpán Němec <stepnem@gmail.com> wrote:

> Not that it probably matters at all, but let me express my sincere
> appreciation for all your work on making `display-buffer' and friends
> suck less. I do hope the outcome of this discussion won't be sticking
> with the Emacs 23 state of things.
[...]
> So I'd think at this point questions of the form "How do I get this
> specific behaviour I want with your new system?" are more useful than
> "Why not redesign it like this?" or "Why not drop these parts of the new
> design?".

+1

    Juanma

Re: display-buffer-alist simplifications

[Tim Cross]

On Mon, Jul 25, 2011 at 9:41 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 11:29, Štěpán Němec <stepnem@gmail.com> wrote:
>
>> Not that it probably matters at all, but let me express my sincere
>> appreciation for all your work on making `display-buffer' and friends
>> suck less. I do hope the outcome of this discussion won't be sticking
>> with the Emacs 23 state of things.
> [...]
>> So I'd think at this point questions of the form "How do I get this
>> specific behaviour I want with your new system?" are more useful than
>> "Why not redesign it like this?" or "Why not drop these parts of the new
>> design?".
>
> +1
>
>     Juanma
>
>

+1 and a thumbs up as well.

While Martin has probably put more deep thought into this than most,
even he may not have considered all the possible use cases, so such
questions could also help him as well as the rest of us. I suspect one
of the reasons this seems so difficult is that we as yet don't really
understand the problem. Specific questions from various
viewpoints/requirements may help address this.

Tim

Re: display-buffer-alist simplifications

[Juri Linkov]

> martin, who begins feeling to weak to delve into this subject again.

Having only one customizable variable to specify how to display a buffer
is definitely a very good thing.  One problem is that currently it's
too complicated.  I see the following ways to improve this situation.

There are three levels where the window displaying behavior can be defined:

1. default behavior with good heuristics.  It can be either hard-coded or
   defined in a defvar (or even defconst) with the current default value
   of `display-buffer-alist' (or the result of `display-buffer-alist-set').

2. function-specific behavior can be defined by the arguments
   `specifiers' and `label' of `display-buffer' and override
   the default behavior.

3. user-specific behavior can override the function-specific behavior.
   It seems `display-buffer-alist' was intended to define that.
   But I think it should be separate from the definition of the
   default behavior and should not be merged with it.

To help the users to customize the desired behavior we could allow
to group a set of low-level specifiers into "themes".  So e.g.
for users who prefer using frames we could predefine a "frame theme"
with a set of specifiers that affect displaying buffers in frames.

Each group could be marked with a symbolic tag that can be used
by the `specifiers' argument of `display-buffer', e.g.:

  (display-buffer "*Completions*" 'near-minibuffer)

as well as in the user-customizable variable, e.g.:

  '(("*Completions*" below-selected)
     ("*info*" same-window))

And the value `t' could emulate the old behavior of the argument
`not-this-window' in `display-buffer' for backward-compatibility.

As for `labels' I expect very little use of them.  Maybe we should
allow specifying the command name (i.e. the value of `this-command')
in `display-buffer-alist', e.g.:

  '((("*info*" . info-other-window) same-window))

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Juri Linkov writes:

 > > martin, who begins feeling to weak to delve into this subject again.
 > 
 > Having only one customizable variable to specify how to display a buffer
 > is definitely a very good thing.  One problem is that currently it's
 > too complicated.

The behavior (by which I do *not* mean any behavior that anybody has
so far specified, but the *union* of all behaviors that users want)
*is* *very* complicated.  +1 for accepting that as a fact and getting
on with the business of learning (as a project, though hopefully
within a few months individual users and even many developers can
mostly just accept the defaults) to use Martin's specifiers.

Note that XEmacs has had specifiers (in a somewhat different sense,
but the basic idea of a more or less hierarchical mapping from
contexts to instances is the same) for literally decades, they are
automatically merged, and with the exception of David Kastrup (a
self-proclaimed Simple Mind From the City of Light :-), nobody has
really complained about their complexity and merging generally DTRTs.
Rather users and third-party developers have asked how to accomplish
what they want to do, and generally are pleased with the results they
get.  Specifiers are one thing that nobody in the SXEmacs fork has
suggested getting rid of, by the way.

Since XEmacs specifiers are *not* used to configure buffer to window
mapping, I can't promise that Martin's design will be as successful in
this application, but I think it's very much worth a try.

BTW, designing defaults is IMHO basically impossible.  It's much more
profitable (at least, if the architect is as available and responsive
as Martin has been) to make the basic design as flexible as possible,
start with the architect's preferences as default, and tweak, with the
ongoing advice of the architect on how-to.  Again, I think that it's
probably a good idea to accept that the defaults for Emacs 24 will be
way suboptimal (except in Martin's personal opinion :-), and aim for
good defaults in 24.1 *after* a wide variety of users who usually just
lurk on emacs-devel have had their say.

Re: display-buffer-alist simplifications

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Note that XEmacs has had specifiers (in a somewhat different sense,
> but the basic idea of a more or less hierarchical mapping from
> contexts to instances is the same) for literally decades, they are
> automatically merged, and with the exception of David Kastrup (a
> self-proclaimed Simple Mind From the City of Light :-), nobody has
> really complained about their complexity and merging generally DTRTs.
> Rather users and third-party developers have asked how to accomplish
> what they want to do, and generally are pleased with the results they
> get.

One aim of the GNU project is empowering users.  An interface that
requires relying on highly competent special users and/or extensive
experimentation (which often leads to results relying on undefined
artifacts of the current behavior) is not conducive in that regard.

If you look closely, you'll find a high correlation between "David is
ranting again" and "this won't work without additional resources".  Just
a few days ago the CEDET guys had to suffer that.

> Specifiers are one thing that nobody in the SXEmacs fork has suggested
> getting rid of, by the way.

You can only get rid of things you understand.

-- 
David Kastrup

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

David Kastrup writes:

 > One aim of the GNU project is empowering users.  An interface that
 > requires relying on highly competent special users and/or extensive
 > experimentation (which often leads to results relying on undefined
 > artifacts of the current behavior) is not conducive in that regard.

That criticism applies to all of Emacs in greater or lesser degree,
mostly greater IMHO.

But that's not important.  My main claim is that the important
question is not "is the interface complex?"  Rather it is, "is the
power available with a simpler interface?"  If the answer is "no" (and
I believe that is true for the problems addressed by XEmacs specifiers
-- a generalization of "defface" as Juri points out -- and by Martin's
specifiers), then the question becomes, "shall we have a complex
interface that empowers some users more than others, or shall we have
a procrustean interface that ensures all users have equal and low
capability?"  Emacs obviously has to go for the former; we'll never be
able to equal "Notepad" in the latter. ;-)

 > If you look closely, you'll find a high correlation between "David
 > is ranting again" and "this won't work without additional
 > resources".

Yeah, well, GNU Emacs won't run on an 8086, either, you need
additional resources.

That's not to say that your ranting isn't a service to the community;
it certainly is.  But you shouldn't stand in the way of necessary
complexity (unless you can show it isn't really necessary!)

 > Just a few days ago the CEDET guys had to suffer that.

Different case, IIUC.  AIUI the resource CEDET is missing is a central
piece of "the preferred form for making changes to the software."  I
find it incomprehensible that CEDET was permitted to be installed in
Emacs in that state (or perhaps I misunderstand the issue), but it's
not my problem.

 > > Specifiers are one thing that nobody in the SXEmacs fork has suggested
 > > getting rid of, by the way.
 > 
 > You can only get rid of things you understand.

The SXEmacs developers understand fine, as do many XEmacs users.  Your
situation is different; you aren't an XEmacs user except to the extent
that you support a few XEmacs users who also happen to use AUCTeX.
You had every right to complain, although it was less than gracious of
you to refuse to review the rewrite of the documents you complained so
vociferously about.

Re: display-buffer-alist simplifications

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > One aim of the GNU project is empowering users.  An interface that
>  > requires relying on highly competent special users and/or extensive
>  > experimentation (which often leads to results relying on undefined
>  > artifacts of the current behavior) is not conducive in that regard.
>
> That criticism applies to all of Emacs in greater or lesser degree,
> mostly greater IMHO.

There is a qualitative difference between requiring leads and pointers,
and requiring somebody else to do the work.

> But that's not important.  My main claim is that the important
> question is not "is the interface complex?"  Rather it is, "is the
> power available with a simpler interface?"  If the answer is "no" (and
> I believe that is true for the problems addressed by XEmacs specifiers
> -- a generalization of "defface" as Juri points out -- and by Martin's
> specifiers), then the question becomes, "shall we have a complex
> interface that empowers some users more than others, or shall we have
> a procrustean interface that ensures all users have equal and low
> capability?"  Emacs obviously has to go for the former; we'll never be
> able to equal "Notepad" in the latter. ;-)

Sometimes the right question is "where did we go wrong that we require
this sort of power in the first place?".  When did we fall off the cliff
of diminishing returns?  It is, in my opinion, the main question to be
solved in the energy, climate, waste, law&order crisises.

> Different case, IIUC.  AIUI the resource CEDET is missing is a central
> piece of "the preferred form for making changes to the software."  I
> find it incomprehensible that CEDET was permitted to be installed in
> Emacs in that state (or perhaps I misunderstand the issue), but it's
> not my problem.

The rationale as far as I understand was "it is useful, this is just
transitory, and we are going to fix this when the version control
migrations are past, quite certainly before the next major release".

The cases are related in as far that they frustrate me by keeping me
from having the power to work with the software on my system.

> The SXEmacs developers understand fine, as do many XEmacs users.  Your
> situation is different; you aren't an XEmacs user except to the extent
> that you support a few XEmacs users who also happen to use AUCTeX.

I am no longer doing that.

> You had every right to complain, although it was less than gracious of
> you to refuse to review the rewrite of the documents you complained so
> vociferously about.

There would be little point to reviewing XEmacs programming documents
when I don't have a copy of XEmacs installed anymore.

-- 
David Kastrup

Re: display-buffer-alist simplifications

[Juri Linkov]

> Since XEmacs specifiers are *not* used to configure buffer to window
> mapping, I can't promise that Martin's design will be as successful in
> this application, but I think it's very much worth a try.

GNU Emacs has a similar system of specifiers in face definitions.
It's simpler but still powerful enough for its purpose.
`defface' defines a set of conditions for different contexts depending
on a list of such specifiers as `type', `class', `min-colors',
`supports' that maps to a set of merging face attributes.

The advantage of Martin's design is that it provides a similar set of
conditions ("buffer identifiers") that can be easily extended.
Currently `name' and `regexp' match the name of the buffer to display.
But it would be useful to add more identifiers such as e.g.
"from-name" and "from-regexp" to match the name of the original
buffer from which a new buffer should be displayed, so a rule like
'(((from-name . "*Help*")) ((reuse-window nil same))) will reuse
the selected window to display any buffer (regardless of its name)
if the selected window's buffer was "*Help*". This is easy to do
with Martin's design.

Generally behavior is defined by a set of rules with two parts:
conditions (that define the context) and actions (that define what to do).
In rules defined by `display-buffer-alist' "buffer identifiers" are
conditions and "display specifiers" are actions.  But one problem with
the new design is that some conditions are implicit and hard-coded into
actions.  I mean such conditions that can be expressed as e.g.
"the buffer is already displayed in another window or frame",
"the selected window is to narrow to split" and other restrictions
depending on the values of `window-min-width', `window-min-height', etc.

Defining such conditions explicitly will allow writing more precise rules
and avoid the problem of merging actions (they will be executed
sequentially without problems).

Another difference between face specifications and window displaying
is that rules that define how to display faces are grouped and named
by `defface' and can grouped further into themes.  Another important
feature of face specifications is the attribute `:inherit' that
allows creating new definitions based on existing definitions.
That's why faces are easy for users to customize.  Doing something like
that for windows will help to improve usability of the new design.

Re: display-buffer-alist simplifications

[martin rudalics]

 > Generally behavior is defined by a set of rules with two parts:
 > conditions (that define the context) and actions (that define what to do).
 > In rules defined by `display-buffer-alist' "buffer identifiers" are
 > conditions and "display specifiers" are actions.  But one problem with
 > the new design is that some conditions are implicit and hard-coded into
 > actions.  I mean such conditions that can be expressed as e.g.
 > "the buffer is already displayed in another window or frame",
 > "the selected window is to narrow to split" and other restrictions
 > depending on the values of `window-min-width', `window-min-height', etc.

A pure condition/rule analogy is hard to achieve.  IIUC, for example,
`even-window-sizes' would be a rule.  This rule works on the conditions
that the window used and the selected window are adjacent, one of them
is higher, ...  Would these be conditions?

 > Defining such conditions explicitly will allow writing more precise rules
 > and avoid the problem of merging actions (they will be executed
 > sequentially without problems).

I'm not sure what you mean by "merging actions".  How would you "merge
in" the Emacs 23 default behavior of evening window heights?

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

> A pure condition/rule analogy is hard to achieve.  IIUC, for example,
> `even-window-sizes' would be a rule.  This rule works on the conditions
> that the window used and the selected window are adjacent, one of them
> is higher, ...  Would these be conditions?

These are not conditions.  They are post-actions, i.e. the final actions
to be called after performing base actions, so merging should take care
of putting `even-window-sizes' after window splitting, etc.

Moreover, I suspect that `even-window-sizes' is unnecessary.
Using `balance-windows' at the end of the action part of the rule
should do the same.  Their functionalities are conceptually similar,
so I think they should be joined to `balance-windows'.

> I'm not sure what you mean by "merging actions".  How would you "merge
> in" the Emacs 23 default behavior of evening window heights?

In Emacs 23, `display-buffer' called `window--even-window-heights'
unconditionally.  So calling it from the action part of the rule
should be equivalent.

Re: display-buffer-alist simplifications

[martin rudalics]

 > In Emacs 23, `display-buffer' called `window--even-window-heights'
 > unconditionally.  So calling it from the action part of the rule
 > should be equivalent.

Currently I can't call it unconditionally because popping up a window
may try to fit the window to its buffer (in its post-action, say).

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 > There are three levels where the window displaying behavior can be defined:
 >
 > 1. default behavior with good heuristics.  It can be either hard-coded

It currently is hard-coded with the precise behavior specified by the
user's settings for the Emacs 23 options and the default fallbacks of
Emacs 23 `display-buffer'.

 >    or
 >    defined in a defvar (or even defconst) with the current default value
 >    of `display-buffer-alist' (or the result of `display-buffer-alist-set').

The latter function in fact initializes `display-buffer-alist' from the
users old settings, the Emacs 23 default if emacs -Q is used.

 > 2. function-specific behavior can be defined by the arguments
 >    `specifiers' and `label' of `display-buffer' and override
 >    the default behavior.
 >
 > 3. user-specific behavior can override the function-specific behavior.
 >    It seems `display-buffer-alist' was intended to define that.

Not really.  I assume that most `display-buffer' calls do not set the
specifiers argument.  User-specific behavior can be mainly seen as what
customizing buffer display options does in Emacs 23.  If and only if
users are dissatisfied with the specifiers argument they override it.

 >    But I think it should be separate from the definition of the
 >    default behavior and should not be merged with it.

If a user doesn't care about specifying an option, the default behavior
will be merged in.  How would you avoid that?

 > To help the users to customize the desired behavior we could allow
 > to group a set of low-level specifiers into "themes".  So e.g.
 > for users who prefer using frames we could predefine a "frame theme"
 > with a set of specifiers that affect displaying buffers in frames.

There are only two major groups: The pop-up-windows group and the
pop-up-frames group.  Reusing windows is part of both (and of the
single-frame-single-window minority).

 > Each group could be marked with a symbolic tag that can be used
 > by the `specifiers' argument of `display-buffer', e.g.:
 >
 >   (display-buffer "*Completions*" 'near-minibuffer)
 >
 > as well as in the user-customizable variable, e.g.:
 >
 >   '(("*Completions*" below-selected)
 >      ("*info*" same-window))
 >
 > And the value `t' could emulate the old behavior of the argument
 > `not-this-window' in `display-buffer' for backward-compatibility.

Basically, that's what macro specifiers are intended for.

 > As for `labels' I expect very little use of them.  Maybe we should
 > allow specifying the command name (i.e. the value of `this-command')
 > in `display-buffer-alist', e.g.:
 >
 >   '((("*info*" . info-other-window) same-window))

I consider labels as something to quickly override the behavior for a
specific function invocation until a better solution has been found.

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

>> There are three levels where the window displaying behavior can be defined:
>>
>> 1. default behavior with good heuristics.  It can be either hard-coded
>
> It currently is hard-coded with the precise behavior specified by the
> user's settings for the Emacs 23 options and the default fallbacks of
> Emacs 23 `display-buffer'.
>
>>    or
>>    defined in a defvar (or even defconst) with the current default value
>>    of `display-buffer-alist' (or the result of `display-buffer-alist-set').
>
> The latter function in fact initializes `display-buffer-alist' from the
> users old settings, the Emacs 23 default if emacs -Q is used.

Very good for backward-compatibility.

>> 2. function-specific behavior can be defined by the arguments
>>    `specifiers' and `label' of `display-buffer' and override
>>    the default behavior.
>>
>> 3. user-specific behavior can override the function-specific behavior.
>>    It seems `display-buffer-alist' was intended to define that.
>
> Not really.  I assume that most `display-buffer' calls do not set the
> specifiers argument.  User-specific behavior can be mainly seen as what
> customizing buffer display options does in Emacs 23.  If and only if
> users are dissatisfied with the specifiers argument they override it.

I meant "user-specific behavior can override the _default_ and
function-specific behavior", i.e. I forgot to mention that
users can override the default behavior as well.  If now the default
behavior is based on the users old settings, then users new settings
should override them.  For instance, when old customization in .emacs
sets `pop-up-frames' to t, and the user customizes `display-buffer-alist'
to not create a frame, then settings from `display-buffer-alist'
should override the old settings `pop-up-frames'.

> If a user doesn't care about specifying an option, the default behavior
> will be merged in.  How would you avoid that?

My concern is how users will be able to override parts of the
default behavior?  For instance, how users can specify a rule
to override the default and to not to balance/even window sizes?
I understand that using settings like (reuse-window-even-sizes . nil)
and (reuse-window-even-sizes . t).

>> Each group could be marked with a symbolic tag that can be used
>> by the `specifiers' argument of `display-buffer', e.g.:
>>
>>   (display-buffer "*Completions*" 'near-minibuffer)
>>
>> as well as in the user-customizable variable, e.g.:
>>
>>   '(("*Completions*" below-selected)
>>      ("*info*" same-window))
>>
>> And the value `t' could emulate the old behavior of the argument
>> `not-this-window' in `display-buffer' for backward-compatibility.
>
> Basically, that's what macro specifiers are intended for.

How easy is to add new macros like `near-minibuffer' and `below-selected'?
Can users add own macros?

>> As for `labels' I expect very little use of them.  Maybe we should
>> allow specifying the command name (i.e. the value of `this-command')
>> in `display-buffer-alist', e.g.:
>>
>>   '((("*info*" . info-other-window) same-window))
>
> I consider labels as something to quickly override the behavior for a
> specific function invocation until a better solution has been found.

I'm sure that most authors will be lazy or forget to add labels.
And how users are supposed to deal with the lack of labels?
Should they send mails to the authors asking them to add labels?
Honestly, I think adding labels was good intention but they are useless.

For some exceptional cases where it's impossible to override the
function-specific behavior based on `buffer-or-name' or `this-command',
then a label could be specified as part of specifiers like
`((label . "info-other-window") ...)'.

Or maybe we can't remove the 3rd argument of `display-buffer'
for backward-compatibility with the old version that had 3 arguments,
so we should keep the 3rd argument and use it for something?

Re: display-buffer-alist simplifications

[martin rudalics]

 > I meant "user-specific behavior can override the _default_ and
 > function-specific behavior", i.e. I forgot to mention that
 > users can override the default behavior as well.  If now the default
 > behavior is based on the users old settings, then users new settings
 > should override them.  For instance, when old customization in .emacs
 > sets `pop-up-frames' to t, and the user customizes `display-buffer-alist'
 > to not create a frame, then settings from `display-buffer-alist'
 > should override the old settings `pop-up-frames'.

That's what the current code does, hopefully.

 > My concern is how users will be able to override parts of the
 > default behavior?  For instance, how users can specify a rule
 > to override the default and to not to balance/even window sizes?
 > I understand that using settings like (reuse-window-even-sizes . nil)
 > and (reuse-window-even-sizes . t).

Yes.

 > How easy is to add new macros like `near-minibuffer' and `below-selected'?
 > Can users add own macros?

Currently there's only the constant `display-buffer-macro-specifiers'.
I made it a constant because I considered modifying it unsafe.  We could
make it customizable.

 > I'm sure that most authors will be lazy or forget to add labels.
 > And how users are supposed to deal with the lack of labels?
 > Should they send mails to the authors asking them to add labels?
 > Honestly, I think adding labels was good intention but they are useless.

Maybe.  I have no strong opinion.

 > For some exceptional cases where it's impossible to override the
 > function-specific behavior based on `buffer-or-name' or `this-command',
 > then a label could be specified as part of specifiers like
 > `((label . "info-other-window") ...)'.
 >
 > Or maybe we can't remove the 3rd argument of `display-buffer'
 > for backward-compatibility with the old version that had 3 arguments,
 > so we should keep the 3rd argument and use it for something?

That was part of the idea of the labels concept.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> First of all you would have to give me some idea of what
> `display-buffer-fallback-alist' should look like.  Should it be
> constructed from the same associations as `display-buffer-alist'?

Yes, that is the idea.

> why do you think it's better to pay for removing the (override . t)
> entries (which should be fairly rare BTW) with another variable and a
> doc-string that would either have to refer to that of
> `display-buffer-alist' or replicate most of the latter.

Because that would simplify the meaning of both variables, by making
every specifier be a particular way to finding a window to display
in---with no exceptions.

>> Having gone through these examples, I am convinced that the cost of
>> this design outweighs the benefits.
>
> Can you tell me what you mean by "cost of the design" and how exactly
> you want to avoid that cost.  You cannot avoid merging specifiers
> unless you duplicate each and every component like `even-sizes' in
> each and every specifier.  In the latter case the cost of maintaining
> an option like `display-buffer-alist' would clearly outweigh any
> benefits gained by making the design less expensive.

One cost is that, from your previous message, it conflicts with using a
plist syntax like

  (display-buffer buf
    '((reuse-window :buffer same :window other)
      (pop-up-window :root lru :side right :min-width 10)))

This syntax is (IMO) much more readable.  It is easy to guess what every
element means---one problem I have with the current design is that I
have to delve into the docstring to work out what the different elements
and special tags mean.  And it has the advantage of similarity with
other facilities in Emacs, like defface specs.

> Now shouldn't we rather back out all buffer display changes I've
> applied recently and revert to using the old Emacs 23 options?

I like the display specifier argument to `display-buffer' (with the
aboves changes to the syntax to make them easier to understand); it
seems like a real improvement in the way Lisp programs handle window and
buffer switching.

What I find problematic is `display-buffer-alist' and specifier merging.
I don't like the idea that each specifier lacks a self-contained
meaning, because it can be modified by other specifiers.  IIUC, even
with these complications it's still not as flexible as real Lisp code
(e.g. in situations where you want to merge in a specifier if and only
if the original specifier had some specific form).

My inclination would be to keep the display specifier argument to
`display-buffer', switching to the plist syntax, but leave out
`display-buffer-alist' until we can work out a better way to do merging
(e.g. in 24.2).  This way, the display specifier functionality is at
least accessible to Lisp programs for 24.1.  Do you think this is
feasible, or do you think that it's impractical, e.g. because the plist
syntax is fundamentally incompatible with merging?  If so, it might be
good to revert everything and postphone these changes to 24.2.

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Tue, 26 Jul 2011 22:43:20 -0400
> Cc: emacs-devel@gnu.org
> 
>   (display-buffer buf
>     '((reuse-window :buffer same :window other)
>       (pop-up-window :root lru :side right :min-width 10)))
> 
> This syntax is (IMO) much more readable.  It is easy to guess what every
> element means---one problem I have with the current design is that I
> have to delve into the docstring to work out what the different elements
> and special tags mean.  And it has the advantage of similarity with
> other facilities in Emacs, like defface specs.

OTOH, we have the example of frame parameters alist, which supports
merging with the default-frame-alist, is quite self-explanatory, and
works quite well in practice, AFAIK.

So why wouldn't display-buffer-alist be useful as an alist as well,
without any need for a plist?

> My inclination would be to keep the display specifier argument to
> `display-buffer', switching to the plist syntax, but leave out
> `display-buffer-alist' until we can work out a better way to do merging
> (e.g. in 24.2).

If there's no display-buffer-alist, then how can users customize the
behavior to their liking?  The current code sets up
display-buffer-alist from various user options for backward
compatibility; leave display-buffer-alist out, and those options will
have no effect on behavior whatsoever, IIUC.

> If so, it might be good to revert everything and postphone these
> changes to 24.2.

Alternatively, we could postpone the pretest and invest the time into
this issue now.  IMO, reverting everything, or even a large portion of
it, would be extremely unkind to Martin's efforts, especially that the
only reason for that is our self-imposed date of pretest start.  That
date is by no means sacred.  We should cherish significant
contributions like this one much more than we cherish the schedule of
Emacs releases.

Re: display-buffer-alist simplifications

[Tim Cross]

On Wed, Jul 27, 2011 at 2:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Tue, 26 Jul 2011 22:43:20 -0400
>> Cc: emacs-devel@gnu.org
>>
>>   (display-buffer buf
>>     '((reuse-window :buffer same :window other)
>>       (pop-up-window :root lru :side right :min-width 10)))
>>
>> This syntax is (IMO) much more readable.  It is easy to guess what every
>> element means---one problem I have with the current design is that I
>> have to delve into the docstring to work out what the different elements
>> and special tags mean.  And it has the advantage of similarity with
>> other facilities in Emacs, like defface specs.
>
> OTOH, we have the example of frame parameters alist, which supports
> merging with the default-frame-alist, is quite self-explanatory, and
> works quite well in practice, AFAIK.
>
> So why wouldn't display-buffer-alist be useful as an alist as well,
> without any need for a plist?
>
>> My inclination would be to keep the display specifier argument to
>> `display-buffer', switching to the plist syntax, but leave out
>> `display-buffer-alist' until we can work out a better way to do merging
>> (e.g. in 24.2).
>
> If there's no display-buffer-alist, then how can users customize the
> behavior to their liking?  The current code sets up
> display-buffer-alist from various user options for backward
> compatibility; leave display-buffer-alist out, and those options will
> have no effect on behavior whatsoever, IIUC.
>
>> If so, it might be good to revert everything and postphone these
>> changes to 24.2.
>
> Alternatively, we could postpone the pretest and invest the time into
> this issue now.  IMO, reverting everything, or even a large portion of
> it, would be extremely unkind to Martin's efforts, especially that the
> only reason for that is our self-imposed date of pretest start.  That
> date is by no means sacred.  We should cherish significant
> contributions like this one much more than we cherish the schedule of
> Emacs releases.
>
>

+1

Tim

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Wed, Jul 27, 2011 at 06:59, Eli Zaretskii <eliz@gnu.org> wrote:

> Alternatively, we could postpone the pretest and invest the time into
> this issue now.  IMO, reverting everything, or even a large portion of
> it, would be extremely unkind to Martin's efforts, especially that the
> only reason for that is our self-imposed date of pretest start.  That
> date is by no means sacred.  We should cherish significant
> contributions like this one much more than we cherish the schedule of
> Emacs releases.

+1

Let's not forget that the reason we're struggling right now with
Martin's changes is that he had them in a branch for a long time with
little outside testing. Which makes me wonder if, really, developing
such sweeping changes in a branch is such a good idea, once past the
point where everything seems to be more or less in place. Is not as if
destabilizing the trunk is such a big deal anyway, and it would get
more testing.

    Juanma

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Wed, Jul 27, 2011 at 13:25, Juanma Barranquero <lekktu@gmail.com> wrote:

> Let's not forget [...] more testing.

Next time I'll try to use "such" four or more times in a single
paragraph. What's life without a challenge now and then?

    Juanma

Re: display-buffer-alist simplifications

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> Which makes me wonder if, really, developing such sweeping changes in
> a branch is such a good idea, once past the point where everything
> seems to be more or less in place.

Developing in a separate branch seems to have been successful for Eli's
bidi work, so I think it varies.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: display-buffer-alist simplifications

[David Kastrup]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> Which makes me wonder if, really, developing such sweeping changes in
>> a branch is such a good idea, once past the point where everything
>> seems to be more or less in place.
>
> Developing in a separate branch seems to have been successful for Eli's
> bidi work, so I think it varies.

IIRC, the development was stalled in that separate branch, and he just
kept working on a private version.  So it does not seem like the best
example.

-- 
David Kastrup

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Wed, Jul 27, 2011 at 13:47, David Kastrup <dak@gnu.org> wrote:

> IIRC, the development was stalled in that separate branch, and he just
> kept working on a private version.  So it does not seem like the best
> example.

No, it's not the best example. Just a datapoint which made me think.
In some respects, we're still on the phase of researching effective
working protocols for Emacs development in a dVCS world. Or that's my
feeling anyway.

    Juanma

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Wed, Jul 27, 2011 at 13:30, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Developing in a separate branch seems to have been successful for Eli's
> bidi work, so I think it varies.

Honestly, we don't yet know if it has worked for Eli's bidi changes,
because `bidi-display-reordering' still defaults to nil. Once we
switch it and start getting bug reports. or not, we'll see. Note that
I'm not talking about the easyness of developing in a separate branch,
or the convenience of adding a lot of related changes to the trunk as
a single merge commit. These, I don't deny. I'm just wondering whether
there are enough interested Emacs developers to really help testing
anything big before it is committed to the trunk.

That said, I think Eli's bidi is a huge amount of work and he's been
very thourough, and if I had to bet, I'd bet on bidi integration being
a success. But IIUC, the gist of it is, if you don't use bidi, you
*shouldn't* see anything different. It should just work like before.
Martin's changes weren't so clear-cut. They affect something that
everybody uses, and which wasn't really well defined and easy to set
up in previous Emacsen. He's solving a problem with, from my outside
point of view, has a lower implementation complexity that bidi, but a
higher UI complexity.  (Now, excuse me if I run before Eli's got hold
of his stone-engraved copy of UAX#9...)

    Juanma

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 27 Jul 2011 14:02:07 +0200
> 
> On Wed, Jul 27, 2011 at 13:30, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> 
> > Developing in a separate branch seems to have been successful for Eli's
> > bidi work, so I think it varies.
> 
> Honestly, we don't yet know if it has worked for Eli's bidi changes,
> because `bidi-display-reordering' still defaults to nil. Once we
> switch it and start getting bug reports. or not, we'll see.

Exactly my thoughts.  Although in my case, I made a point of merging
onto the trunk as soon as the code was reasonably stable (read:
stopped crashing every minute or so).  I'm grateful to Stefan and
Chong for their encouragement to do so, because I had my doubts.

> That said, I think Eli's bidi is a huge amount of work and he's been
> very thourough, and if I had to bet, I'd bet on bidi integration being
> a success.

Thanks.  But I still have my doubts ;-)

RE: display-buffer-alist simplifications

[Drew Adams]

> Alternatively, we could postpone the pretest and invest the time into
> this issue now.  IMO, reverting everything, or even a large portion of
> it, would be extremely unkind to Martin's efforts, especially that the
> only reason for that is our self-imposed date of pretest start.  That
> date is by no means sacred.  We should cherish significant
> contributions like this one much more than we cherish the schedule of
> Emacs releases.

1+

Take the time. Get it right.
There should be no hurry to get to Emacs 24.

And if you do decide to take the time then you can probably thaw the feature
freeze, at least for relatively predictably small new features. IOW, forget
about the "self-imposed date of pretest start".

Re: display-buffer-alist simplifications

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> OTOH, we have the example of frame parameters alist, which supports
> merging with the default-frame-alist, is quite self-explanatory, and
> works quite well in practice, AFAIK.
>
> So why wouldn't display-buffer-alist be useful as an alist as well,
> without any need for a plist?

One difference is that frame parameters don't interact with one another.
Each entry in default-frame-alist overrides any corresponding entry in
initial-frame-alist, and is overridden in turn by any corresponding
entry in window-system-default-frame-alist.

Another difference is that in default-frame-alist, each stored value
(i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
value of a frame parameter.  In display-buffer-alist, each stored value
is a _list_ of specifiers, and each specifier has its own no-obvious
meaning.  For example, in the specifier

   (reuse-window nil nil nil)

each of the `nil's means something different, and you have to look up to
docstring to figure out what it is.

Re: display-buffer-alist simplifications

[martin rudalics]

 > One difference is that frame parameters don't interact with one another.
 > Each entry in default-frame-alist overrides any corresponding entry in
 > initial-frame-alist, and is overridden in turn by any corresponding
 > entry in window-system-default-frame-alist.

With Emacs 23 `pop-up-frame-alist' overrides `default-frame-alist' and
`special-display-frame-alist' overrides `pop-up-frame-alist', hence you
may have to know the values of five lists to know what really goes on
when popping up frames (disregarding `frame-inherited-parameters' which
are applied after the frame has been created).

These parameters interact like the specifiers of `display-buffer-alist'
with one fundamental difference: The normalization procedure for frame
parameters removes all instances of overriden parameters.  It can do so
because frame creation is guaranteed to succeed in the first attempt or
fail forever.

The normalization procedure for `display-buffer-alist' doesn't remove
instances of overridden parameters because processing one method
specifier may fail in which case the next method specifier has to be
tried.

 > Another difference is that in default-frame-alist, each stored value
 > (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
 > value of a frame parameter.  In display-buffer-alist, each stored value
 > is a _list_ of specifiers, and each specifier has its own no-obvious
 > meaning.  For example, in the specifier
 >
 >    (reuse-window nil nil nil)
 >
 > each of the `nil's means something different, and you have to look up to
 > docstring to figure out what it is.

That's true.  Just as I never got around remembering the order of edges
returned by `window-edges'.

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 >> why do you think it's better to pay for removing the (override . t)
 >> entries (which should be fairly rare BTW) with another variable and a
 >> doc-string that would either have to refer to that of
 >> `display-buffer-alist' or replicate most of the latter.
 >
 > Because that would simplify the meaning of both variables, by making
 > every specifier be a particular way to finding a window to display
 > in---with no exceptions.

This is not an argument for using two variables.  The "making every
specifier be a particular way to finding a window to display in---with
no exceptions" can be applied to the current one variable approach as
well.

 > One cost is that, from your previous message, it conflicts with using a
 > plist syntax like
 >
 >   (display-buffer buf
 >     '((reuse-window :buffer same :window other)
 >       (pop-up-window :root lru :side right :min-width 10)))
                        ^^^^^
                        :window

It conflicts only in the sense that a value may be non-scalar like a
list because you would have to say something like

'((reuse-window :window-buffer-frame (other same)))

instead.  But a list-like value would be needed anyway for the
`pop-up-frame-alist' specifier.

 > This syntax is (IMO) much more readable.  It is easy to guess what every
 > element means---one problem I have with the current design is that I
 > have to delve into the docstring to work out what the different elements
 > and special tags mean.  And it has the advantage of similarity with
 > other facilities in Emacs, like defface specs.

Agreed.

 > I like the display specifier argument to `display-buffer' (with the
 > aboves changes to the syntax to make them easier to understand); it
 > seems like a real improvement in the way Lisp programs handle window and
 > buffer switching.
 >
 > What I find problematic is `display-buffer-alist' and specifier merging.

As I explained earlier, you don't have to merge specifiers for
processing `display-buffer-alist'.  If you really want to avoid that, I
can fill in the unspecified elements so there's a 100% guarantee that no
merging occurs within the elements of `display-buffer-alist'.  Which
means that the above specifiers would become semantically equivalent to

  '((reuse-window :buffer same :window other :frame nil :even-sizes t
		 :dedicated nil :dedicate nil :no-other-window nil)
    (pop-up-window :window lru :side right :min-height 40 :min-width 10
		  :desired-height nil :desired-width nil
		  :split-unsplittable nil :no-other-window nil))

But if you want to process the `display-buffer' argument, you have to
merge.  You can't ask all applications that call `display-buffer' to
provide all possible specifiers in the argument.  So you have to merge
in the rest from `display-buffer-alist' or `split-height-threshold',
`special-frame-alist', `pop-up-frame-alist', ....  And I can't merge in
default specifiers as for `display-buffer-alist' because I have to
remain compatible with the Emacs 23 behavior where option values are
merged in.

 > I don't like the idea that each specifier lacks a self-contained
 > meaning, because it can be modified by other specifiers.  IIUC, even
 > with these complications it's still not as flexible as real Lisp code
 > (e.g. in situations where you want to merge in a specifier if and only
 > if the original specifier had some specific form).

You would have to give me an example here.

 > My inclination would be to keep the display specifier argument to
 > `display-buffer', switching to the plist syntax, but leave out
 > `display-buffer-alist' until we can work out a better way to do merging
 > (e.g. in 24.2).

I don't understand you.  If we want to process the display specifier
argument, we have to merge.  If, with Emacs 23, the second argument of
`display-buffer' is non-nil, all `display-buffer' does is to mark the
selected window as not usable.  It merges in the values of all relevant
options wrt finding a suitable "other" window.  Note that Emacs 23 even
merges when you don't provide the argument.  For example, the call in
`message-mail-other-window'

     (let ((pop-up-windows t)
	  (special-display-buffer-names nil)
	  (special-display-regexps nil)
	  (same-window-buffer-names nil)
	  (same-window-regexps nil))
       (message-pop-to-buffer (message-buffer-name "mail" to))))

merges in the value of `split-height-threshold' (which can have the
effect of not popping up a new window but reusing an existing one) and
`even-window-heights' (which may adjust the height of a reused window).
And, if `pop-up-frames' is non-nil, it will merge in the values of
`pop-up-frame-function' and `pop-up-frame-alist' too.

 > This way, the display specifier functionality is at
 > least accessible to Lisp programs for 24.1.  Do you think this is
 > feasible, or do you think that it's impractical, e.g. because the plist
 > syntax is fundamentally incompatible with merging?

The display specifier argument is already there.  But in its current
implementation it gets merged.  That is if you call

(display-buffer
  "*scratch*"
  '((reuse-window other same) (reuse-window other) (reuse-window-even-sizes . t)))

the two attempts to reuse another window will both try to even sizes.
And if you do

(display-buffer
  "*scratch*" '((reuse-window other same) (reuse-window other)))

it will try to even window sizes provided `even-window-heights' is
non-nil.  So nothing would be gained wrt your concerns.

 > If so, it might be
 > good to revert everything and postphone these changes to 24.2.

I intend to start doing that by the end of the week ;-)

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

>   (display-buffer buf
>     '((reuse-window :buffer same :window other)
>       (pop-up-window :root lru :side right :min-width 10)))
>
> This syntax is (IMO) much more readable.  It is easy to guess what every
> element means---one problem I have with the current design is that I
> have to delve into the docstring to work out what the different elements
> and special tags mean.  And it has the advantage of similarity with
> other facilities in Emacs, like defface specs.

In defface specs parameters like `min-width 10' are specified in the
condition part of `defface' like `min-colors 88' as a list.
For non-conditional parameters I agree that the plist syntax is better.
And defface spec merges plist attributes from inherited faces.

I also want to note that tags like `reuse-window' and `pop-up-window'
are redundant in plists.  Their meaning can be expressed as plists like
`:window same', `:window other', `:buffer same'.  This would bring
them closer to the syntax of defface specs that is proven to be flexible
and easy to configure.

> If so, it might be good to revert everything and postphone
> these changes to 24.2.

It would be very sad to revert and move development backward.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Executive summary:

If you do revert, it might be a good idea to tag the last revision
with this version of Martin's code in it for ease of experimenting.

Juri Linkov writes:

 > > If so, it might be good to revert everything and postphone
 > > these changes to 24.2.
 > 
 > It would be very sad to revert and move development backward.

That's not moving development backward!  You can debate whether it's
appropriate or not, but an explicit decision to revert is moving
*forward*: it removes a technical or social blockage to other
development.

Nor is any code lost.  It may be somewhat complicated to untangle the
changes now, but the new code is all still there in the repository,
and in the future the patch to revert can be applied in reverse again
to get you more or less back where you are now.  And at any time you
want to experiment with this code you can revert your 

I actually agree with your opinion that reversion is inappropriate for
this code, IMNSEO FWIW.  I just hate to see people arguing that code
that's in a project should stay just because it's already in.  That
always has the effect of making it harder to conduct such experiments
in the first place!

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Thu, Jul 28, 2011 at 04:12, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> I just hate to see people arguing that code
> that's in a project should stay just because it's already in.

FWIW, in my previous comment the argument was not that it should stay
because it's already in, but that it should stay because it's the best
way to give it the testing and discussion that it needs to be ready.

    Juanma

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Thu, 28 Jul 2011 11:12:34 +0900
> Cc: martin rudalics <rudalics@gmx.at>, Chong Yidong <cyd@stupidchicken.com>,
> 	emacs-devel@gnu.org
> 
> I just hate to see people arguing that code that's in a project
> should stay just because it's already in.  That always has the
> effect of making it harder to conduct such experiments in the first
> place!

A major surgery of one of the Emacs core functionalities, whose
development was encouraged by the head maintainers and whose merge
onto the trunk was explicitly sanctioned by them, is no longer an
``experiment''.  It was an experiment only as long as it was on a
separate branch.  Now it's much more than that.

(Yes, I have a knee-jerk reaction to disrespect for others' work, as
much as you have a knee-jerk reaction to "people arguing that code
should stay just because it's already in".)

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Thu, 28 Jul 2011 11:12:34 +0900
 > > Cc: martin rudalics <rudalics@gmx.at>, Chong Yidong <cyd@stupidchicken.com>,
 > > 	emacs-devel@gnu.org
 > > 
 > > I just hate to see people arguing that code that's in a project
 > > should stay just because it's already in.  That always has the
 > > effect of making it harder to conduct such experiments in the first
 > > place!
 > 
 > A major surgery of one of the Emacs core functionalities, whose
 > development was encouraged by the head maintainers and whose merge
 > onto the trunk was explicitly sanctioned by them, is no longer an
 > ``experiment''.  It was an experiment only as long as it was on a
 > separate branch.  Now it's much more than that.

I'm sorry you take it that way, but it should be clear from reviewing
the context that the word "experiment" was not a description of the
code itself at all!  Use of a modern VCS makes experimenting with code
very cheap, regardless of maintainer encouragement.  Discouraging
"unsanctioned" coding "experiments" is not what I'm talking about here.

Rather, *merging onto the trunk* is always an experiment, ie, a test
of the proposition that the code in its current form will improve
Emacs for the community as a whole.  There's no disrespect toward code
*or* maintainers intended, just an acknowledgement of the fact that we
don't know with certainty whether a particular merge will successfully
improve the project until we try it.

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Thu, 28 Jul 2011 16:45:21 +0900
> Cc: juri@jurta.org, rudalics@gmx.at, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
>  > A major surgery of one of the Emacs core functionalities, whose
>  > development was encouraged by the head maintainers and whose merge
>  > onto the trunk was explicitly sanctioned by them, is no longer an
>  > ``experiment''.  It was an experiment only as long as it was on a
>  > separate branch.  Now it's much more than that.
> 
> I'm sorry you take it that way

Not sure why you should be sorry.  We simply disagree, that's all.

> Rather, *merging onto the trunk* is always an experiment

That's exactly the core of our disagreement.  When the head
maintainers approve a merge, and don't qualify it with something like
"let's try", it's not just an experiment.

> There's no disrespect toward code *or* maintainers intended, just an
> acknowledgement of the fact that we don't know with certainty
> whether a particular merge will successfully improve the project
> until we try it.

No certainty is required.  However, some degree of confidence _is_
expected, and if that's not granted, maintainers should review the
code, ask questions, try it themselves etc., before they sanction the
merge.  You will most probably disagree, but that's MO.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > You will most probably disagree, but that's MO.

I do disagree about policy (I think that it may be a good idea to
consider merging code like bidi, lexbind, and display-buffer at an
earlier stage on an explicitly experimental "we're probably going to
have to take it out, but we need to know what only the users can tell
us for future work" basis), but how is that "disrespectful"?

Note that I didn't propose that people discount the maintainers'
considered opinions, only that they not argue against reversion simply
because it means changing code that's been approved.  IMHO it's more
disrespectful to suggest that the maintainers can't change their minds!

Anyway, the word "experiment" is appropriate until you propose a more
accurate one that takes into account both the maintainers' approval
and the uncertainty of success.

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: juri@jurta.org,
>     rudalics@gmx.at,
>     cyd@stupidchicken.com,
>     emacs-devel@gnu.org
> Date: Fri, 29 Jul 2011 10:39:42 +0900

First, let me make it clear that what I wrote earlier and what I will
write in the future in this thread is by no means meant to be a
criticism of Stefan's and Chong's style of leadership.  I have nothing
but deep respect for their work.  In my case, wrt the bidi support,
their constant encouragement to push this through and get the code
merged onto the trunk and into Emacs 24.1 was definitely a great help.

IOW, I don't intend to say that the current maintenance team does not
do well what I think it should do.

>  > You will most probably disagree, but that's MO.
> 
> I do disagree about policy (I think that it may be a good idea to
> consider merging code like bidi, lexbind, and display-buffer at an
> earlier stage on an explicitly experimental "we're probably going to
> have to take it out, but we need to know what only the users can tell
> us for future work" basis), but how is that "disrespectful"?

If there's considerable doubt about the usefulness and/or quality of
implementation or UI aspects of such a feature, that doubt should be
eliminated to the large extent while the feature is still on a branch.
Most large features like this underwent this process to some degree,
and that is fine.  Once the merge happens, the decision to revert
should be the last resort, not part of a "trial-and-error" routine of
some kind.

In my case, I worked for 2 years on bidirectional display.  That
involved a lot of effort, sometimes at considerable personal price.
Telling me now that this will be reverted _will_ have certain
unpleasant effects on my mood, to put it mildly.  If someone would
request me to do that, I will have a moral right to ask where were
they for the past year and a half, since the bidi code was merged onto
the trunk, and why didn't they take a good look at it, try it out, ask
questions etc.  If I did a poor job, I'd like to hear that back then,
and cut my losses, or go back to the drawing board and come up with a
better design or implementation.

I don't know how long it took Martin to do what he did with
window-level display features, but I'm certain it was longer than a
day or a month.  I don't remember how long was the code available on a
public branch, but it wasn't a day or a month, either.  I expect
Martin to have similar feelings about reverting it now.  I think I
already saw an expression of these feelings in his messages lately.  I
don't think we should trigger such feelings, except if that's the only
way to prevent some disaster.

IOW, developing software by volunteers is a social process, no less
than it is a technical or managerial one, I'm sure you know that.
Reverting some significant contribution is not just a technical
decision, because it has profound social and emotional consequences.

More generally, the GNU Project's goal is to make a better world, not
just better software.  You cannot get there by disregarding people you
meet on the way, just because that might make maintenance or
"progress" a tad harder.  But I digress.

> Note that I didn't propose that people discount the maintainers'
> considered opinions, only that they not argue against reversion simply
> because it means changing code that's been approved.  IMHO it's more
> disrespectful to suggest that the maintainers can't change their minds!

I wasn't talking about just _any_ code reversion, we do that all the
time.  I was talking about significant features that took a long time
and a significant effort to implement and tune, and that had been
publicly available for quite some time.  When we are past a certain
quantity of effort, there's a need for a qualitatively different
decision-making process regarding reversion, IMO.

> Anyway, the word "experiment" is appropriate until you propose a more
> accurate one that takes into account both the maintainers' approval
> and the uncertainty of success.

The point is that certainty of success should be quite high as a
prerequisite for approving such significant features for a merge.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Eli Zaretskii writes:

Now you are the one being disrespectful.  I've been release manager
and the closest thing XEmacs has to a head maintainer for a decade.
Of course I understand the issues you're talking about.  Everything
you mention is a good reason for being reluctant to consider, and even
more reluctant to execute, a reversion of a feature.  I did not and do
not deny that.  Nevertheless, the possibility remains.

 > > Anyway, the word "experiment" is appropriate until you propose a more
 > > accurate one that takes into account both the maintainers' approval
 > > and the uncertainty of success.
 > 
 > The point is that certainty of success should be quite high as a
 > prerequisite for approving such significant features for a merge.

Certainty is not "high" or nor even "quite high".  Certainty is an
absolute, no differences from expectation allowed.  If you are not
certain of the outcome of an action, then ... what do you call that
action?

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rudalics@gmx.at,
>     cyd@stupidchicken.com,
>     emacs-devel@gnu.org
> Date: Fri, 29 Jul 2011 16:44:50 +0900
> 
> Eli Zaretskii writes:
> 
> Now you are the one being disrespectful.

Didn't mean to be, granted.  Sorry if my choice of words somehow could
be interpreted otherwise.

>  > The point is that certainty of success should be quite high as a
>  > prerequisite for approving such significant features for a merge.
> 
> Certainty is not "high" or nor even "quite high".  Certainty is an
> absolute, no differences from expectation allowed.

Sorry for not choosing the right word, English is not my first
language.  I guess I meant high probability.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Certainty is not "high" or nor even "quite high".  Certainty is an
 > > absolute, no differences from expectation allowed.
 > 
 > Sorry for not choosing the right word, English is not my first
 > language.  I guess I meant high probability.

I'm sorry, this is not about your English, which is more than
sufficient to the discussion.  I did not intend to focus on your word
choice, rather on the fact that the outcome is uncertain.

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 31 Jul 2011 01:08:11 +0900
> Cc: rudalics@gmx.at, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Eli Zaretskii writes:
> 
>  > > Certainty is not "high" or nor even "quite high".  Certainty is an
>  > > absolute, no differences from expectation allowed.
>  > 
>  > Sorry for not choosing the right word, English is not my first
>  > language.  I guess I meant high probability.
> 
> I'm sorry, this is not about your English, which is more than
> sufficient to the discussion.  I did not intend to focus on your word
> choice, rather on the fact that the outcome is uncertain.

The level of uncertainty should be low, that's all.  E.g., like the
level of uncertainty that the sun will rise tomorrow in the East and
not elsewhere.

Re: display-buffer-alist simplifications

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Sun, 31 Jul 2011 01:08:11 +0900
>> Cc: rudalics@gmx.at, cyd@stupidchicken.com, emacs-devel@gnu.org
>> 
>> Eli Zaretskii writes:
>> 
>>  > > Certainty is not "high" or nor even "quite high".  Certainty is an
>>  > > absolute, no differences from expectation allowed.
>>  > 
>>  > Sorry for not choosing the right word, English is not my first
>>  > language.  I guess I meant high probability.
>> 
>> I'm sorry, this is not about your English, which is more than
>> sufficient to the discussion.  I did not intend to focus on your word
>> choice, rather on the fact that the outcome is uncertain.
>
> The level of uncertainty should be low, that's all.  E.g., like the
> level of uncertainty that the sun will rise tomorrow in the East and
> not elsewhere.

That's likely a different metric in parts of Finland than in Israel.

-- 
David Kastrup

Re: display-buffer-alist simplifications

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 30 Jul 2011 18:45:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The level of uncertainty should be low, that's all.  E.g., like the
> > level of uncertainty that the sun will rise tomorrow in the East and
> > not elsewhere.
> 
> That's likely a different metric in parts of Finland than in Israel.

Depending on the time of year, yes; but no less predictable.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > The level of uncertainty should be low, that's all.  E.g., like the
 > level of uncertainty that the sun will rise tomorrow in the East and
 > not elsewhere.

Indeed, I agree that getting up before sunrise and watching the
eastern horizon for the crack of dawn is not an experiment.

Unfortunately, not even the Pope is that reliable (and IIUC the Pope
only claims infallibility once or twice a century, which would be way
too infrequent even for release of Emacsen).

Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Fri, Jul 29, 2011 at 08:51, Eli Zaretskii <eliz@gnu.org> wrote:

> Telling me now that this will be reverted _will_ have certain
> unpleasant effects on my mood, to put it mildly.

You trying for the Understatement of the Year Award?

    Juanma

Re: display-buffer-alist simplifications

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>>   (display-buffer buf
>>     '((reuse-window :buffer same :window other)
>>       (pop-up-window :root lru :side right :min-width 10)))
>>
>> This syntax is (IMO) much more readable.  It is easy to guess what every
>> element means---one problem I have with the current design is that I
>> have to delve into the docstring to work out what the different elements
>> and special tags mean.  And it has the advantage of similarity with
>> other facilities in Emacs, like defface specs.
>
> In defface specs parameters like `min-width 10' are specified in the
> condition part of `defface' like `min-colors 88' as a list.
> For non-conditional parameters I agree that the plist syntax is better.
> And defface spec merges plist attributes from inherited faces.

I don't know why the condition part of defface specs doesn't use a
plist, and always figured it was a historical accident.  But you raise a
good point---the defface analogy helps clarify how to think about buffer
display specs.  Let's see where this analogy leads.

Currently, `display-buffer-alist' stores lists of specifiers.  Each
specifier can specify either

  (1) A set of conditions, e.g. "display by reusing an existing window"
      and "the window must be already showing the buffer".

or

  (2) "Extra" properties, like (pop-up-frame-function . foo) or
      (reuse-window-even-sizes . t).

If (1) is analogous to the display type in a defface spec and (2) is
analogous to face properties, then instead of lumping (1) and (2) into a
single list, a specifier should have a form like

  (CONDITIONS ATTRIBUTES)

e.g. something like

  (((method reuse-window) (buffer same) (window other))
   (:even-sizes t :reuse-dedicated t))

or maybe

  ((:method reuse-window :buffer same :window other)
   (:even-sizes t :reuse-dedicated t))

Then, "merging" `display-buffer-alist' into the `display-buffer'
specifier arg means combining the attributes for specifiers with the
"same" conditional.  But what does "the same conditional" mean?

In the current design, a (reuse-window-dedicated . t) appearing in
`display-buffer-alist' affects ALL instances of `reuse-window'
specifiers in the specifier list.  (Or something like that---AFAICT it
affects all except those after another `reuse-window-dedicated' cons
cell.  This is one of the things that bugs me about the design.)

So, should "the same conditional" mean `equal'?  Then it will no longer
be possible to use a single display-buffer-alist to affect ALL
`reuse-window' conditional specs passed to `display-buffer'.  I am
personally fine with that.

Re: display-buffer-alist simplifications

[Juri Linkov]

> I don't know why the condition part of defface specs doesn't use a
> plist, and always figured it was a historical accident.

Inner structures of the condition part of defface already use a plist:

    (((supports :slant italic))
     :slant italic)
    (((supports :underline t))
     :underline t)

And since nested structures are allowed in defface specs like:

     :box (:line-width 2 :color "grey40" :style released-button)

I see no problem using them in the condition part as well.

> So, should "the same conditional" mean `equal'?  Then it will no longer
> be possible to use a single display-buffer-alist to affect ALL
> `reuse-window' conditional specs passed to `display-buffer'.  I am
> personally fine with that.

This means more data duplication in specs.  But this duplication
can be removed via the inheritance mechanism.

Re: display-buffer-alist simplifications

[martin rudalics]

 >> So, should "the same conditional" mean `equal'?  Then it will no longer
 >> be possible to use a single display-buffer-alist to affect ALL
 >> `reuse-window' conditional specs passed to `display-buffer'.  I am
 >> personally fine with that.
 >
 > This means more data duplication in specs.  But this duplication
 > can be removed via the inheritance mechanism.

But how would such an inheritance mechanism look like?  IIUC I would have
to invent a naming mechanism for this purpose.  Or what am I missing?

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

> But how would such an inheritance mechanism look like?  IIUC I would have
> to invent a naming mechanism for this purpose.  Or what am I missing?

Yes, a naming mechanism like macro specifiers, but more flexible like defface.

Re: display-buffer-alist simplifications

[martin rudalics]

 > If (1) is analogous to the display type in a defface spec and (2) is
 > analogous to face properties, then instead of lumping (1) and (2) into a
 > single list, a specifier should have a form like
 >
 >   (CONDITIONS ATTRIBUTES)
 >
 > e.g. something like
 >
 >   (((method reuse-window) (buffer same) (window other))
 >    (:even-sizes t :reuse-dedicated t))
 >
 > or maybe
 >
 >   ((:method reuse-window :buffer same :window other)
 >    (:even-sizes t :reuse-dedicated t))
 >
 > Then, "merging" `display-buffer-alist' into the `display-buffer'
 > specifier arg means combining the attributes for specifiers with the
 > "same" conditional.  But what does "the same conditional" mean?
 >
 > In the current design, a (reuse-window-dedicated . t) appearing in
 > `display-buffer-alist' affects ALL instances of `reuse-window'
 > specifiers in the specifier list.  (Or something like that---AFAICT it
 > affects all except those after another `reuse-window-dedicated' cons
 > cell.  This is one of the things that bugs me about the design.)

More precisely "after a `reuse-window-dedicated' cons cell preceding it
in `display-buffer-alist'.  That is, the (reuse-window-dedicated . t)
cell in the form below affects only the condition where a window showing
another buffer shall be used.  For a window showing the same buffer no
dedication is done.

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window other same)
     (reuse-window-even-sizes . nil)
     (reuse-window other other)
     (reuse-window-even-sizes . t))))

 > So, should "the same conditional" mean `equal'?

What do you mean by `equal' here?

 > Then it will no longer
 > be possible to use a single display-buffer-alist

I suppose you mean "a single display-buffer-alist entry" here?

 > to affect ALL
 > `reuse-window' conditional specs passed to `display-buffer'.  I am
 > personally fine with that.

But how can the user formulate an attribute to do that?  Note that users
can do that with Emacs 23 options.

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

>> to affect ALL
>> `reuse-window' conditional specs passed to `display-buffer'.  I am
>> personally fine with that.
>
> But how can the user formulate an attribute to do that?  Note that users
> can do that with Emacs 23 options.

Maybe by specifying a "catch-all" condition like ".*"?

Re: display-buffer-alist simplifications

[martin rudalics]

 >>> to affect ALL
 >>> `reuse-window' conditional specs passed to `display-buffer'.  I am
 >>> personally fine with that.
 >> But how can the user formulate an attribute to do that?  Note that users
 >> can do that with Emacs 23 options.
 >
 > Maybe by specifying a "catch-all" condition like ".*"?

But that's what I'm doing, implicitly and via
`display-buffer-alist-set'.  Just that users must be able to edit that
value.

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 > In defface specs parameters like `min-width 10' are specified in the
 > condition part of `defface' like `min-colors 88' as a list.
 > For non-conditional parameters I agree that the plist syntax is better.
 > And defface spec merges plist attributes from inherited faces.

Sorry.  I'm a bit lost here.  Is this what is done in the filter parts
of this form

     (:inherit
      (repeat :tag "Inherit"

in `custom-face-attributes'?  If so, then this specifies inheritance
explicitly.  The inheritance mechanism used by `display-buffer-alist' is
implicit.

Let's consider the following example setup:

(setq
  display-buffer-alist
  '((((regexp . ".*")) (pop-up-window (largest) (lru)))
    (((regexp . "^\\*Help\\*$")) (pop-up-window-set-height . fit-window-to-buffer))
    (((regexp . "^\\*.+\\*$")) (pop-up-window-set-height . 20))
    (((regexp . ".*")) (pop-up-window-min-height . 15))))

This currently means that a user wants to

(1) Pop up a window for any buffer either below the largest or least
     recently used window.  The minimum height is 15 lines; if Emacs
     can't make a window that large, don't bother popping up a window.

(2) For "*...*" buffers try setting the window height to 20 lines.  If
     this is not possible, leave the height alone.

(3) For *Help* buffers try fitting the window to the height of the
     buffer.

So the minimum height of the popped up window is inherited for all
"*...*" buffers.

Now the questions are whether (1) writing such specifications is useful
in the first place, and (2) whether such implicit inheritance is useful.
If they are, I don't see a way to _explicitly_ specify that *Help*
buffers should inherit the minimum window height from the specifier for
all buffers.

 > I also want to note that tags like `reuse-window' and `pop-up-window'
 > are redundant in plists.  Their meaning can be expressed as plists like
 > `:window same', `:window other', `:buffer same'.

These tags are mainly used to group items together for the customization
interface: A user caring about how to display a buffer on a separate
frame shouldn't be concerned with specifiers that describe how to pop up
a new window for that buffer.  On the "top level" :window is ambiguous
because it can mean the window to reuse or the window to split.  So we
would have to write ":window-to-reuse same" and ":window-to-split lru"
or something the like.

 > This would bring
 > them closer to the syntax of defface specs that is proven to be flexible
 > and easy to configure.

If I leave in inheritance, the form above could be simplified to say

(setq
  display-buffer-alist
  '((".*" :pop-up-window largest)
    (".*" :pop-up-window lru)
    ("^\\*Help\\*$" :pop-up-window-set-height fit-window-to-buffer)
    ("^\\*.+\\*$" :pop-up-window-set-height 20)
    (".*" :pop-up-window-min-height 15)))

If we don't want inheritance, we'd probably have to write a thing like

(setq
  display-buffer-alist
  '(("^\\*Help\\*$"
     :pop-up-window largest
     :pop-up-window-set-height fit-window-to-buffer
     :pop-up-window-min-height 15)
    ("^\\*Help\\*$"
     :pop-up-window lru
     :pop-up-window-set-height fit-window-to-buffer
     :pop-up-window-min-height 15)
    ("^\\*.+\\*$"
     :pop-up-window largest
     :pop-up-window-set-height 20
     :pop-up-window-min-height 15)
    ("^\\*.+\\*$"
     :pop-up-window lru
     :pop-up-window-set-height 20
     :pop-up-window-min-height 15)
    (".*"
     :pop-up-window largest
     :pop-up-window-min-height 15)
    ("^\\*.+\\*$"
     :pop-up-window lru
     :pop-up-window-min-height 15)))

instead.

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

>     (:inherit
>      (repeat :tag "Inherit"
>
> in `custom-face-attributes'?  If so, then this specifies inheritance
> explicitly.  The inheritance mechanism used by `display-buffer-alist' is
> implicit.

Yes, I meant exactly that.  Explicit settings are easier to understand
and customize for the users.

> Let's consider the following example setup:
>
> (setq
>  display-buffer-alist
>  '((((regexp . ".*")) (pop-up-window (largest) (lru)))
>    (((regexp . "^\\*Help\\*$")) (pop-up-window-set-height . fit-window-to-buffer))
>    (((regexp . "^\\*.+\\*$")) (pop-up-window-set-height . 20))
>    (((regexp . ".*")) (pop-up-window-min-height . 15))))

This is a kind of inheritance by regexps, i.e. a set of buffer names
matched by a stricter regexp is a subset of buffer names matched by a
more loose regexp.  ("Inheritance" is not the right term here, but
acceptable in a sense that a set of objects instantiated by a subclass
is a subset of the set of all objects instantiated by its parent.)

> Now the questions are whether (1) writing such specifications is useful
> in the first place, and (2) whether such implicit inheritance is useful.
> If they are, I don't see a way to _explicitly_ specify that *Help*
> buffers should inherit the minimum window height from the specifier for
> all buffers.

Yes, writing such specifications is useful and "inheritance by regexps"
is useful.  But actually I meant inheritance for named specifications
like macro specifiers (and they are not required to use regexps).

>> I also want to note that tags like `reuse-window' and `pop-up-window'
>> are redundant in plists.  Their meaning can be expressed as plists like
>> `:window same', `:window other', `:buffer same'.
>
> These tags are mainly used to group items together for the customization
> interface: A user caring about how to display a buffer on a separate
> frame shouldn't be concerned with specifiers that describe how to pop up
> a new window for that buffer.  On the "top level" :window is ambiguous
> because it can mean the window to reuse or the window to split.  So we
> would have to write ":window-to-reuse same" and ":window-to-split lru"
> or something the like.

This is the most difficult part of the design - to find a good balance
between customization tags and parameters.

>> This would bring
>> them closer to the syntax of defface specs that is proven to be flexible
>> and easy to configure.
>
> If I leave in inheritance, the form above could be simplified to say
>
> (setq
>  display-buffer-alist
>  '((".*" :pop-up-window largest)
>    (".*" :pop-up-window lru)
>    ("^\\*Help\\*$" :pop-up-window-set-height fit-window-to-buffer)
>    ("^\\*.+\\*$" :pop-up-window-set-height 20)
>    (".*" :pop-up-window-min-height 15)))

This looks nicer.  But currently I don't know how expressive it will be.

Re: display-buffer-alist simplifications

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> (setq
>>  display-buffer-alist
>>  '((((regexp . ".*")) (pop-up-window (largest) (lru)))
>>    (((regexp . "^\\*Help\\*$")) (pop-up-window-set-height . fit-window-to-buffer))
>>    (((regexp . "^\\*.+\\*$")) (pop-up-window-set-height . 20))
>>    (((regexp . ".*")) (pop-up-window-min-height . 15))))
>
> This is a kind of inheritance by regexps, i.e. a set of buffer names
> matched by a stricter regexp is a subset of buffer names matched by a
> more loose regexp.  ("Inheritance" is not the right term here, but
> acceptable in a sense that a set of objects instantiated by a subclass
> is a subset of the set of all objects instantiated by its parent.)
>
>> Now the questions are whether (1) writing such specifications is useful
>> in the first place, and (2) whether such implicit inheritance is useful.
>> If they are, I don't see a way to _explicitly_ specify that *Help*
>> buffers should inherit the minimum window height from the specifier for
>> all buffers.
>
> Yes, writing such specifications is useful and "inheritance by regexps"
> is useful.  But actually I meant inheritance for named specifications
> like macro specifiers (and they are not required to use regexps).

The problem is that the design is trying to do BOTH "inheritance by
regexps" and "inheritance by specifiers" at the same time---there are
too many moving parts.


At this point, I think we really need to figure out a way to make the
system simple.  Even expressiveness must take a back seat---we can
always add expressiveness later by providing an overriding hook!

Here is one suggestion.

1) Expose all the internal "variables" currently living inside
   display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes
   and pop-up-window-min-height.

2) Make the "display methods" specifier just another one of these
   variables, e.g. call it `display-buffer-method'.

3) Change display-buffer-alist so that it is just a method of overriding
   Lisp variables during display-buffer.  That is to say, it is an alist
   where each element has the form (MATCHER . OVERRIDES).  The first
   entry with matching MATCHER takes effect; its OVERRIDES is an alist
   where each element has the form (VAR . VALUE), which says to bind VAR
   to VALUE.

   MATCHER will include matching the buffer name to a regexp, but we can
   add more complex conditionals later, e.g. a way to specify that a
   variable must have a certain value.

In this scheme, there is no interaction between elements of
display-buffer-alist, and no interaction between specifiers apart from
the familiar behavior of rebinding Lisp variables.  Martin's example
would be implemented like the following:

 (setq pop-up-window-min-height 15)

 (setq pop-up-window-choice '((largest) (lru)))

 (setq display-buffer-method '(pop-up-window))

 (setq
  display-buffer-alist
  '((((regexp . "\\`\\*Help\\*\\'"))
     (pop-up-window-set-height . fit-window-to-buffer))
    (((regexp . "\\`\\*.+\\*\\'"))
     (pop-up-window-set-height . 20))))

WDYT?

Re: display-buffer-alist simplifications

[Andy Moreton]

On Mon 01 Aug 2011, Chong Yidong wrote:
> Here is one suggestion.
>
> 1) Expose all the internal "variables" currently living inside
>    display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes
>    and pop-up-window-min-height.
>
> 2) Make the "display methods" specifier just another one of these
>    variables, e.g. call it `display-buffer-method'.
>
> 3) Change display-buffer-alist so that it is just a method of overriding
>    Lisp variables during display-buffer.  That is to say, it is an alist
>    where each element has the form (MATCHER . OVERRIDES).  The first
>    entry with matching MATCHER takes effect; its OVERRIDES is an alist
>    where each element has the form (VAR . VALUE), which says to bind VAR
>    to VALUE.
>
>    MATCHER will include matching the buffer name to a regexp, but we can
>    add more complex conditionals later, e.g. a way to specify that a
>    variable must have a certain value.
>
> In this scheme, there is no interaction between elements of
> display-buffer-alist, and no interaction between specifiers apart from
> the familiar behavior of rebinding Lisp variables.

This is a very important point, ensuring that smaller pieces can be
composed together into larger lists without changing the semantics. It
is much easier to reason about than the curent design.

>  Martin's example would be implemented like the following:
>
>  (setq pop-up-window-min-height 15)
>
>  (setq pop-up-window-choice '((largest) (lru)))
>
>  (setq display-buffer-method '(pop-up-window))
>
>  (setq
>   display-buffer-alist
>   '((((regexp . "\\`\\*Help\\*\\'"))
>      (pop-up-window-set-height . fit-window-to-buffer))
>     (((regexp . "\\`\\*.+\\*\\'"))
>      (pop-up-window-set-height . 20))))
>
> WDYT?

This proposal is much simpler to understand than the current design.
I've followed the discussion here and read the documentation several
times, and I still cannot make any sense of display-buffer-alist.

Point (3) above is important. Processing the alist only as far as the
entry with a matching MATCHER form is easier to reason about. It is also
more compositional: it allows the user to combine working alists of
specifiers together without surprising changes in the semantics of the
constituent pieces.

    AndyM

Re: display-buffer-alist simplifications

[martin rudalics]

 > 1) Expose all the internal "variables" currently living inside
 >    display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes
 >    and pop-up-window-min-height.

I suppose that what you mean here is to rewrite Emacs 23 options like
`even-window-heights' and `split-height-threshold' where applicable.
These values would serve as the default values for any buffer, that is,
there would be no distinction between *Help* and *Info* buffers wrt the
minimum height of their windows, I presume.  Then the applications could
override this by their plists and `display-buffer-alist' would override
the application's and the default values.  Is that correct?

One idea of `display-buffer-alist' was to concentrate all display buffer
related variables into one and make any additions inside that variable.
A basic drawback of the <= Emacs 23 approach was that we always added
variables like `display-buffer-reuse-frames' and
`display-buffer-mark-dedicated' with very ad hoc semantics many people
don't understand.  (Maybe I exaggerate here but at least I don't
understand them as recent problems with reusing frames and marking
reused windows as dedicated shows.)

Personally, I hardly ever had problems with displaying buffers because I
don't do that often.  So if people agree that exposing these variables
is TRT I can principally do that.  For this purpose we'd first have to
go through each of these variables and decide

(1) on a suitbale name (and possibly any aliases), and

(2) whether and what should be changed in the possible values and how to
     represent them.

Finally we'd have to decide what to do about options that don't exist
yet like `pop-up-window-set-height'.

What I probably cannot do is incorporating buffer specific options like
`special-display-regexps' into this scheme.  These apply individually to
buffers and do require the merge-in behavior of things like
`even-window-heights' you probably want to avoid by exposing the
internal variables.  I'm obviously all ears for any suggestions how to
do that.  (If there are any doubts about why these are problems recall
that `display-buffer-alist' is nothing else but a generalization of
`special-display-regexps' and `special-display-buffer-names'.)

 > 2) Make the "display methods" specifier just another one of these
 >    variables, e.g. call it `display-buffer-method'.

Would this discriminate buffers via regexps and how would you apply the
"try reusing a window and if that fails pop up a new one ..." here?  I
assume you'll say "no" to both of them.

 > 3) Change display-buffer-alist so that it is just a method of overriding
 >    Lisp variables during display-buffer.  That is to say, it is an alist
 >    where each element has the form (MATCHER . OVERRIDES).  The first
 >    entry with matching MATCHER takes effect; its OVERRIDES is an alist
 >    where each element has the form (VAR . VALUE), which says to bind VAR
 >    to VALUE.
 >    MATCHER will include matching the buffer name to a regexp, but we can
 >    add more complex conditionals later, e.g. a way to specify that a
 >    variable must have a certain value.
 >
 > In this scheme, there is no interaction between elements of
 > display-buffer-alist, and no interaction between specifiers apart from
 > the familiar behavior of rebinding Lisp variables.  Martin's example
 > would be implemented like the following:
 >
 >  (setq pop-up-window-min-height 15)
 >
 >  (setq pop-up-window-choice '((largest) (lru)))
 >
 >  (setq display-buffer-method '(pop-up-window))
 >
 >  (setq
 >   display-buffer-alist
 >   '((((regexp . "\\`\\*Help\\*\\'"))
 >      (pop-up-window-set-height . fit-window-to-buffer))
 >     (((regexp . "\\`\\*.+\\*\\'"))
 >      (pop-up-window-set-height . 20))))

Could you give an example of how to specify reusing a window along these
lines?  And of how to specify the above mentioned "try reusing a window
and if that fails pop up a new one ..."?

Would we write, for example,

   (setq display-buffer-method '(pop-up-window reuse-window))

If so how would we express to first find another window showing the same
buffer and then another window showing another buffer?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

> don't understand.  (Maybe I exaggerate here but at least I don't
> understand them as recent problems with reusing frames and marking
> reused windows as dedicated shows.)

This had nothing to do with display-buffer-mark-dedicate: when we re-use
a window for a new buffer, clearly that window is not dedicated to that
buffer, since it was used for something else already.

Maybe there are cases where you might want to hijack a non-dedicated
window to show some buffer and make it dedicated, but that sounds like
a very rare case (I haven't seen such a use-case yet).  "Dedicated"
means "it's only used for that buffer".


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > This had nothing to do with display-buffer-mark-dedicate: when we re-use
 > a window for a new buffer, clearly that window is not dedicated to that
 > buffer, since it was used for something else already.
 >
 > Maybe there are cases where you might want to hijack a non-dedicated
 > window to show some buffer and make it dedicated, but that sounds like
 > a very rare case (I haven't seen such a use-case yet).  "Dedicated"
 > means "it's only used for that buffer".

IIUC you mark the window as weakly dedicated which means that
`switch-to-buffer' can use it for showing another buffer.

martin

Re: display-buffer-alist simplifications

[Nix]

On 3 Aug 2011, martin rudalics uttered the following:

> IIUC you mark the window as weakly dedicated which means that
> `switch-to-buffer' can use it for showing another buffer.

Just checking: the important thing here is that it can be used for
showing another buffer, but only by hand: `display-buffer' won't
select it, nor will it resize it?

-- 
NULL && (void)

Re: display-buffer-alist simplifications

[martin rudalics]

 >> IIUC you mark the window as weakly dedicated which means that
 >> `switch-to-buffer' can use it for showing another buffer.
 >
 > Just checking: the important thing here is that it can be used for
 > showing another buffer, but only by hand: `display-buffer' won't
 > select it, nor will it resize it?

If a window is weakly dedicated, `display-buffer' based functions are
not allowed to show another buffer in it (neither selection nor resizing
are affected by this).  If the window is strongly dedicated,
`set-window-buffer' based functions are not allowed to show another
buffer in it which means that virtually no function can.

The Elisp manual section on windows has an entire section devoted to
this subject.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> This had nothing to do with display-buffer-mark-dedicated: when we re-use
>> a window for a new buffer, clearly that window is not dedicated to that
>> buffer, since it was used for something else already.
>> 
>> Maybe there are cases where you might want to hijack a non-dedicated
>> window to show some buffer and make it dedicated, but that sounds like
>> a very rare case (I haven't seen such a use-case yet).  "Dedicated"
>> means "it's only used for that buffer".

> IIUC you mark the window as weakly dedicated which means that
> `switch-to-buffer' can use it for showing another buffer.

I'm not sure what you refer to, but In Emacs≤23, a window was only ever
marked dedicated (weakly or strongly) upon creation, never when reused.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >>> "Dedicated"
 >>> means "it's only used for that buffer".
 >
 >> IIUC you mark the window as weakly dedicated which means that
 >> `switch-to-buffer' can use it for showing another buffer.
 >
 > I'm not sure what you refer to, but In Emacs≤23, a window was only ever
 > marked dedicated (weakly or strongly) upon creation, never when reused.

Simply that if a window is weakly dedicated, the meaning of "dedicated"
cited at the top disagrees with the actual meaning.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>>> "Dedicated" means "it's only used for that buffer".
>>> IIUC you mark the window as weakly dedicated which means that
>>> `switch-to-buffer' can use it for showing another buffer.
>> I'm not sure what you refer to, but In Emacs≤23, a window was only ever
>> marked dedicated (weakly or strongly) upon creation, never when reused.
> Simply that if a window is weakly dedicated, the meaning of "dedicated"
> cited at the top disagrees with the actual meaning.

Not quite: whenever the soft-dedication is overridden, the window is (at
least should be, barring any bug) un-dedicated.  So, as long as it's
dedicated "it's only used for that buffer".


        Stefan

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> I suppose that what you mean here is to rewrite Emacs 23 options like
> `even-window-heights' and `split-height-threshold' where applicable.
> These values would serve as the default values for any buffer, that is,
> there would be no distinction between *Help* and *Info* buffers wrt the
> minimum height of their windows, I presume.  Then the applications could
> override this by their plists and `display-buffer-alist' would override
> the application's and the default values.  Is that correct?
>
> One idea of `display-buffer-alist' was to concentrate all display
> buffer related variables into one and make any additions inside that
> variable.  A basic drawback of the <= Emacs 23 approach was that we
> always added variables like `display-buffer-reuse-frames' and
> `display-buffer-mark-dedicated' with very ad hoc semantics many people
> don't understand.

Fair enough.  So use `display-buffer-fallback-alist' as Juri said.  The
main point is to make it so that (i) display specifiers behave like
familiar old variable binding, and (ii) there is an easy way to set the
default without introducing complex merging sematics.

OTOH, this can be implemented internally as local vars---concatenate all
the alists from the display-buffer-alist, the display-buffer arg, and
display-buffer-fallback-alist into one big alist, then do a
destructuring-bind.

> Any such thing like `display-buffer-fallback-alist' has to cope with
> the variables `special-display-buffer-names' and
> `special-display-regexps' which may prescribe individual behavior
> based on the names of buffers.  There is no "global" default value for
> all buffers unless we are prepared to sacrifice compatibility with
> Emacs 23.

We can specify that these old variables override the new behavior,
i.e. `display-buffer-fallback-alist' only applies to buffers not
matching `special-display-buffer-names'.

>> 2) Make the "display methods" specifier just another one of these
>>    variables, e.g. call it `display-buffer-method'.
>
> Would this discriminate buffers via regexps and how would you apply
> the "try reusing a window and if that fails pop up a new one ..."
> here?
>
> Would we write, for example,
>
>   (setq display-buffer-method '(pop-up-window reuse-window))
>
> If so how would we express to first find another window showing the
> same buffer and then another window showing another buffer?

One way would be to allow display-buffer-method to be a list of macro
specifiers, e.g. something like:

  (setq display-buffer-fallback-alist
    '((display-buffer-method (other-window-same-buffer other-window))))

  (setq display-buffer-macro-specifiers
    '((other-window-same-buffer
       (display-buffer-method reuse-window)
       (reuse-window-buffer same)
       (reuse-window-window other))
      (other-window
       (display-buffer-method reuse-window)
       (reuse-window-window other))

Re: display-buffer-alist simplifications

[martin rudalics]

 > Fair enough.  So use `display-buffer-fallback-alist' as Juri said.  The
 > main point is to make it so that (i) display specifiers behave like
 > familiar old variable binding, and (ii) there is an easy way to set the
 > default without introducing complex merging sematics.
...
 > We can specify that these old variables override the new behavior,
 > i.e. `display-buffer-fallback-alist' only applies to buffers not
 > matching `special-display-buffer-names'.

In Emacs 23 a user can specify that a buffer shall be displayed in the
selected window by adding its name to `same-window-buffer-names'.  An
application can override the user by binding `same-window-buffer-names'
temporarily to nil.  We have to offer a similar feature in Emacs 24.

Currently this can be done by setting `display-buffer-alist' from
`same-window-buffer-names' via `display-buffer-alist-set'.  But how
would we do that with `display-buffer-fallback-alist'?  If we add the
value to `display-buffer-fallback-alist' then the latter must be fully
customizable just as `display-buffer-alist'.  If we add the value to
`display-buffer-alist' itself it can't be overridden by the application.
If we let applications bind `display-buffer-alist' there's no sense in
supplying an argument in the first place.

 >> If so how would we express to first find another window showing the
 >> same buffer and then another window showing another buffer?
 >
 > One way would be to allow display-buffer-method to be a list of macro
 > specifiers, e.g. something like:
 >
 >   (setq display-buffer-fallback-alist
 >     '((display-buffer-method (other-window-same-buffer other-window))))
 >
 >   (setq display-buffer-macro-specifiers
 >     '((other-window-same-buffer
 >        (display-buffer-method reuse-window)
 >        (reuse-window-buffer same)
           ^^^^^^^^^^^^^^^^^^^

Would such a naming scheme suit you?

 >        (reuse-window-window other))
 >       (other-window
 >        (display-buffer-method reuse-window)
 >        (reuse-window-window other))

Basically, this means to shift complexity from `display-buffer-alist' to
`display-buffer-macro-specifiers' which sounds reasonable.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> We can specify that these old variables override the new behavior,
>> i.e. `display-buffer-fallback-alist' only applies to buffers not
>> matching `special-display-buffer-names'.
>
> In Emacs 23 a user can specify that a buffer shall be displayed in the
> selected window by adding its name to `same-window-buffer-names'.  An
> application can override the user by binding `same-window-buffer-names'
> temporarily to nil.  We have to offer a similar feature in Emacs 24.
>
> Currently this can be done by setting `display-buffer-alist' from
> `same-window-buffer-names' via `display-buffer-alist-set'.  But how
> would we do that with `display-buffer-fallback-alist'?

IIUC, the intention of same-window-buffer-names is to specify that such
buffers should appear in the "same" window.  But if the argument to
display-buffer specifies some other method for displaying the buffer,
Emacs should obey that argument rather than same-window-buffer-names.

So, this can be handled by

  (setq display-buffer-fallback-alist
    '("\\*\\(shell\\|unsent mail\\|mail\\|inferior-lisp\\|ielm\\)\\*"
      (display-buffer-method reuse-window same-frame)
      (reuse-window-window same)))

Just to be sure we are one the same page, here is how I imagine the
system would work:

 - "Display specifiers" are cons cells (VAR . VALUE).  For example,
   (reuse-window-window other) means that when Emacs is trying to reuse
   a window, it must use a window other than the selected one.

 - `display-buffer-method' is a special display specifier.  Its VALUE is
   a list of "display-methods", one of `reuse-window', `pop-up-window',
   etc., or a "macro specifier" (any symbol except the reserved symbols
   `reuse-window' etc).

   (I'll use the word "macro" for now, but we might want to pick another
   word since "macro" can be confused with keyboard macros.)

 - `display-buffer-alist' is an alist that maps a matcher (regexp,
   label, or matcher function) to an alist of display specifiers.

 - `display-buffer-fallback-alist' is an alist of display specifiers.

 - `display-buffer-macro-specifiers' is an alist that maps a "macro
   specifier" to an alist of display specifiers.  It must include a
   `display-buffer-method' specifier.

 - The action of `display-buffer' can be conceptually described this
   way:

   1. Construct an alist of display specifiers by appending (in order)
      (a) the first matching display specifier alist found in
      `display-buffer-alist', if any
      (b) the SPECIFIERS argument
      (c) `display-buffer-fallback-alist'

   2. Get the value of the `display-buffer-macro-specifiers' specifier
      from this alist.

   3. Iterate through the list of specified methods, trying to display
      with each method, obeying specifiers such as `reuse-window-window'
      drawn from the constructed alist.  If the method fails, try the
      next method in the list.  If it succeeds, stop.

   4. If one of the methods is a macro specifier, add that macro's
      specifier alist "temporarily" to the front of the constructed
      alist.  Then look up `display-buffer-macro-specifiers' again, and
      iterate again through that list, as in step 3.  The "macro" fails
      iff all of its `display-buffer-macro-specifiers' fail.

Re: display-buffer-alist simplifications

[martin rudalics]

 > IIUC, the intention of same-window-buffer-names is to specify that such
 > buffers should appear in the "same" window.  But if the argument to
 > display-buffer specifies some other method for displaying the buffer,
 > Emacs should obey that argument rather than same-window-buffer-names.
 >
 > So, this can be handled by
 >
 >   (setq display-buffer-fallback-alist
 >     '("\\*\\(shell\\|unsent mail\\|mail\\|inferior-lisp\\|ielm\\)\\*"
 >       (display-buffer-method reuse-window same-frame)
 >       (reuse-window-window same)))

Aha ... so the fallback alist must discriminate buffer names (you didn't
tell me so far how it should look like).

 > Just to be sure we are one the same page, here is how I imagine the
 > system would work:
 >
 >  - "Display specifiers" are cons cells (VAR . VALUE).  For example,
 >    (reuse-window-window other) means that when Emacs is trying to reuse
 >    a window, it must use a window other than the selected one.

If we can manage to get this conveniently and consistently it would be a
great improvement.  I already explained to Stefan that I was too silly
to get this part right (IMHO, a term like "reuse-window-window" is very
easy to mistype as "reuse-window").

 >  - `display-buffer-method' is a special display specifier.

Good.  I haven't yet explored all possible misuses of this but it makes
it clear that the stuff that follows is a method.  This is, admittedly,
not clear in my design.

 >    Its VALUE is
 >    a list of "display-methods", one of `reuse-window', `pop-up-window',
 >    etc., or a "macro specifier" (any symbol except the reserved symbols
 >    `reuse-window' etc).
 >
 >    (I'll use the word "macro" for now, but we might want to pick another
 >    word since "macro" can be confused with keyboard macros.)

I'd very much appreciate if someone could invent a more useful term for
these.

 >  - `display-buffer-alist' is an alist that maps a matcher (regexp,
 >    label, or matcher function) to an alist of display specifiers.

OK.  I slowly begin to understand what a matcher function could be like.

 >  - `display-buffer-fallback-alist' is an alist of display specifiers.

OK.  I don't like the name much (I would rather call the other one
something like `display-buffer-overriding-alist' and the fallback one
`display-buffer-alist' but that's a minor issue).

 >  - `display-buffer-macro-specifiers' is an alist that maps a "macro
 >    specifier" to an alist of display specifiers.  It must include a
 >    `display-buffer-method' specifier.

OK.  We have to invent a mechanism that makes `display-buffer' work even
if someone removes more essential associations from the list.  The
SPECIFIERS argument below should be able to reference it safely.

 >  - The action of `display-buffer' can be conceptually described this
 >    way:
 >
 >    1. Construct an alist of display specifiers by appending (in order)
 >       (a) the first matching display specifier alist found in
 >       `display-buffer-alist', if any
 >       (b) the SPECIFIERS argument

... if any ...

 >       (c) `display-buffer-fallback-alist'

Good.  Would `display-buffer-fallback-alist' be constructed from the
user's Emacs 23 options, from the Emacs 23 default options, or be nil?

 >    2. Get the value of the `display-buffer-macro-specifiers' specifier
 >       from this alist.
 >
 >    3. Iterate through the list of specified methods, trying to display
 >       with each method, obeying specifiers such as `reuse-window-window'
 >       drawn from the constructed alist.  If the method fails, try the
 >       next method in the list.  If it succeeds, stop.
 >
 >    4. If one of the methods is a macro specifier, add that macro's
 >       specifier alist "temporarily" to the front of the constructed
 >       alist.  Then look up `display-buffer-macro-specifiers' again, and
 >       iterate again through that list, as in step 3.

Here you mean to not expand all macro specifiers at call time but lazily
when needed.

 >       The "macro" fails
 >       iff all of its `display-buffer-macro-specifiers' fail.

OK.

I'm still not sure where the `even-window-heights' stuff would go
though.  IIUC it must be by default present in each and every macro
specifier that reuses any window but the selected one.  Same for the
minimum height/width specifiers.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> For example, (reuse-window-window other) means that when Emacs is
>> trying to reuse a window, it must use a window other than the
>> selected one.
> If we can manage to get this conveniently and consistently it would be a
> great improvement.  I already explained to Stefan that I was too silly
> to get this part right (IMHO, a term like "reuse-window-window" is very
> easy to mistype as "reuse-window").

>> - `display-buffer-method' is a special display specifier.
> Good.  I haven't yet explored all possible misuses of this but it makes
> it clear that the stuff that follows is a method.  This is, admittedly,
> not clear in my design.

>> Its VALUE is a list of "display-methods", one of `reuse-window',
>> `pop-up-window', etc., or a "macro specifier" (any symbol except the
>> reserved symbols `reuse-window' etc).

I'd make a "display method" be a function, i.e. one of
`display-buffer-reuse-window', `display-buffer-pop-up-window', ...
At which point you can get rid of the idea of a "macro specifier" since
function definitions work just as well.

>> (I'll use the word "macro" for now, but we might want to pick another
>> word since "macro" can be confused with keyboard macros.)
> I'd very much appreciate if someone could invent a more useful term for
> these.

The name exists already, it's called a function definition.  It's really
well supported by a lot of Emacs code: you can document those "macros"
in a very simple way, let users get that doc via C-h f, see them work
step by step with edebug, have feedback about their correctness/style
with M-x byte-compile-file, ...

>> - `display-buffer-alist' is an alist that maps a matcher (regexp,
>> label, or matcher function) to an alist of display specifiers.

If display specifiers are of the form (VAR . VAL), then you presumably
mean "a list of display specifiers" rather than "an alist of ...".

>> - `display-buffer-macro-specifiers' is an alist that maps a "macro
>> specifier" to an alist of display specifiers.  It must include a
>> `display-buffer-method' specifier.
> OK.  We have to invent a mechanism that makes `display-buffer' work even
> if someone removes more essential associations from the list.  The
> SPECIFIERS argument below should be able to reference it safely.

I hope by now you all know what I think of "macro specifiers".

> Good.  Would `display-buffer-fallback-alist' be constructed from the
> user's Emacs 23 options, from the Emacs 23 default options, or be nil?

I think that, as much as possible, the old options should only be used
by the old code.  Trying to translate them into the new framework is
generally a bad idea.  Especially if it may end up influencing the end
design: let's first design something clean and flexible regardless of
details of the old behavior.  Then figure out how to provide backward
compatibility, without impacting the design.

>> 3. Iterate through the list of specified methods, trying to display
>> with each method, obeying specifiers such as `reuse-window-window'
>> drawn from the constructed alist.  If the method fails, try the
>> next method in the list.  If it succeeds, stop.

So, as is the case now, your list of specifiers is not truly an alist
(i.e. earlier elements don't override later elements), instead it's
a mix between an alist and an `or block'?
That sounds like a problem.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > I'd make a "display method" be a function, i.e. one of
 > `display-buffer-reuse-window', `display-buffer-pop-up-window', ...
 > At which point you can get rid of the idea of a "macro specifier" since
 > function definitions work just as well.

At which point you can give up the idea of merging.  I meanwhile know
that no one here likes the idea of merging specifiers and don't have the
slightest intention to fight for it any more.  But no one so far has
cared to explain how to support all the things people have piled up over
the years like split-height-threshold, even-window-heights, or
display-buffer-mark-dedicated.  I'd be all in favor of functions if you
told me how to write a function that within a year has not been
rewritten completely because it's oh so important to add a little thingy
here and there.

 >>> (I'll use the word "macro" for now, but we might want to pick another
 >>> word since "macro" can be confused with keyboard macros.)
 >> I'd very much appreciate if someone could invent a more useful term for
 >> these.
 >
 > The name exists already, it's called a function definition.  It's really
 > well supported by a lot of Emacs code: you can document those "macros"
 > in a very simple way, let users get that doc via C-h f, see them work
 > step by step with edebug, have feedback about their correctness/style
 > with M-x byte-compile-file, ...

We currently have many ways to specify a function for displaying a
buffer: `display-buffer-function', `special-display-function',
`pop-up-frame-function', `split-window-preferred-function', the function
one can specify via `special-display-regexps'.  I know of two people who
customized the latter - Drew and you.  This doesn't strike me as a story
of success.

 >>> - `display-buffer-alist' is an alist that maps a matcher (regexp,
 >>> label, or matcher function) to an alist of display specifiers.
 >
 > If display specifiers are of the form (VAR . VAL), then you presumably
 > mean "a list of display specifiers" rather than "an alist of ...".

It's an alist where the key of each element is a display specifier.

 >>> - `display-buffer-macro-specifiers' is an alist that maps a "macro
 >>> specifier" to an alist of display specifiers.  It must include a
 >>> `display-buffer-method' specifier.
 >> OK.  We have to invent a mechanism that makes `display-buffer' work even
 >> if someone removes more essential associations from the list.  The
 >> SPECIFIERS argument below should be able to reference it safely.
 >
 > I hope by now you all know what I think of "macro specifiers".

They are what macros are: Rewrite rules for the users' convenience.

 >> Good.  Would `display-buffer-fallback-alist' be constructed from the
 >> user's Emacs 23 options, from the Emacs 23 default options, or be nil?
 >
 > I think that, as much as possible, the old options should only be used
 > by the old code.  Trying to translate them into the new framework is
 > generally a bad idea.  Especially if it may end up influencing the end
 > design: let's first design something clean and flexible regardless of
 > details of the old behavior.  Then figure out how to provide backward
 > compatibility, without impacting the design.

OK.  I agree with the idea to support the old code and its options as
fallback and try to get a new behavior.  But what I'm missing is a
strategy for how to merge-in the re-bindings of the old options within
the old _and_ the new code.  Things like

(defun message-mail-other-window (&optional to subject)
   "Like `message-mail' command, but display mail buffer in another window."
   (interactive)
   (unless (message-mail-user-agent)
     (let ((pop-up-windows t)
	  (special-display-buffer-names nil)
	  (special-display-regexps nil)
	  (same-window-buffer-names nil)
	  (same-window-regexps nil))
       (message-pop-to-buffer (message-buffer-name "mail" to))))

which I intended to rewrite as

(defun message-mail-other-window (&optional to subject)
   "Like `message-mail' command, but display mail buffer in another window."
   (interactive)
   (unless (message-mail-user-agent)
     (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

would then become

(defun message-mail-other-window (&optional to subject)
   "Like `message-mail' command, but display mail buffer in another window."
   (interactive)
   (unless (message-mail-user-agent)
     (let ((pop-up-windows t)
	  (special-display-buffer-names nil)
	  (special-display-regexps nil)
	  (same-window-buffer-names nil)
	  (same-window-regexps nil))
       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

for approximately as long as how we are supporting the old code.

Or am I missing something?

 > So, as is the case now, your list of specifiers is not truly an alist
 > (i.e. earlier elements don't override later elements), instead it's
 > a mix between an alist and an `or block'?
 > That sounds like a problem.

If someone told me how to address the problem of merging specifiers in a
different way I'd be all ears.  So far people addressed purely cosmetic
issues like using a function instead of a macro or a plist instead of an
alist.

martin

Re: display-buffer-alist simplifications

[Andreas Röhler]

Am 08.08.2011 11:10, schrieb martin rudalics:
>  > I'd make a "display method" be a function, i.e. one of
>  > `display-buffer-reuse-window', `display-buffer-pop-up-window', ...
>  > At which point you can get rid of the idea of a "macro specifier" since
>  > function definitions work just as well.
>
> At which point you can give up the idea of merging. I meanwhile know
> that no one here likes the idea of merging specifiers and don't have the
> slightest intention to fight for it any more. But no one so far has
> cared to explain how to support all the things people have piled up over
> the years like split-height-threshold, even-window-heights, or
> display-buffer-mark-dedicated. I'd be all in favor of functions if you
> told me how to write a function that within a year has not been
> rewritten completely because it's oh so important to add a little thingy
> here and there.


Hi Martin,

can't take part in this discussion now for several reasons.

However let me say your remarks meet my experience with a lot of Emacs 
stuff. Consider all effort of cleaning that up as crucial, as 
difficulties must rise otherwise.

Thanks all,

Andreas

Re: display-buffer-alist simplifications

[Juri Linkov]

> At which point you can give up the idea of merging.  I meanwhile know
> that no one here likes the idea of merging specifiers and don't have the
> slightest intention to fight for it any more.  But no one so far has
> cared to explain how to support all the things people have piled up over
> the years like split-height-threshold, even-window-heights, or
> display-buffer-mark-dedicated.

Currently the following layers are planned:

1. default global behavior
2. old user settings
3. application specifiers
4. new user specifiers

We should keep the old mess in 2 for backward-compatibility
and design a new clean and simply way to specify 3 and 4, so
we don't need to merge new specifiers with old user settings in 2,
because new specifiers just override the old user settings.

> would then become
>
> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (let ((pop-up-windows t)
> 	  (special-display-buffer-names nil)
> 	  (special-display-regexps nil)
> 	  (same-window-buffer-names nil)
> 	  (same-window-regexps nil))
>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))
>
> for approximately as long as how we are supporting the old code.

Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg
over the old settings in `same-window-regexps' etc.?  IOW, when the
`SPECIFIERS' arg is `other-window' then `display-buffer' should ignore
the values of `same-window-regexps' etc.

Re: display-buffer-alist simplifications

[martin rudalics]

 > Currently the following layers are planned:
 >
 > 1. default global behavior
 > 2. old user settings
 > 3. application specifiers
 > 4. new user specifiers
 >
 > We should keep the old mess in 2 for backward-compatibility
 > and design a new clean and simply way to specify 3 and 4, so
 > we don't need to merge new specifiers with old user settings in 2,
 > because new specifiers just override the old user settings.

With the scheme sketched above users have no chance to specify what they
want when they want to use the new design _and_ respect the application
specifiers.  When they set the new specifiers they would override the
application.

 >> would then become
 >>
 >> (defun message-mail-other-window (&optional to subject)
 >>   "Like `message-mail' command, but display mail buffer in another window."
 >>   (interactive)
 >>   (unless (message-mail-user-agent)
 >>     (let ((pop-up-windows t)
 >> 	  (special-display-buffer-names nil)
 >> 	  (special-display-regexps nil)
 >> 	  (same-window-buffer-names nil)
 >> 	  (same-window-regexps nil))
 >>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))
 >>
 >> for approximately as long as how we are supporting the old code.
 >
 > Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg
 > over the old settings in `same-window-regexps' etc.?  IOW, when the
 > `SPECIFIERS' arg is `other-window' then `display-buffer' should ignore
 > the values of `same-window-regexps' etc.

Because this would change the behavior of `display-buffer' for users who
prefer good ol' `display-buffer'.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> We should keep the old mess in 2 for backward-compatibility
>> and design a new clean and simply way to specify 3 and 4, so
>> we don't need to merge new specifiers with old user settings in 2,
>> because new specifiers just override the old user settings.
> With the scheme sketched above users have no chance to specify what they
> want when they want to use the new design _and_ respect the application
> specifiers.  When they set the new specifiers they would override the
> application.

Yes, and I think that's fine.  We may want to provide a 5th level for
elisp code that lets it override user settings.  This could then be used
for things like C-x 4 and C-x 5 which are ways for the user to say
"please override my own settings".

For the `not-this-window' behavior, I'm still not sure how best to
do it.  My current idea is to redefine RULEs from (FUNCTION . ARGS) to
(FUNCTION . ALIST), and then FUNCTION called is the one from the highest
precedence, and the ALIST passed to it is the concatenation of all the
ALISTs (the one from display-buffer-default-rule, plus the one from the
caller, plus the one from display-buffer-alist, plus the one from
display-buffer-override-rule), and `not-this-window' would be one of the
possible ALIST keys.  So if it's provided by the caller it will appear
as arg to FUNCTION, unless it's explicitly overridden by
a (not-this-window . nil) element in the display-buffer-alist.

>> Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg
>> over the old settings in `same-window-regexps' etc.?  IOW, when the
>> `SPECIFIERS' arg is `other-window' then `display-buffer' should ignore
>> the values of `same-window-regexps' etc.
> Because this would change the behavior of `display-buffer' for users who
> prefer good ol' `display-buffer'.

It should only change the behavior for calls to display-buffer which use
the new RULE/SPECIFIER parameter or for users who set
display-buffer-alist.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > My current idea is to redefine RULEs from (FUNCTION . ARGS) to
 > (FUNCTION . ALIST), and then FUNCTION called is the one from the highest
 > precedence, and the ALIST passed to it is the concatenation of all the
 > ALISTs (the one from display-buffer-default-rule, plus the one from the
 > caller, plus the one from display-buffer-alist, plus the one from
 > display-buffer-override-rule), and `not-this-window' would be one of the
 > possible ALIST keys.  So if it's provided by the caller it will appear
 > as arg to FUNCTION, unless it's explicitly overridden by
 > a (not-this-window . nil) element in the display-buffer-alist.

I begin to wonder how this differs from the current handling of
`display-buffer-alist'.

 >>> Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg
 >>> over the old settings in `same-window-regexps' etc.?  IOW, when the
 >>> `SPECIFIERS' arg is `other-window' then `display-buffer' should ignore
 >>> the values of `same-window-regexps' etc.
 >> Because this would change the behavior of `display-buffer' for users who
 >> prefer good ol' `display-buffer'.
 >
 > It should only change the behavior for calls to display-buffer which use
 > the new RULE/SPECIFIER parameter

So when an application sets the argument, people who want the old
behavior are overridden.  This means that such people can use
`message-mail' as before but any of their customizations affecting
`message-mail-other-window' or `message-mail-other-frame' are lost.

 > or for users who set
 > display-buffer-alist.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> My current idea is to redefine RULEs from (FUNCTION . ARGS) to
>> (FUNCTION . ALIST), and then FUNCTION called is the one from the highest
>> precedence, and the ALIST passed to it is the concatenation of all the
>> ALISTs (the one from display-buffer-default-rule, plus the one from the
>> caller, plus the one from display-buffer-alist, plus the one from
>> display-buffer-override-rule), and `not-this-window' would be one of the
>> possible ALIST keys.  So if it's provided by the caller it will appear
>> as arg to FUNCTION, unless it's explicitly overridden by
>> a (not-this-window . nil) element in the display-buffer-alist.
> I begin to wonder how this differs from the current handling of
> `display-buffer-alist'.

Here are the difference I see:
- use functions rather than a finite set of symbols.
- handle the FUNCTION or FUNCTIONS (i.e. the list of methods to use/try)
  separately from the other arguments, i.e. separate the part which is
  tried in sequence from the part that's handled as an alist.

> So when an application sets the argument, people who want the old
> behavior are overridden.  This means that such people can use
> `message-mail' as before but any of their customizations affecting
> `message-mail-other-window' or `message-mail-other-frame' are lost.

Yes (unless message-mail-other-window keeps using the old let-binding
horror, of course).


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > Here are the difference I see:
 > - use functions rather than a finite set of symbols.

Not really a difference because `display-buffer-alist' provides the
function specifier.

 > - handle the FUNCTION or FUNCTIONS (i.e. the list of methods to use/try)
 >   separately from the other arguments, i.e. separate the part which is
 >   tried in sequence from the part that's handled as an alist.

Indeed.  These are strongly tied in `display-buffer-alist'.

 >> So when an application sets the argument, people who want the old
 >> behavior are overridden.  This means that such people can use
 >> `message-mail' as before but any of their customizations affecting
 >> `message-mail-other-window' or `message-mail-other-frame' are lost.
 >
 > Yes (unless message-mail-other-window keeps using the old let-binding
 > horror, of course).

With customization I meant that so far they can make
`message-mail-other-window' use another frame by setting `pop-up-frames'
to t.  This won't be possible any more.

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> Here are the difference I see:

In the mean time I thought of 2 more:
- all the args to the display methods are in the ALIST rather than
  having some in the ALIST and some bundled with the display method.
- the display method has to handle everything, there's no common/shared
  postprocessing.

>> - use functions rather than a finite set of symbols.
> Not really a difference because `display-buffer-alist' provides the
> function specifier.

I know, but what I meant is that everything is handled through the
FUNCTION case.

>>> So when an application sets the argument, people who want the old
>>> behavior are overridden.  This means that such people can use
>>> `message-mail' as before but any of their customizations affecting
>>> `message-mail-other-window' or `message-mail-other-frame' are lost.
>> Yes (unless message-mail-other-window keeps using the old let-binding
>> horror, of course).
> With customization I meant that so far they can make
> `message-mail-other-window' use another frame by setting `pop-up-frames'
> to t.  This won't be possible any more.

Yes, that's what I understood, and I think that's OK.
If we don't like that, we can make display-buffer-other-window obey
pop-up-frames as well.  But such supplemental backward compatibility
should only be added on a case-by-case basis.  And I'd much rather
provide "other-window-prefix" and "other-frame-prefix" commands so that
when people ask for such compatibility we can tell us: here's the new,
better way to do it.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > In the mean time I thought of 2 more:
 > - all the args to the display methods are in the ALIST rather than
 >   having some in the ALIST and some bundled with the display method.
 > - the display method has to handle everything, there's no common/shared
 >   postprocessing.

Using a more operational reasoning I see the differences as follows:

After "normalizing" specifiers (stripping buffer identifers and
expanding "macro specifiers") my specifiers boil down to an alist of say
methods (M) and parameters (P) like

((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...))

This alist was produced by concatening the overriding (O), application
provided (A), and non-overriding specifiers (N, where this group
contains in its tail the specifiers produced by the old buffer display
options) as indicated below

((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

This alist is processed by taking the first method specifier and
handling _all_ following parameters just like frame alists - the first
parameter value that is found is taken.  If the first method fails, the
next method is tried as

((M ...) (M ...) (P ...) (M ...) (P ...) (P ...))
  OOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

then the next method as

((M ...) (P ...) (M ...) (P ...) (P ...))
  AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

and if everything failed till here the last method as

((M ...) (P ...) (P ...))
  NNNNNNNNNNNNNNNNNNNNNNN


The other proposals I have seen here ask for using something I would
describe as a list of alists like

(((M ...) (P ...) (P ...) (P ...))
  ((M ...) (P ...))
  ((M ...) (P ...) (P ...)))

where, if a method specifier matches, _only_ the parameters provided
together with that specifier are processed.  That means you process

((M ...) (P ...) (P ...) (P ...))

first, if that fails

((M ...) (P ...))

and finally

((M ...) (P ...) (P ...))


IIUC I've also seen

(((M ...) (M ...) (P ...) (P ...) (P ...))
  ((M ...) (M ...) (M ...) (P ...)))

such that two or more methods may share the same parameters, maybe also
written as

((((M ...) (M ...)) . ((P ...) (P ...) (P ...)))
  (((M ...) (M ...)) . ((M ...) (P ...))))


Also dismissing non-overriding specifiers and handling old buffer
display options (D) has been proposed like

(((M ...) (P ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  ((M ...) (P ...))
  AAAAAAAAAAAAAAAAA
  ((M ...) (P ...) (P ...))
  DDDDDDDDDDDDDDDDDDDDDDDDD
)

where I'm still not able to see how to

(1) Respect the application _and_ supply user parameters.

(2) Respect the application _and_ supply parameters resulting from old
     user options.

both of which I've called merging here.


Finally, I've seen a very high priority application provided level of
specifiers (H) which would appear as

(((M ...) (P ...))
  HHHHHHHHHHHHHHHHH
  ((M ...) (P ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  ((M ...) (P ...))
  AAAAAAAAAAAAAAAAA
  ((M ...) (P ...) (P ...))
  DDDDDDDDDDDDDDDDDDDDDDDDD
)


Does this approximately describe the current state of affairs?  I've
deliberately dismissed things I consider sugar like whether methods
represent functions or just symbols to look up functions, or whether a
parameter actually is a condition enabling a method (like a window's
minimum height) rather then ask for some kind of post-action (like
setting a window's height).

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

> Does this approximately describe the current state of affairs?  I've
> deliberately dismissed things I consider sugar like whether methods
> represent functions or just symbols to look up functions, or whether a
> parameter actually is a condition enabling a method (like a window's
> minimum height) rather then ask for some kind of post-action (like
> setting a window's height).

Not quite. Here's my take on display-buffer-alist:

  (defvar display-buffer-alist nil
    "Specifications of user preferences for `display-buffer'.
  This is a list of elements of the form (CONDITION . ACTION)
  where CONDITION is either a regexp matching buffer names, or a function
  that takes a buffer and returns a boolean.
  ACTION is a list of the form (FUNCTION . ALIST) where FUNCTION can be
  either a function or a list of functions.  Those functions will be called
  with 2 arguments: the buffer to display and an ALIST built from the various
  alists specified in the various ACTIONs.  It should either return the
  window used, or nil to fallback to the next function.")

  (defvar display-buffer-default-action (list #'display-buffer-default)
    "Default action to perform to display a buffer.
  This is an ACTION just like in `display-buffer-alist'.")

  (defvar display-buffer-overriding-action '(nil)
    "Overriding action to perform to display a buffer.
  This is an ACTION just like in `display-buffer-alist'.")

  (defun display-buffer (&optional buffer action)
    "Display BUFFER in some window."
    (let* ((user-action
            (assq-regexp (buffer-name buffer) display-buffer-alist))
          (functions (append (car display-buffer-overriding-action)
                             (car user-action)
                             (car action)
                             (car display-buffer-default-action)))
          (alist (append (cdr display-buffer-overriding-action)
                         (cdr user-action)
                         (cdr action)
                         (cdr display-buffer-default-action))))
      (run-with-args-until-success functions buffer alist)))

  (defalias 'display-buffer-default 'emacs23-display-buffer)

  (defun display-buffer-other-window (buffer alist)
    (let ((pop-up-windows t)
          (special-display-buffer-names nil)
          (special-display-regexps nil)
          (same-window-buffer-names nil)
          (same-window-regexps nil))
      (emacs23-display-buffer buffer)))

  [...]

The code is clearly incorrect and incomplete, but hopefully gives you an
idea of what I expect it to do.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >   (defvar display-buffer-alist nil
 >     "Specifications of user preferences for `display-buffer'.
 >   This is a list of elements of the form (CONDITION . ACTION)
 >   where CONDITION is either a regexp matching buffer names, or a function
 >   that takes a buffer and returns a boolean.
 >   ACTION is a list of the form (FUNCTION . ALIST) where FUNCTION can be
 >   either a function or a list of functions.  Those functions will be called
 >   with 2 arguments: the buffer to display and an ALIST built from the various
 >   alists specified in the various ACTIONs.  It should either return the
 >   window used, or nil to fallback to the next function.")

This is what I'd call a `display-buffer-alist' purely built from macro
specifiers.

 >   (defvar display-buffer-default-action (list #'display-buffer-default)
 >     "Default action to perform to display a buffer.
 >   This is an ACTION just like in `display-buffer-alist'.")
 >
 >   (defvar display-buffer-overriding-action '(nil)
 >     "Overriding action to perform to display a buffer.
 >   This is an ACTION just like in `display-buffer-alist'.")
 >
 >   (defun display-buffer (&optional buffer action)
 >     "Display BUFFER in some window."
 >     (let* ((user-action
 >             (assq-regexp (buffer-name buffer) display-buffer-alist))
 >           (functions (append (car display-buffer-overriding-action)
 >                              (car user-action)
 >                              (car action)

Here the user has only two choices: Either accept the (car action) with
its alist or use its own (car user-action) with its own alist.

 >                              (car display-buffer-default-action)))
 >           (alist (append (cdr display-buffer-overriding-action)
 >                          (cdr user-action)
 >                          (cdr action)
 >                          (cdr display-buffer-default-action))))
 >       (run-with-args-until-success functions buffer alist)))
 >
 >   (defalias 'display-buffer-default 'emacs23-display-buffer)
 >
 >   (defun display-buffer-other-window (buffer alist)
 >     (let ((pop-up-windows t)
 >           (special-display-buffer-names nil)
 >           (special-display-regexps nil)
 >           (same-window-buffer-names nil)
 >           (same-window-regexps nil))
 >       (emacs23-display-buffer buffer)))

IIUC this is the Emacs23 compatible version skillful users can override
by supplying their own version.  I'm not quite sure how they would
indicate such a preference via `display-buffer-alist' but apparently the
"function that takes a buffer and returns a boolean" together with some
knowledge about the command that is currently executed should allow them
to do that.


My basic problem with your approach is the following: When we write a
`display-buffer-near-minibuffer' function that reuses the bottom window,
we have two choices wrt evening window heights - do it or don't do it.
As we know, some users are picky about their customizations.  Most of
them, I suppose, got used to the default.  But Eli, for example, doesn't
like `display-buffer' to even window heights.  So we'll soon find
someone who wants the opposite behavior.  And you will propose to
respect the value of the good old `even-window-heights' option in
`display-buffer-near-minibuffer'.  Why would I be not surprised?

As a next step suppose Chong wants to adjust the height of the new
window created by `display-buffer-near-minibuffer' calling, for example,
`fit-window-to-buffer'.  We'll soon find someone who dislikes this
behavior and wants `display-buffer' to leave the new height alone.  So
someone will propose to add a new user option to turn that behavior off.
And people will continue adding new options as they did with
special-display-..., same-window-..., display-buffer-reuse-frames, and
display-buffer-mark-dedicated.

The `display-buffer-alist' idea was to radically put an end to that.
This means that such options can be added _exclusively_ via the alist
and no new variables must be introduced.  And obviously it would have
prompted users to customize it in order to get the behavior they want.
But the interaction between options would have been based on a strict
priority.  Emacs 23 options are not manageable in this regard.

Your approach will divide Emacs users into two groups: A wide majority
that continues to use the old options and a small minority able to write
their own alist based functions.  Since applications cater for the
majority, clones of your `display-buffer-other-window' code above would
abound soon.

Most of what you propose above is easily available in Emacs 23 via
`special-display-regexps'.  An application would just temporarily add
the buffer, the function, and the alist to the head of that and get the
behavior without setting any arguments.  Is it really worth inventing a
new `display-buffer' in order to resolve such cosmetic issues?

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

>>     "Specifications of user preferences for `display-buffer'.
>>   This is a list of elements of the form (CONDITION . ACTION)
>>   where CONDITION is either a regexp matching buffer names, or a function
>>   that takes a buffer and returns a boolean.
>>   ACTION is a list of the form (FUNCTION . ALIST) where FUNCTION can be
>>   either a function or a list of functions.

This is probably more simply stated as

  This is a list of elements of the form (CONDITION FUNCTIONS ACTION-ARGS...)

>>   (defun display-buffer (&optional buffer action)
>>     "Display BUFFER in some window."
>>     (let* ((user-action
>>             (assq-regexp (buffer-name buffer) display-buffer-alist))
>>           (functions (append (car display-buffer-overriding-action)
>>                              (car user-action)
>>                              (car action)
>
> Here the user has only two choices: Either accept the (car action) with
> its alist or use its own (car user-action) with its own alist.
>
>>                              (car display-buffer-default-action)))

I don't see any problem with that.

> As a next step suppose Chong wants to adjust the height of the new
> window created by `display-buffer-near-minibuffer' calling, for
> example, `fit-window-to-buffer'.  We'll soon find someone who dislikes
> this behavior and wants `display-buffer' to leave the new height
> alone.  So someone will propose to add a new user option to turn that
> behavior off.

It's not necessary for a new option.  This can be handled with an
element in display-buffer-default-action, since the alist of arguments
passed to the display function is constructed by

>>           (alist (append (cdr display-buffer-overriding-action)
>>                          (cdr user-action)
>>                          (cdr action)
>>                          (cdr display-buffer-default-action))))

The display function just needs to know about that alist element.  So I
don't think this objection is valid.

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>> "Specifications of user preferences for `display-buffer'.
>>> This is a list of elements of the form (CONDITION . ACTION)
>>> where CONDITION is either a regexp matching buffer names, or a function
>>> that takes a buffer and returns a boolean.
>>> ACTION is a list of the form (FUNCTION . ALIST) where FUNCTION can be
>>> either a function or a list of functions.

> This is probably more simply stated as

>   This is a list of elements of the form (CONDITION FUNCTIONS ACTION-ARGS...)

I call it (CONDITION . ACTION) because we can have ACTIONs at other places.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 >>   This is a list of elements of the form (CONDITION FUNCTIONS ACTION-ARGS...)
 >
 > I call it (CONDITION . ACTION) because we can have ACTIONs at other places.

I have made window minimum heights (aka `split-height-threshold') alist
members although, as Juri mentioned earlier, these are actually part of
the enabling condition (or the action).  Where really put these?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>> This is a list of elements of the form (CONDITION FUNCTIONS ACTION-ARGS...)
>> I call it (CONDITION . ACTION) because we can have ACTIONs at other places.
> I have made window minimum heights (aka `split-height-threshold') alist
> members although, as Juri mentioned earlier, these are actually part of
> the enabling condition (or the action).  Where really put these?

The CONDITION is only concerned with the buffer to display, so things
like minimum window height is not part of the CONDITION.  It definitely
belongs in the ALIST.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

>> I have made window minimum heights (aka `split-height-threshold') alist
>> members although, as Juri mentioned earlier, these are actually part of
>> the enabling condition (or the action).  Where really put these?
>
> The CONDITION is only concerned with the buffer to display, so things
> like minimum window height is not part of the CONDITION.  It definitely
> belongs in the ALIST.

I agree that window minimum heights would be too fine-grained
for the CONDITION part.  It's better suitable for the ALIST.

I think that important part of design is functional decomposition
to implement minimal building blocks that can be easily combined
to define a buffer-displaying behavior.

To continue this discussion, I propose to think about the complexity
of implementing a `display-buffer-near-minibuffer' function.
How easy it would be to do by using existing functions
(and ignoring `display-buffer-alist' awhile)?

I imagine an algorithm like this:

1. Try to reuse a window dedicated to the buffer to be displayed.

2. Try to reuse a window at the bottom with the width of the selected frame.
   Alternatively, provide a parameter for the ALIST to skip this step.
   Also provide a parameter to resize the reused window.

3. Otherwise, taking into account min-height try to create a new window
   with the specified height at the bottom of the selected frame.

4. Otherwise, reuse any available window on the selected frame.
   Provide a parameter to define the order of different methods:
   largest, lru, rightmost, etc.

5. Alternatively, with preference of using frames, try to find
   a dedicated frame.  Otherwise, create a new frame with
   specified parameters.

Is it possible to write that now using simple function calls?

Re: display-buffer-alist simplifications

[martin rudalics]

 > I think that important part of design is functional decomposition
 > to implement minimal building blocks that can be easily combined
 > to define a buffer-displaying behavior.

That was my initial aim.

 > 1. Try to reuse a window dedicated to the buffer to be displayed.

`display-buffer-reuse-window' doesn't check for dedicated windows yet.
This would have to be done manually first, passing the window in the
second argument.

 > 2. Try to reuse a window at the bottom with the width of the selected frame.

Non-trivial.  That may be the only, the selected, a dedicated, or in
some other sense important window.  I don't yet know how to handle this
case satisfactorily.

 >    Alternatively, provide a parameter for the ALIST to skip this step.
 >    Also provide a parameter to resize the reused window.

So far we only even the size of a reused window.

 > 3. Otherwise, taking into account min-height try to create a new window
 >    with the specified height at the bottom of the selected frame.

Calling `display-buffer-pop-up-window' with root and below as only
choices, passing min-height and the specified height as arguments.

 > 4. Otherwise, reuse any available window on the selected frame.
 >    Provide a parameter to define the order of different methods:
 >    largest, lru, rightmost, etc.

`display-buffer-reuse-window' doesn't recognize these methods yet.  We
would either have to get them manually and pass the windows directly or
expand the semantics of the second argument.

 > 5. Alternatively, with preference of using frames, try to find
 >    a dedicated frame.  Otherwise, create a new frame with
 >    specified parameters.

Calling `display-buffer-reuse-window' manually sorting out a suitable
frame and calling `display-buffer-pop-up-frame' otherwise.

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

>>    Also provide a parameter to resize the reused window.
>
> So far we only even the size of a reused window.

Adjusting the size is also necessary with `fit-window-to-buffer'
(optionally) like in `dired-pop-to-buffer'.

>> 3. Otherwise, taking into account min-height try to create a new window
>>    with the specified height at the bottom of the selected frame.
>
> Calling `display-buffer-pop-up-window' with root and below as only
> choices, passing min-height and the specified height as arguments.

In `dired-pop-to-buffer', `min-height' is specified as an argument
of `fit-window-to-buffer'.  It would be good instead of

  (fit-window-to-buffer (display-buffer-pop-up-window " *Marked Files*"
                         '((root . below)))
   nil 1)

to specify that as

  (display-buffer-pop-up-window " *Marked Files*"
   '((root . below) (min-height . 1) (fit-to-buffer . t)))

This could avoid calling `fit-window-to-buffer' directly, because
`display-buffer-pop-up-window' could interpret the parameter
`fit-to-buffer' as an indication to calculate the height of the created
window from the number of lines in the buffer to be displayed.

>> 4. Otherwise, reuse any available window on the selected frame.
>>    Provide a parameter to define the order of different methods:
>>    largest, lru, rightmost, etc.
>
> `display-buffer-reuse-window' doesn't recognize these methods yet.  We
> would either have to get them manually and pass the windows directly or
> expand the semantics of the second argument.

They could share the same semantics to find the window to reuse/split.

Re: display-buffer-alist simplifications

[martin rudalics]

 >> So far we only even the size of a reused window.
 >
 > Adjusting the size is also necessary with `fit-window-to-buffer'
 > (optionally) like in `dired-pop-to-buffer'.

Indeed.  ISTR that I readjusted the height of such windows when quitting
them but this somehow doesn't work any more.  Hmmmm ...

 >>> 3. Otherwise, taking into account min-height try to create a new window
 >>>    with the specified height at the bottom of the selected frame.
 >> Calling `display-buffer-pop-up-window' with root and below as only
 >> choices, passing min-height and the specified height as arguments.
 >
 > In `dired-pop-to-buffer', `min-height' is specified as an argument
 > of `fit-window-to-buffer'.  It would be good instead of
 >
 >   (fit-window-to-buffer (display-buffer-pop-up-window " *Marked Files*"
 >                          '((root . below)))
 >    nil 1)
 >
 > to specify that as
 >
 >   (display-buffer-pop-up-window " *Marked Files*"
 >    '((root . below) (min-height . 1) (fit-to-buffer . t)))

min-height 1 might not be very useful here if the subsequent
`fit-to-buffer' fails.  In any case, `dired-pop-to-buffer' must deal
with the fact that no window can be popped up.

 > This could avoid calling `fit-window-to-buffer' directly, because
 > `display-buffer-pop-up-window' could interpret the parameter
 > `fit-to-buffer' as an indication to calculate the height of the created
 > window from the number of lines in the buffer to be displayed.

So why not make this the value of min-height?

 >>> 4. Otherwise, reuse any available window on the selected frame.
 >>>    Provide a parameter to define the order of different methods:
 >>>    largest, lru, rightmost, etc.
 >> `display-buffer-reuse-window' doesn't recognize these methods yet.  We
 >> would either have to get them manually and pass the windows directly or
 >> expand the semantics of the second argument.
 >
 > They could share the same semantics to find the window to reuse/split.

This can be done.  BTW in your example above (root . below) is not a
valid alist entry since below is not the value of the key root.  We need
something like (window . root) (side . below) instead.

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 > The display function just needs to know about that alist element.  So I
 > don't think this objection is valid.

A display function like Stefan's display-buffer-other-window won't care.
Or what am I missing?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> (defun display-buffer (&optional buffer action)
>> "Display BUFFER in some window."
>> (let* ((user-action
>> (assq-regexp (buffer-name buffer) display-buffer-alist))
>> (functions (append (car display-buffer-overriding-action)
>> (car user-action)
>> (car action)
> Here the user has only two choices: Either accept the (car action) with
> its alist or use its own (car user-action) with its own alist.

No: the alist passed to the function is built by combining the user's
and the caller's.
The only thing the user's FUNCTION doesn't know is the caller's
FUNCTION, although it can fallback to it by retuning nil.

>> (defun display-buffer-other-window (buffer alist)
>> (let ((pop-up-windows t)
>> (special-display-buffer-names nil)
>> (special-display-regexps nil)
>> (same-window-buffer-names nil)
>> (same-window-regexps nil))
>> (emacs23-display-buffer buffer)))
> IIUC this is the Emacs23 compatible version skillful users can override
> by supplying their own version.

This is a sample function that can be used in
message-mail-other-window to maximize backward compatibility.

> I'm not quite sure how they would indicate such a preference via
> `display-buffer-alist'

Not sure what "such a preference" refers to.

> but apparently the "function that takes a buffer and returns
> a boolean" together with some knowledge about the command that is
> currently executed should allow them to do that.

They can either recognize the buffer name via the regexp, or the
buffer's major-mode (yes, the latter requires a function that takes the
buffer and returns non-nil iff the major-mode is the right one).
I don't think that "knowledge about the command that is currently
executed" is something we want to provide because it's too messy.

> My basic problem with your approach is the following: When we write a
> `display-buffer-near-minibuffer' function that reuses the bottom window,
> we have two choices wrt evening window heights - do it or don't do it.

You're referring to the following point, I think:
  - the display method has to handle everything, there's no common/shared
    postprocessing.
The way I think we would handle it is by making most/all
display-buffer-<foo> function finish by calling
a display-buffer-post-process function, passing it the ALIST.
So the ALIST may include something like (even-window . height) to
specify whether and how to even windows.

> someone who wants the opposite behavior.  And you will propose to
> respect the value of the good old `even-window-heights' option in
> `display-buffer-near-minibuffer'.  Why would I be not surprised?

I don't see any reason why a brand new method such as
display-buffer-near-minibuffer should obey obsolete config vars.

> As a next step suppose Chong wants to adjust the height of the new
> window created by `display-buffer-near-minibuffer' calling, for example,
> `fit-window-to-buffer'.  We'll soon find someone who dislikes this
> behavior and wants `display-buffer' to leave the new height alone.  So
> someone will propose to add a new user option to turn that
> behavior off.

If someone suggest it, it's fine: we can just answer by adding
a `fit-window' parameter in the ALIST to control this behavior.

> And people will continue adding new options as they did with
> special-display-..., same-window-..., display-buffer-reuse-frames, and
> display-buffer-mark-dedicated.

I don't see any reason why that should be the case.

> The `display-buffer-alist' idea was to radically put an end to that.
> This means that such options can be added _exclusively_ via the alist
> and no new variables must be introduced.  And obviously it would have
> prompted users to customize it in order to get the behavior they want.
> But the interaction between options would have been based on a strict
> priority.  Emacs 23 options are not manageable in this regard.

AFAICT my proposal shares the same goal and the same property in
this regard.

> Most of what you propose above is easily available in Emacs 23 via
> `special-display-regexps'.

Nope.

> An application would just temporarily add
> the buffer, the function, and the alist to the head of that and get the
> behavior without setting any arguments.

But then the user can't override it without a lot of effort.
My proposal fixes this problem just as well as yours.

> Is it really worth inventing a new `display-buffer' in order to
> resolve such cosmetic issues?

I don't understand the question.

To get back to my suggestion, I think it's really not that different
from your code.  We can largely provide the same predefined methods (just
that things like the `reuse-window' symbol turns into a function
`display-buffer-reuse-window', forcing the code to be more modular) and
let them handle the same set of arguments and parameters (tho the args
to `reuse-window' need to be turned into named parameters).

Admittedly, you won't be able to do the equivalent of
((reuse-window foo bar) (reuse-window titi toto)) because the args
passed to FUNCTIONs are the same for each FUNCTION, so if a FUNCTION
appears twice both occurrences will behave identically.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > You're referring to the following point, I think:
 >   - the display method has to handle everything, there's no common/shared
 >     postprocessing.
 > The way I think we would handle it is by making most/all
 > display-buffer-<foo> function finish by calling
 > a display-buffer-post-process function, passing it the ALIST.
 > So the ALIST may include something like (even-window . height) to
 > specify whether and how to even windows.

Now this makes sense.  We would have to decide whether we provide one
such function or more (depending on the functionality of the service or
the method used).  And probably, if there's no suitable ALIST entry,
such a function would respect the old options where applicable.

 > Admittedly, you won't be able to do the equivalent of
 > ((reuse-window foo bar) (reuse-window titi toto)) because the args
 > passed to FUNCTIONs are the same for each FUNCTION, so if a FUNCTION
 > appears twice both occurrences will behave identically.

I should be able to live with that.  But how do we express that
splitting a window should try the largest window first and the lru
afterwards?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> You're referring to the following point, I think:
>> - the display method has to handle everything, there's no common/shared
>> postprocessing.
>> The way I think we would handle it is by making most/all
>> display-buffer-<foo> function finish by calling
>> a display-buffer-post-process function, passing it the ALIST.
>> So the ALIST may include something like (even-window . height) to
>> specify whether and how to even windows.
> Now this makes sense.  We would have to decide whether we provide one
> such function or more (depending on the functionality of the service or
> the method used).  And probably, if there's no suitable ALIST entry,
> such a function would respect the old options where applicable.

That's the idea, yes.  I'm not completely satisfied with this, tho.
I'd rather have a way to specify a list of post-processing functions,
but I can't think of an elegant way to do that right now.

>> Admittedly, you won't be able to do the equivalent of
>> ((reuse-window foo bar) (reuse-window titi toto)) because the args
>> passed to FUNCTIONs are the same for each FUNCTION, so if a FUNCTION
>> appears twice both occurrences will behave identically.
> I should be able to live with that.  But how do we express that
> splitting a window should try the largest window first and the lru
> afterwards?

You don't express it in display-buffer-alist but in Elisp code instead.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

I still don't understand how this can DTRT:

   (defun display-buffer (&optional buffer action)
     "Display BUFFER in some window."
     (let* ((user-action
             (assq-regexp (buffer-name buffer) display-buffer-alist))
           (functions (append (car display-buffer-overriding-action)
                              (car user-action)
                              (car action)
                              (car display-buffer-default-action)))
           (alist (append (cdr display-buffer-overriding-action)
                          (cdr user-action)
                          (cdr action)
                          (cdr display-buffer-default-action))))
       (run-with-args-until-success functions buffer alist)))

Suppose `display-buffer-overriding-action' specifies as action to reuse
a window and an alist element to use the lru window like

'(display-buffer-reuse-window . ((window . lru)))

and `user-action' specifies as action to reuse a window and as alist
element to use the largest window like

'(display-buffer-reuse-window . ((window . largest)))

If the lru window cannot be reused, `display-buffer' will nevertheless
try twice to use it and never try to use the largest window.

If `user-action' specifies

'(display-buffer-pop-up-window . ((window . largest)))

`display-buffer' will try to split the lru window.  Shall these
behaviors be considered features or am I missing something?

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 >           (functions (append (car display-buffer-overriding-action)
 >                              (car user-action)
 >                              (car action)
 >                              (car display-buffer-default-action)))
 >           (alist (append (cdr display-buffer-overriding-action)
 >                          (cdr user-action)
 >                          (cdr action)
 >                          (cdr display-buffer-default-action))))
 >       (run-with-args-until-success functions buffer alist)))

Elaborating once more on this subject: Let O, U, A and D respectively
denote the functions in the cars of display-buffer-overriding-action,
user-action, action, and display-buffer-default-action and OL, UL, AL,
DL the alists in the corresponding cdrs.  Now my original proposal was
to run until success

(O . (OL UL AL DL))
(U . (UL AL DL))
(A . (AL DL))
(D . (DL))

that is, try the overriding function with all alists, if that fails try
the user function with all alists but the overriding one and so on.
People raised concerns about misinterpreting the alist concept and Chong
proposed to do something like

(O . (OL))
(U . (UL))
(A . (AL))
(D . (DL))

instead.  I raised concerns about applications not bothering to specify
anything in OL and AL and so he later changed this to something like

(O . (OL DL))
(U . (UL DL))
(A . (AL DL))
(D . (DL))

IIUC.  Stefan's proposal, as can be seen from the code above, now is to
do

(O . (OL UL AL DL))
(U . (OL UL AL DL))
(A . (OL UL AL DL))
(D . (OL UL AL DL))

which IMHO isn't TRT since, for example, the entries in OL might not
make sense in the context of the functions in U, A and D.

So which is the solution I should use?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

> IIUC.  Stefan's proposal, as can be seen from the code above, now is to do

> (O . (OL UL AL DL))
> (U . (OL UL AL DL))
> (A . (OL UL AL DL))
> (D . (OL UL AL DL))

> which IMHO isn't TRT since, for example, the entries in OL might not
> make sense in the context of the functions in U, A and D.

This was a conscious choice on my part.  It does introduce potential for
problems, indeed, but it also introduces potential for more flexibility.
Basically it means that parameter names have to be chosen more
carefully: when beneficial the same name should be used and when not
parameter names should use "private" names.  E.g. `window' is probably
not a good parameter name because it's likely to mean completely
different things for O U A and D.

E.g. the original motivation for early params to be passed to later
functions (contrary to your current code) is for the
`not-this-window' parameter which will usually be specified by AL
and handled by D.


        Stefan

Re: display-buffer-alist simplifications

[Stefan Monnier]

> Suppose `display-buffer-overriding-action' specifies as action to reuse
> a window and an alist element to use the lru window like
>
> '(display-buffer-reuse-window . ((window . lru)))
>
> and `user-action' specifies as action to reuse a window and as alist
> element to use the largest window like
>
> '(display-buffer-reuse-window . ((window . largest)))

If it hurts don't do that: the way my proposal works indeed does not
lend itself to the kind of decomposition you've used in the current code.

Until now there is no caller out there that specifies "I want to reuse
an existing window and I want it to be the LRU", and neither is there
a user out there that has a config that says "buffers names TOTO should
be displayed in an existing window and should use the largest window".
So it's not a real problem.

> If the lru window cannot be reused, `display-buffer' will nevertheless
> try twice to use it and never try to use the largest window.

The double-call is indeed a bit ugly, so we could remove duplicates
before running the hook.

> If `user-action' specifies
> '(display-buffer-pop-up-window . ((window . largest)))
> `display-buffer' will try to split the lru window.

That indicates a name conflict, i.e. a misfeature in your choice of
parameter names.

Just like different programming languages end up favoring different
coding styles (even though most programming languages are fundamentally
very similar), my buffer-display-alist is sufficiently different from
yours that it will favor a different kind of decomposition than the
one you've currently implemented.

We should focus at this point on providing:
- the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
  other-window, other-frame, dedicated-or-not, existing-window) so as to
  be able to mark the various old config vars as obsolete.
- the new experimental side-window feature.
- nothing more.

And leave the more refined functionality to Emacs-24.2, so we have time
to experiment with it to see what fits well in this system.

To me the main purpose of the change is to provide the new framework so
we can obsolete the old vars (mostly because they suffer from the
problem of being both custom-vars and vars modified by packages via setq
and via let).  This is a long-standing problem and since it touches vars
used by many Elisp packages it's a long-term change and it's important
to make the old stuff obsolete as soon as possible (i.e. 24.1).

The introduction of more refined specifications of behavior is secondary
and given the timeline, I'd rather postpone it to Emacs-24.2.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > If it hurts don't do that: the way my proposal works indeed does not
 > lend itself to the kind of decomposition you've used in the current code.
 >
 > Until now there is no caller out there that specifies "I want to reuse
 > an existing window and I want it to be the LRU", and neither is there
 > a user out there that has a config that says "buffers names TOTO should
 > be displayed in an existing window and should use the largest window".
 > So it's not a real problem.

So when we write a function `display-buffer-near-minibuffer' and want to
reuse the bottom-most window we can't decompose?

 >> If `user-action' specifies
 >> '(display-buffer-pop-up-window . ((window . largest)))
 >> `display-buffer' will try to split the lru window.
 >
 > That indicates a name conflict, i.e. a misfeature in your choice of
 > parameter names.

IIRC it was Juri's idea to unify keys this way.  Good to know that it's
a misfeature.

 > Just like different programming languages end up favoring different
 > coding styles (even though most programming languages are fundamentally
 > very similar), my buffer-display-alist is sufficiently different from
 > yours that it will favor a different kind of decomposition than the
 > one you've currently implemented.

Already in Emacs 23 we had three basic functions to find a window for
`display-buffer': `window--reuse-window', `window--pop-up-window' and
`window--pop-up-frame'.  These are the basic building blocks and
whatever we want to do on top will always boil down to calling some
variant of these.

 > - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
 >   other-window, other-frame, dedicated-or-not, existing-window) so as to
 >   be able to mark the various old config vars as obsolete.

Without offering anything people can customize instead but a single
option called `display-buffer-alist' to choose one of these functions?

Bold ;-)

martin

Re: display-buffer-alist simplifications

[Juri Linkov]

> IIRC it was Juri's idea to unify keys this way.  Good to know that it's
> a misfeature.

I said "_like_ `run-hook-with-args-until-success'" ;-)
This does not mean we should use it as is.
We could run every funcall with different alist arguments.

Or with Stefan's design without decomposition
these actions could be specified as:
'(display-buffer-reuse-lru-window . ())
'(display-buffer-reuse-largest-window . ())

>> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>>   other-window, other-frame, dedicated-or-not, existing-window) so as to
>>   be able to mark the various old config vars as obsolete.
>
> Without offering anything people can customize instead but a single
> option called `display-buffer-alist' to choose one of these functions?

At least, this change will be easy to understand for users. ;-)

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> Until now there is no caller out there that specifies "I want to reuse
>> an existing window and I want it to be the LRU", and neither is there
>> a user out there that has a config that says "buffers names TOTO should
>> be displayed in an existing window and should use the largest window".
>> So it's not a real problem.

> So when we write a function `display-buffer-near-minibuffer' and want to
> reuse the bottom-most window we can't decompose?

I don't know what you mean by "decompose".  I suspect you're referring
to the way your current display-buffer-alist provides very fine-grained
building blocks that are combined in display-buffer-alist specifiers.
If so, indeed, my design does not make such decomposition easy.
But I don't think it's a problem: the decomposition can be done in the
Elisp code instead (i.e. display-buffer-near-minibuffer can call some
display-buffer-reuse-foo function).

>> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>> other-window, other-frame, dedicated-or-not, existing-window) so as to
>> be able to mark the various old config vars as obsolete.
> Without offering anything people can customize instead but a single
> option called `display-buffer-alist' to choose one of these functions?

Almost.  Actually, I think there are 2 defcustoms: display-buffer-alist
and display-buffer-default-rule.  The default-rule will replace things
like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while
display-buffer-alist will replace things like same-window-* and
special-display-*.

Juri writes:
> Or with Stefan's design without decomposition
> these actions could be specified as:
> '(display-buffer-reuse-lru-window . ())
> '(display-buffer-reuse-largest-window . ())

No, since all these params belong to display-buffer-alist, the
"display-buffer-" prefix would be unnecessary.


        Stefan

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>>   other-window, other-frame, dedicated-or-not, existing-window) so as to
>>   be able to mark the various old config vars as obsolete.
>
> Without offering anything people can customize instead but a single
> option called `display-buffer-alist' to choose one of these functions?
>
> Bold ;-)

I don't think it's even necessary to mark the Emacs 23 variables as
obsolete for 24.1; we can save that for Emacs 24.2.

Because it is so late in the game, now that we've settled on a workable
design the objective should be to get the basic code "infrastructure"
and the old the Emacs 23 variables work.  Making a rich set of Custom
interfaces to that design can wait.

For example, I would not spend time on the defcustom definitions for
display-buffer-alist and display-buffer-default-rule, if that proves
complicated---you could just make them defvars for now.

RE: display-buffer-alist simplifications

[Drew Adams]

> now that we've settled on a workable design

You/we have?  I hadn't gotten that impression from scanning the thread.  I
(think I) see new proposals and counter-proposals everyday.

> For example, I would not spend time on the defcustom definitions for
> display-buffer-alist and display-buffer-default-rule, if that proves
> complicated---you could just make them defvars for now.

Huh?  I thought the decision was that there was no hurry for Emacs 24 and that
you wanted to get this right first.  Sounds like now someone wants to go to
market in a hurry.

defvars instead of defcustoms?  Are you serious?  How do you expect users to
deal with this stuff?  It seems almost impossible for even you guys to
understand it all and make up your minds about what's going on.

I say take the time to get it right.  What's the rush?

Re: display-buffer-alist simplifications

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> now that we've settled on a workable design
>
> You/we have?  I hadn't gotten that impression from scanning the
> thread.  I (think I) see new proposals and counter-proposals everyday.

You haven't been reading the thread carefully, then.

>> For example, I would not spend time on the defcustom definitions for
>> display-buffer-alist and display-buffer-default-rule, if that proves
>> complicated---you could just make them defvars for now.
>
> Huh?  I thought the decision was that there was no hurry for Emacs 24
> and that you wanted to get this right first.  Sounds like now someone
> wants to go to market in a hurry.
>
> I say take the time to get it right.  What's the rush?

Conversely, as long as the Emacs 23 variables continues to work, we have
all the time in the world to introduce the full set of new window
management features.

The hold-up is fine for now, because meanwhile other bugs are getting
fixed and the manuals are getting updated.  But the timeline is not
infinitely elastic---the whole point of a feature freeze is that new
features are supposed to be ready for testing/integration at more or
less the same time, instead of waiting on one another.

Another reason I would prefer to reduce the initial set of changes to
the minimum working set of "base" code is to get that code into the
repository sooner rather than later.  Then other Emacs developers can
help at working out integration issues, reducing the current bottleneck
(i.e. "Martin doing everything").

Re: display-buffer-alist simplifications

[martin rudalics]

 > Conversely, as long as the Emacs 23 variables continues to work, we have
 > all the time in the world to introduce the full set of new window
 > management features.
 >
 > The hold-up is fine for now, because meanwhile other bugs are getting
 > fixed and the manuals are getting updated.  But the timeline is not
 > infinitely elastic---the whole point of a feature freeze is that new
 > features are supposed to be ready for testing/integration at more or
 > less the same time, instead of waiting on one another.
 >
 > Another reason I would prefer to reduce the initial set of changes to
 > the minimum working set of "base" code is to get that code into the
 > repository sooner rather than later.  Then other Emacs developers can
 > help at working out integration issues, reducing the current bottleneck
 > (i.e. "Martin doing everything").

I hopefully restored the old code now together with the functionality
needed for quit-window and a rudimentary `pop-to-buffer-same-window'
function.  So feel free to go on reducing the current bottleneck.

Thanks, martin

Re: display-buffer-alist simplifications

[Juri Linkov]

> I hopefully restored the old code now together with the functionality
> needed for quit-window and a rudimentary `pop-to-buffer-same-window'
> function.  So feel free to go on reducing the current bottleneck.

What do you think about Stefan's near-term goal:

> We should focus at this point on providing:
> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>   other-window, other-frame, dedicated-or-not, existing-window) so as to
>   be able to mark the various old config vars as obsolete.

I agree that it would be expedient to do this before 24.1:
to obsolete the old vars and move their default values to two
defcustoms: `display-buffer-alist' and `display-buffer-default-alist'.

Re: display-buffer-alist simplifications

[martin rudalics]

 > What do you think about Stefan's near-term goal:
 >
 >> We should focus at this point on providing:
 >> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
 >>   other-window, other-frame, dedicated-or-not, existing-window) so as to
 >>   be able to mark the various old config vars as obsolete.
 >
 > I agree that it would be expedient to do this before 24.1:
 > to obsolete the old vars and move their default values to two
 > defcustoms: `display-buffer-alist' and `display-buffer-default-alist'.

Please go ahead doing as much as you can in this area.  I'm not very apt
to write code based on variables that shall be obsoleted.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> We should focus at this point on providing:
>> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>>   other-window, other-frame, dedicated-or-not, existing-window) so as to
>>   be able to mark the various old config vars as obsolete.
>
> I agree that it would be expedient to do this before 24.1: to obsolete
> the old vars and move their default values to two defcustoms:
> `display-buffer-alist' and `display-buffer-default-alist'.

Which variables ought to be moved into `display-buffer-alist'?  I
haven't seen anyone write down a specific list, and one would be
helpful.

Re: display-buffer-alist simplifications

[Juri Linkov]

> Which variables ought to be moved into `display-buffer-alist'?  I
> haven't seen anyone write down a specific list, and one would be
> helpful.

Stefan said yesterday:

> Actually, I think there are 2 defcustoms: display-buffer-alist
> and display-buffer-default-rule.  The default-rule will replace things
> like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while
> display-buffer-alist will replace things like same-window-* and
> special-display-*.

And I agree it would be good to do that before 24.1.

Re: display-buffer-alist simplifications

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Stefan said yesterday:
>
>> Actually, I think there are 2 defcustoms: display-buffer-alist
>> and display-buffer-default-rule.  The default-rule will replace things
>> like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while
>> display-buffer-alist will replace things like same-window-* and
>> special-display-*.
>
> And I agree it would be good to do that before 24.1.

Yes, so can someone draw up the *exact* list of variables that we want
to fold into display-buffer-alist, and their corresponding names in the
action alist?  Such a list will facilitate matters greatly.

Re: display-buffer-alist simplifications

[Stefan Monnier]

> Which variables ought to be moved into `display-buffer-alist'?  I
> haven't seen anyone write down a specific list, and one would be
> helpful.

Four variables should be made obsolete by display-buffer-alist:
same-window-buffer-names, same-window-regexps, special-display-regexps,
and special-display-buffer-names.

The rest should be made obsolete by display-buffer-default-rule (or by
the RULE (formerly NOT-THIS-WINDOW) arg of display-buffer):
pop-up-frames, pop-up-windows, display-buffer-mark-dedicated,
display-buffer-reuse-frames, probably a few more.

I also think that special-display-function can be marked obsolete, not
because something superceded it, but because I don't think anyone ever
used it.


        Stefan

Re: display-buffer-alist simplifications

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Four variables should be made obsolete by display-buffer-alist:
> same-window-buffer-names, same-window-regexps, special-display-regexps,
> and special-display-buffer-names.
>
> The rest should be made obsolete by display-buffer-default-rule (or by
> the RULE (formerly NOT-THIS-WINDOW) arg of display-buffer):
> pop-up-frames, pop-up-windows, display-buffer-mark-dedicated,
> display-buffer-reuse-frames, probably a few more.
>
> I also think that special-display-function can be marked obsolete, not
> because something superceded it, but because I don't think anyone ever
> used it.

I've now split up display-buffer-default into separate functions.  So
the default action of display-buffer is given by the following value of
display-buffer-default-action:

  '((display-buffer-reuse-selected-window
     display-buffer-maybe-same-window
     display-buffer-reuse-or-pop-window
     display-buffer-use-some-window
     display-buffer-pop-up-frame))

The "rule" terminology does sound nicer, so I guess we could rename
display-buffer-default-action to display-buffer-default-rule, and
display-buffer-use-some-window to display-rule-use-some-window etc.


Currently `display-buffer-maybe-same-window' handles the same-window-*
variables simply as

(defun display-buffer-maybe-same-window (buffer alist)
  (and (same-window-p (buffer-name buffer))
       (display-buffer-same-window buffer alist)))

If you want to convert same-window-* into alist entries, the cleanest
way is probably to add new optional args to `same-window-p' that, if
non-nil, override the values of same-window-*.  Then
`display-buffer-maybe-same-window' can pass the alist values to
`same-window-p' in those arguments.


OTOH we don't need any special handling for `special-display-*',
`display-buffer-reuse-frames', `pop-up-frames', or `pop-up-windows'.
They're currently handled in `display-buffer-reuse-or-pop-window', which
checks those variables and conditionally calls other functions like
`display-buffer-pop-up-frame', etc.  So those variables can be replaced
at a future date, by changing `display-buffer-default-action' and
replacing `display-buffer-reuse-or-pop-window' with the desired
combination of those other functions.

display-buffer-overriding-action

[Chong Yidong]

The new display-buffer design seems to work OK, but one aspect of it is
still bugging me: do we really need display-buffer-overriding-action?

If memory serves, the original idea was to allow the user to easily
impose options to override the ACTION argument to display-buffer,
applying to all buffers (unlike display-buffer-alist).  Such an option
might include the choice of window to reuse (currently not implemented).

But display-buffer-default-action should instead be used for such
purposes.  If we can assume that Lisp callers don't abuse the ACTION
argument for frivolous reasons, it is smarter to honor their specific
requests.  Such an override should not be necessary.

Re: display-buffer-overriding-action

[Juanma Barranquero]

On Sun, Sep 11, 2011 at 22:40, Chong Yidong <cyd@stupidchicken.com> wrote:

> If we can assume that Lisp callers don't abuse the ACTION
> argument for frivolous reasons, it is smarter to honor their specific
> requests.

It's not about frivolity. It's about the Lisp programmer setting what
s/he considers a good default, and the user disagreeing with that
opinion and being able to override it without needing to resort to
advice or rewriting the function. Experience shows that, with regards
to frame/window/buffer customizations, no two Emacs users are alike.

    Juanma

Re: display-buffer-overriding-action

[Stefan Monnier]

> The new display-buffer design seems to work OK, but one aspect of it is
> still bugging me: do we really need display-buffer-overriding-action?

I think so, yes.

> If memory serves, the original idea was to allow the user to easily
> impose options to override the ACTION argument to display-buffer,
> applying to all buffers (unlike display-buffer-alist).  Such an option
> might include the choice of window to reuse (currently not implemented).

No, the override-action is so the user can dynamically override even his
own settings.  E.g. C-x 5 b should override a user's own settings of
"same-window" for that buffer (after all, that's why he used C-x
5 b rather than C-x b).

So it's meant to be let-bound or set temporarily (the "set temporarily"
is for the case where we implement a new (prefix) command to bind to
keys like C-x 5 or C-x 4).


        Stefan

Re: display-buffer-overriding-action

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, the override-action is so the user can dynamically override even
> his own settings.  E.g. C-x 5 b should override a user's own settings
> of "same-window" for that buffer (after all, that's why he used C-x 5
> b rather than C-x b).
>
> So it's meant to be let-bound or set temporarily (the "set
> temporarily" is for the case where we implement a new (prefix) command
> to bind to keys like C-x 5 or C-x 4).

This is not very clear.  By "his own settings", do you mean the settings
in `display-buffer-alist' or `display-buffer-default-action'?  The
former is not a problem: C-x 5 b passes an ACTION argument to
pop-to-buffer, which takes precedence over d-b-alist.

If the former, how is d-b-overriding-action supposed to know which way
to override d-b-alist?  The display-buffer action functions aren't told
what the original arguments to display-buffer were, so it can't know
whether display-buffer was called for `C-x 5 b' or `C-x 4 b', or another
command entirely.

What would help would be a concrete example with a specific tweak that
you envision the user doing with d-b-alist, and how
d-b-overriding-action is supposed to override that.

Re: display-buffer-overriding-action

[Stefan Monnier]

>> No, the override-action is so the user can dynamically override even
>> his own settings.  E.g. C-x 5 b should override a user's own settings
>> of "same-window" for that buffer (after all, that's why he used C-x 5
>> b rather than C-x b).
>> So it's meant to be let-bound or set temporarily (the "set
>> temporarily" is for the case where we implement a new (prefix) command
>> to bind to keys like C-x 5 or C-x 4).

> This is not very clear.  By "his own settings", do you mean the settings
> in `display-buffer-alist' or `display-buffer-default-action'?  The

Both.

> former is not a problem: C-x 5 b passes an ACTION argument to
> pop-to-buffer, which takes precedence over d-b-alist.

No, the ACTION argument takes precedence over d-b-default-action but not
over d-b-alist.

> If the former, how is d-b-overriding-action supposed to know which way
> to override d-b-alist?

I don't understand the question.

> The display-buffer action functions aren't told what the original
> arguments to display-buffer were, so it can't know whether
> display-buffer was called for `C-x 5 b' or `C-x 4 b', or another
> command entirely.

C-x 5 b would not do

  (display-buffer BUFFER <some-clever-action)
but
  (let ((d-b-overriding-action <some-clever-action>))
    (display-buffer BUFFER))

Admittedly, it would be a change (currently C-x 5 b obeys
special-display-*) and we don't have any experience with such behavior,
but that's the intention behind this variable.

Another is for

   (defun foo-other-frame ()
     (let ((d-b-overriding-action <some-clever-action>))
       (foo)))

where foo-other-frame- does not otherwise have an easy way to change the
ACTION argument passed by `foo' to display-buffer.
       
My own interest is in replacing all those *-other-window and
*-other-frame commands by other-window-prefix and other-frame-prefix.

But I think other than providing the new framework (and making sure, on
the side, that it does provide the flexibility we want), we should not
make other changes to the code (e.g. to try and make use of this new
framework).


        Stefan

Re: display-buffer-overriding-action

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> former is not a problem: C-x 5 b passes an ACTION argument to
>> pop-to-buffer, which takes precedence over d-b-alist.
>
> No, the ACTION argument takes precedence over d-b-default-action but not
> over d-b-alist.

I meant d-b-default-action there.

>> The display-buffer action functions aren't told what the original
>> arguments to display-buffer were, so it can't know whether
>> display-buffer was called for `C-x 5 b' or `C-x 4 b', or another
>> command entirely.
>
> C-x 5 b would not do
>
>   (display-buffer BUFFER <some-clever-action)
> but
>   (let ((d-b-overriding-action <some-clever-action>))
>     (display-buffer BUFFER))

In your scheme, under what circumstances would *any* Lisp caller of
display-buffer use the ACTION argument?

As far as I can see, every Lisp caller falls into one of two cases:

- "Generic" calls to display-buffer or pop-to-buffer, which don't intend
   to second guess Emacs defaults and/or user settings.

- Commands like `C-x 5 b' or `info-other-window', which fall under the
  "explicit command" criterion and should override the defaults.

Your rationale for not using the ACTION argument is to allow a third
case, wherein the Lisp caller wants to specify some behavior that can be
overridden by the user.  I contend that Lisp callers should almost never
do that: as far as possible, they should use a `bare' display-buffer or
pop-to-buffer call.  In that case, it's conceptually cleaner to handle
the second case by letting those callers use the ACTION argument.

Do you have any specific counterexamples in mind?

Re: display-buffer-overriding-action

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Your rationale for not using the ACTION argument is to allow a third
> case, wherein the Lisp caller wants to specify some behavior that can
> be overridden by the user.  I contend that Lisp callers should almost
> never do that: as far as possible, they should use a `bare'
> display-buffer or pop-to-buffer call.

I should add that it is still possible to handle the "third case" by
doing

(let ((display-buffer-default-action
       (frobify display-buffer-default-action)))
  (display-buffer buffer))

This also has the advantage that the caller can do more complex
processing of the actions, such as selectively removing entries from the
function list or argument alist.  But such uses ought to be rare.

Re: display-buffer-overriding-action

[Stefan Monnier]

> As far as I can see, every Lisp caller falls into one of two cases:
> - "Generic" calls to display-buffer or pop-to-buffer, which don't intend
>    to second guess Emacs defaults and/or user settings.

That's the easy case.

> - Commands like `C-x 5 b' or `info-other-window', which fall under the
>   "explicit command" criterion and should override the defaults.

This case depends:
- historically, it has obeyed special-display-*, which would mean it
  should obey d-b-alist as well.  Hence the ACTION argument.
- even if/when we want to change C-x 5 b to override the d-b-alist (and
  special-display-* as well, of course), there are several other
  `other-window' cases where it's not nearly as clear cut that the
  user really meant to override d-b-alist (e.g. because it's the only
  command that has a convenient key binding).

Also you forgot the switch-to-buffer case, which uses the
ACTION argument.


        Stefan

Re: display-buffer-overriding-action

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> - Commands like `C-x 5 b' or `info-other-window', which fall under the
>>   "explicit command" criterion and should override the defaults.
>
> This case depends:
> - historically, it has obeyed special-display-*, which would mean it
>   should obey d-b-alist as well.

Yeah, and I don't think it works very well as an exception (especially
since the special display only kicks in halfway through the window
selection process, after Emacs has tried to reuse a window).

If we want to keep this functionality, one way to do this would be to
make d-b-overriding-action into an alist as well, so that the actions
would come from (in order of priority)

  defcustom d-b-override-alist
  Lisp ACTION
  defcustom d-b-alist
  defvar d-b-default-action

with d-b-override-alist serving to replace special-display-*.

> - there are several other `other-window' cases where it's not nearly
>   as clear cut that the user really meant to override d-b-alist
>   (e.g. because it's the only command that has a convenient key
>   binding).

Which cases are you referring to?  Probably they ought to let-bind
d-b-default-action---or be changed to use display-buffer generically.

> Also you forgot the switch-to-buffer case, which uses the ACTION
> argument.

Based on names alone, it seems reasonable for switch-to-buffer,
switch-to-buffer-other-window, and switch-to-buffer-other-frame to all
behave the same way w.r.t. whether to override d-b-alist.  And you've
argued that s-t-b-other-window/frame should override d-b-alist.

Re: display-buffer-overriding-action

[Stefan Monnier]

>>> - Commands like `C-x 5 b' or `info-other-window', which fall under the
>>> "explicit command" criterion and should override the defaults.
>> This case depends:
>> - historically, it has obeyed special-display-*, which would mean it
>> should obey d-b-alist as well.

> Yeah, and I don't think it works very well as an exception (especially
> since the special display only kicks in halfway through the window
> selection process, after Emacs has tried to reuse a window).

I don't know what you're referring to.  The reuse that takes place
before is not only harmless: special-display-popup-frame redoes its own
reuse check in case the earlier code didn't do a thorough enough job,
because reusing is what we want to do if possible rather than create
a new dedicated frame.

> If we want to keep this functionality, one way to do this would be to
> make d-b-overriding-action into an alist as well, so that the actions
> would come from (in order of priority)

>   defcustom d-b-override-alist
>   Lisp ACTION
>   defcustom d-b-alist
>   defvar d-b-default-action

I have no idea what you're trying to achieve with such a re-organisation.

>> - there are several other `other-window' cases where it's not nearly
>> as clear cut that the user really meant to override d-b-alist
>> (e.g. because it's the only command that has a convenient key
>> binding).
> Which cases are you referring to?  Probably they ought to let-bind
> d-b-default-action---or be changed to use display-buffer generically.

Maybe you're right.  In any case, right now they should most likely call
switch-to-buffer-other-* so as to avoid deciding how to implement it.

> And you've argued that s-t-b-other-window/frame should override
> d-b-alist.

Not quite: I argued that C-x 5 b should (and yes, C-x 4 b as well).
But that should not necessarily affect callers of s-t-b-other-*, unless
they are in the same situation (i.e. all 3 versions are bound to keys
so that the user's choice is clear).

Also, I do not want to make such a change in 24.1 because I'm not 100%
sure it would really be beneficial.  We need to play a bit with
it first.

So for Emacs-24.1, d-b-overriding-default will most likely stay unused,
and that's fine by me.


        Stefan

Re: display-buffer-overriding-action

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   defcustom d-b-override-alist
>>   Lisp ACTION
>>   defcustom d-b-alist
>>   defvar d-b-default-action
>
> I have no idea what you're trying to achieve with such a
> re-organisation.

If the majority of non-trivial calls to display-buffer are not going to
use the ACTION argument, that is a waste of the ACTION argument.  A
function argument is cleaner than let-binding around a display-buffer
call.  Forcing the non-trivial users of display-buffer to let-bind
d-b-overriding-action, instead of using the action argument, is a step
back towards the Emacs 23 situation (where one had to let-bind pop-up-*
special-display-*, etc. around such calls to display-buffer).

Re: display-buffer-overriding-action

[Stefan Monnier]

>>> defcustom d-b-override-alist
>>> Lisp ACTION
>>> defcustom d-b-alist
>>> defvar d-b-default-action
>> I have no idea what you're trying to achieve with such a
>> re-organisation.
> If the majority of non-trivial calls to display-buffer are not going to
> use the ACTION argument, that is a waste of the ACTION argument.

Agreed.  I see no evidence that we're heading this way.

> call.  Forcing the non-trivial users of display-buffer to let-bind
> d-b-overriding-action, instead of using the action argument, is a step

That's the reason why we have the ACTION argument: so non-trivial users
of display-buffer can pass their preference without imposing it on the
user (because the user can override it in d-b-alist).


        Stefan

Re: display-buffer-overriding-action

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> If the majority of non-trivial calls to display-buffer are not going to
>> use the ACTION argument, that is a waste of the ACTION argument.
>
> Agreed.  I see no evidence that we're heading this way.

I don't think we are convincing each other.  I guess we can keep the
current system, but let me make sure I understand your position:

- Interactive and non-interactive calls to switch-to-buffer,
  switch-to-buffer-other-window, and switch-to-buffer-other-frame shall
  override d-b-alist.  (This includes calls from commands in the Emacs
  sources.)

- To do this, s-t-buffer etc should let-bind d-b-overriding-action,
  instead of using ACTION as they currently do.

- This means that d-b-alist can't be used to tell Emacs "when I call
  s-t-buffer(-other-*) for this buffer, do this action instead".
  AFAICT there would be no way to do this except advice.

- If d-b-overriding-action is meant for use by s-t-b and co, then it
  should be a defvar, not a defcustom.

Is this accurate?

> That's the reason why we have the ACTION argument: so non-trivial
> users of display-buffer can pass their preference without imposing it
> on the user (because the user can override it in d-b-alist).

Any example in mind?  Note that if s-t-buffer etc are changed to use
d-b-overriding-action, there will be zero uses of the ACTION argument in
the Emacs source tree.  But can you point to the prospect of any uses in
the future?

Re: display-buffer-overriding-action

[Stefan Monnier]

> - Interactive and non-interactive calls to switch-to-buffer,
>   switch-to-buffer-other-window, and switch-to-buffer-other-frame shall
>   override d-b-alist.  (This includes calls from commands in the Emacs
>   sources.)

No.  I think that maybe they should.  I'm not sure.  But I'm sure they
shouldn't for Emacs-24.1.

> - This means that d-b-alist can't be used to tell Emacs "when I call
>   s-t-buffer(-other-*) for this buffer, do this action instead".
>   AFAICT there would be no way to do this except advice.

That's what it would imply, yes.

> - If d-b-overriding-action is meant for use by s-t-b and co, then it
>   should be a defvar, not a defcustom.

Indeed, d-b-overriding-action should not be a defcustom.


        Stefan

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> I hopefully restored the old code now together with the functionality
> needed for quit-window and a rudimentary `pop-to-buffer-same-window'
> function.  So feel free to go on reducing the current bottleneck.

Thank you!  This looks good.

One question: is there any reason you gave the revised `pop-to-buffer-*'
functions arglists of (&optional buffer-or-name norecord)?  These
functions didn't exist in Emacs 23, so it seems that they should be
written to be pluggable into (the revised) display-buffer-alist.  So the
second argument should instead be an action list instead of NORECORD,
right?

Re: display-buffer-alist simplifications

[martin rudalics]

 > One question: is there any reason you gave the revised `pop-to-buffer-*'
 > functions arglists of (&optional buffer-or-name norecord)?  These
 > functions didn't exist in Emacs 23, so it seems that they should be
 > written to be pluggable into (the revised) display-buffer-alist.  So the
 > second argument should instead be an action list instead of NORECORD,
 > right?

I don't know.  If we do so, then the action list should be probably also
made an argument of the switch-to-* family of functions which, IIUC,
according to Stefan should remain callable from programs.

I wouldn't have included the pop-to-* functions in the first place but
there are already too many callers around.  So please rewrite them the
way you consider most suitable.

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> I don't know.  If we do so, then the action list should be probably also
> made an argument of the switch-to-* family of functions which, IIUC,
> according to Stefan should remain callable from programs.
>
> I wouldn't have included the pop-to-* functions in the first place but
> there are already too many callers around.  So please rewrite them the
> way you consider most suitable.

OK, I understand better now.

The pop-to-* function should NOT be "action functions" (in the sense of
display-buffer-alist), because they select the window in addition to
displaying it.  But, they should make use of action functions.

TRT is to define two functions, `display-buffer-same-window' and
`display-buffer-other-window', which serve as action functions, which
handle the window selection/display part.  Then the implementation of
the pop-to-* functions is very simple: it consists choosing a particular
order for two action functions, or omitting one of them; and then
selecting the window.

This involves a simple re-factoring of your code:


(defun display-buffer-same-window (buffer alist)
  "Display BUFFER in the selected window, and return the window.
If BUFFER cannot be displayed in the selected window (usually
because it is dedicated to another buffer), return nil."
  (setq buffer (window-normalize-buffer-to-display buffer))
  (let ((norecord (cadr (assq 'norecord alist))))
    (cond
     ((eq buffer (window-buffer))
      (selected-window))
     ((not (or (window-minibuffer-p) (window-dedicated-p)))
      (set-window-buffer nil buffer)
      (selected-window)))))

(defun display-buffer-other-window (buffer alist)
  "Display BUFFER in another window, and return BUFFER.
If BUFFER cannot be displayed in another window, just return nil."
  (display-buffer-default buffer t))

(defun pop-to-buffer (buffer-or-name &optional other-window norecord)
  "..."
  (interactive "BPop to buffer:\nP")
  (if other-window
      (let ((same-window-buffer-names nil)
	    (same-window-regexps nil))
	(pop-to-buffer-1 buffer-or-name
			 '((display-buffer-other-window))
			 norecord))
    (pop-to-buffer-1 buffer-or-name
		     '((display-buffer-other-window
			display-buffer-same-window))
		     norecord)))

(defun pop-to-buffer-same-window (&optional buffer-or-name norecord)
  "..."
  (interactive "BPop to buffer in selected window:\nP")
  (pop-to-buffer-1 buffer-or-name
		   '((display-buffer-same-window
		      display-buffer-other-window))
		   norecord))

(defun pop-to-buffer-other-window (&optional buffer-or-name norecord)
  "..."
  (interactive "BPop to buffer in another window:\nP")
  (let ((pop-up-windows t)
  	(same-window-buffer-names nil)
	(same-window-regexps nil))
    (pop-to-buffer-1 buffer-or-name
		     '((display-buffer-other-window
			display-buffer-same-window))
		     norecord)))

(defun pop-to-buffer-other-frame (&optional buffer-or-name norecord)
  "..."
  (interactive "BPop to buffer on another frame:\nP")
  (let ((pop-up-frames t)
  	(same-window-buffer-names nil)
	(same-window-regexps nil))
    (pop-to-buffer-1 buffer-or-name
		     '((display-buffer-other-window
			display-buffer-same-window))
		     norecord)))

(defun pop-to-buffer-1 (buffer-or-name action norecord)
  (let ((buffer (window-normalize-buffer-to-display
		 ;; BUFFER-OR-NAME nil means another buffer.
		 (or buffer-or-name
		     (other-buffer (current-buffer))))))
    (set-buffer buffer)
    (let* ((old-window (selected-window))
	   (old-frame (selected-frame))
	   (window (display-buffer buffer action))
	   (frame (window-frame window)))
      (if (eq frame old-frame)
	  ;; Make sure new window gets selected (Bug#8615), (Bug#6954).
	  (select-window window norecord)
	;; `display-buffer' has chosen another frame, make sure it gets
	;; input focus and is risen.
	(select-frame-set-input-focus frame norecord))
      buffer)))

Re: display-buffer-alist simplifications

[martin rudalics]

 > This involves a simple re-factoring of your code:

Looks good.  If you or anyone else wants to code something in this area,
please go ahead.  I won't be able to code anything in the next days.
I'm currently tormented by a tooth and it's not yet clear whether I'm
going to kill the tooth or the tooth is going to kill me.  My Mengeleian
dentists are so far trying to preserve the tooth ...

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Looks good.  If you or anyone else wants to code something in this
> area, please go ahead.  I won't be able to code anything in the next
> days.  I'm currently tormented by a tooth and it's not yet clear
> whether I'm going to kill the tooth or the tooth is going to kill me.
> My Mengeleian dentists are so far trying to preserve the tooth ...

Sorry to hear about that; good luck.  I'll see what I can do in
window.el over the next couple of days.

RE: display-buffer-alist simplifications

[Drew Adams]

> > I say take the time to get it right.  What's the rush?
> 
> Conversely, as long as the Emacs 23 variables continues to 
> work, we have all the time in the world to introduce the full
> set of new window management features.

Precisely.  So do not include them in Emacs 24.1.  Or include them with a giant
caveat that they are experimental and user code should not depend on them.

IOW, you might want people to play with this, to get some feedback. But you
shouldn't want people to use it seriously and come to expect it to continue as
is.  Play if you want, but do not work with this.

Things that are not fully baked are typically made available in some backdoor
manner (e.g. under a flag/event that users must set, after signing in blood that
they understand that this is not supported).

> The hold-up is fine for now, because meanwhile other bugs are getting
> fixed and the manuals are getting updated.  But the timeline is not
> infinitely elastic---

Why not?  What real deadline does free software development have?  There might
be practical limits such as the lost opportunity of someone not being available
to help after some date, but it's not like you have to deal with contracts and
paying customers.

Let's not exaggerate.  You can do anything you want wrt development schedules.

> the whole point of a feature freeze is that new
> features are supposed to be ready for testing/integration at more or
> less the same time, instead of waiting on one another.

Which is why features that are not ready get pulled from a release.  But the
timing of releases is typically based on concerns and constraints (e.g.
commercial) that Emacs is for the most part not burdened with.

> Another reason I would prefer to reduce the initial set
> of changes to the minimum working set of "base" code

Hey, if that's the case, then either (a) this feature doesn't belong in 24.1 -
save it altogether for 24.2 or (b) 24.1 should wait until this feature is 100%
ready.

And I thought there had already been a decision to do (b).

> is to get that code into the repository sooner rather
> than later.  

In that case your choice is apparently (a) - not include this feature that is
not fully baked in 24.1.

RE: display-buffer-alist simplifications

[Stephen J. Turnbull]

Drew Adams writes:

 > Why not?  What real deadline does free software development have?

Self-imposed ones.  There are things that are real that are
intangible, as someone who works with software experiences every day.

 > There might be practical limits such as the lost opportunity of
 > someone not being available to help after some date, but it's not
 > like you have to deal with contracts and paying customers.
 > 
 > Let's not exaggerate.  You can do anything you want wrt development
 > schedules.

So can a commercial enterprise, and many failures occur as a result.
But those failures aren't important per se, except to owners; there is
some friction, of course, but the productive resources which have been
freed are reasonably soon applied in new, and on average more
productive, activities.  The real problem here is that users (aka
customers), both current and potential, are suffering while the
company languishes.

The same real problem occurs in a non-profit.  If clients are not
served promptly, something is being wasted.  It's just that measuring
"what is wasted" and "the right thing to do" is much harder if you
don't have profit as a measure, and trading off "different what"s is
much harder.

That doesn't mean non-profit activities are a bad idea; just that
socialism sucks as a management tool.  Still, that's no reason for
abdicating management entirely.

 > Which is why features that are not ready get pulled from a release.
 > But the timing of releases is typically based on concerns and
 > constraints (e.g.  commercial) that Emacs is for the most part not
 > burdened with.

Actually, the only such concern that Emacs is free of is labor
quitting because its pay is in arrears.  But even there, releases are
an incentive for many volunteer hackers.  Seeing your code published
is one example.  The other concerns that commercial enterprises worry
about are merely made much harder to measure in a non-profit because
of lack of concrete management information like "revenue" and "cost",
leading to inefficiencies in decision-making (aka "bike-shedding").

You pride yourself on human factors, Drew.  Economics (and I don't
mean "commerce") is one.  You should learn more about it (at least to
the point where you realize that there's more to it than "contracts
and paying customers".)

Re: display-buffer-alist simplifications

[John Yates]

On Mon, Aug 8, 2011 at 8:26 AM, martin rudalics <rudalics@gmx.at> wrote:
>
> With the scheme sketched above users have no chance to specify what they
> want when they want to use the new design _and_ respect the application
> specifiers.  When they set the new specifiers they would override the
> application.

In recent months face themes have gained significant moment.  This has
been facilitated by the communities' adoption of a limited number of
common faces along with increased consistency in the way that
supported modes use and inherit from those faces.

The problem of customizing buffer display details does not seem to be
nearly as far along.  This is evidenced by the fact that a user
specifies his display rules in terms of buffer names.  That in turn
requires the user to intuit a naming pattern, to hope that all mode
(including those not yet explored) hew to that naming pattern, and to
pray that modes defining buffers matching a given pattern all request
buffer display consistently.  This makes trying to achieve consistent
display behavior across multiple modes feel ad hoc, analogous to
attempting to tame "angry fruit salad".  This is especially true when
trying out a mode that one has not used before.

An alternative might be to identify explicitly a limited number of
buffer display protocols:
- transient selection list
- persistent control panel
- etc

Continuing with the face analogy, such buffer display protocols could
easily include a notion of inheritance.

Displaying a buffer would require subscribing to display a protocol.
(Subscribing to a particular protocol likely would impose additional
requirements / constraints.)  User customization could then be
associated with protocols instead of buffer names.

While a big change from the current gestalt I think that such a scheme
could feel significantly less ad hoc and might be easier for
unsophisticated end users to master.

/john

Re: display-buffer-alist simplifications

[Stefan Monnier]

> At which point you can give up the idea of merging.  I meanwhile know
> that no one here likes the idea of merging specifiers and don't have the
> slightest intention to fight for it any more.  But no one so far has
> cared to explain how to support all the things people have piled up over
> the years like split-height-threshold, even-window-heights, or
> display-buffer-mark-dedicated.  I'd be all in favor of functions if you
> told me how to write a function that within a year has not been
> rewritten completely because it's oh so important to add a little thingy
> here and there.

I think these will have to be handled in each display-buffer-<foo> function.
Of course, that means that to avoid code duplication we'll want to
structure those functions with care.

>>>> (I'll use the word "macro" for now, but we might want to pick another
>>>> word since "macro" can be confused with keyboard macros.)
>>> I'd very much appreciate if someone could invent a more useful term for
>>> these.
>> The name exists already, it's called a function definition.  It's really
>> well supported by a lot of Emacs code: you can document those "macros"
>> in a very simple way, let users get that doc via C-h f, see them work
>> step by step with edebug, have feedback about their correctness/style
>> with M-x byte-compile-file, ...
> We currently have many ways to specify a function for displaying a
> buffer: `display-buffer-function', `special-display-function',
> `pop-up-frame-function', `split-window-preferred-function', the function
> one can specify via `special-display-regexps'.  I know of two people who
> customized the latter - Drew and you.  This doesn't strike me as a story
> of success.

Irrelevant.  I'm not talking about the success of hooks, I'm talking
about the success of functions as a way to name a bunch of things, so you
can reuse them conveniently.
I don't really care if people define their own functions or not: we'll
provide our own set of functions so those who can't define their own can
just chose one of the predefined behaviors.
The hook just provides a good way to structure and modularize the code.

>>>> - `display-buffer-alist' is an alist that maps a matcher (regexp,
>>>> label, or matcher function) to an alist of display specifiers.
>> If display specifiers are of the form (VAR . VAL), then you presumably
>> mean "a list of display specifiers" rather than "an alist of ...".
> It's an alist where the key of each element is a display specifier.

I'm lost.
So display-buffer-alist would be a list of (MATCHER . THINGS) where
THINGS are lists of (DISPLAY-SPECIFIERS . SOMETHING-ELSE)?  What are the
SOMETHING-ELSE and what do they do?

> OK.  I agree with the idea to support the old code and its options as
> fallback and try to get a new behavior.  But what I'm missing is a
> strategy for how to merge-in the re-bindings of the old options within
> the old _and_ the new code.  Things like

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (let ((pop-up-windows t)
> 	  (special-display-buffer-names nil)
> 	  (special-display-regexps nil)
> 	  (same-window-buffer-names nil)
> 	  (same-window-regexps nil))
>       (message-pop-to-buffer (message-buffer-name "mail" to))))

> which I intended to rewrite as

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

Rather than `other-window', my suggestion is to pass a RULE,
i.e. something like '(display-buffer-other-window . ARGS), but yes that
sounds about right.

> would then become

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (let ((pop-up-windows t)
> 	  (special-display-buffer-names nil)
> 	  (special-display-regexps nil)
> 	  (same-window-buffer-names nil)
> 	  (same-window-regexps nil))
>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

No, because the RULE takes precedence over the
display-buffer-default-rule which is the one that obeys pop-up-frames
and stuff.  At least, that's what my idealized design does.
Of course, such paper designs tend to behave unrealistically well.

>> So, as is the case now, your list of specifiers is not truly an alist
>> (i.e. earlier elements don't override later elements), instead it's
>> a mix between an alist and an `or block'?
>> That sounds like a problem.
> If someone told me how to address the problem of merging specifiers in a
> different way I'd be all ears.

My suggestion is to not merge them, basically.


        Stefan

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

Stefan Monnier writes:

 > My suggestion is to not merge them, basically.

XEmacs specifiers do not have a mode locale.  This means that in order
to get mode-specific behavior, you must write mode hook functions that
set up the various parameters per-buffer as they enter the mode.
Guess what?

This sucks for the mode author and is buggy for the user.

I think it's one of the primary reasons only core developers ever
explicitly manipulate specifiers.[1]

Merging really is not that hard to understand, and it's the way people
thing about things.  It sounds simpler to avoid conflict between the
particular implementation of merging and various people's intuitions
and/or needs of special cases, but the alternative is playing whack-a-
mole with the same bug reappearing every time somebody tries to copy
the behavior from one context to another.

This is not a drop-dead you lose argument for merging, but the
conditions for behaviors being discussed do seem to nest frequently:
user preference > mode > mode special buffer > user override.  I think
merging is very natural in this context, and should be considered at
some level.  Without it, the feature will not be used as often as mode
authors and users would like to.

Internal representation is a separate issue.  You can, of course, have
a fine-grained internal representation and merge at declaration time,
or you can simply store the user specs and merge at use time.  These
have subtly different semantics for display, and rather different
semantics if users want to query the spec database for some reason.

Footnotes: 
[1]  The other one is the unfortunate and buggy separation between
"glyph" and "image" objects.  Hi, David!

Re: display-buffer-alist simplifications

[martin rudalics]

 > So display-buffer-alist would be a list of (MATCHER . THINGS) where
 > THINGS are lists of (DISPLAY-SPECIFIERS . SOMETHING-ELSE)?  What are the
 > SOMETHING-ELSE and what do they do?

What the doc-string of `display-buffer-alist' individually describes for
each specifier.  For the reuse-window specifier it's a <window, buffer,
frame> triple, for the pop-up-window specifier it's a list of <window,
side> tuples, and for many other specifiers it's a boolean.

 >> would then become
 >
 >> (defun message-mail-other-window (&optional to subject)
 >>   "Like `message-mail' command, but display mail buffer in another window."
 >>   (interactive)
 >>   (unless (message-mail-user-agent)
 >>     (let ((pop-up-windows t)
 >> 	  (special-display-buffer-names nil)
 >> 	  (special-display-regexps nil)
 >> 	  (same-window-buffer-names nil)
 >> 	  (same-window-regexps nil))
 >>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))
 >
 > No, because the RULE takes precedence over the
 > display-buffer-default-rule which is the one that obeys pop-up-frames
 > and stuff.  At least, that's what my idealized design does.
 > Of course, such paper designs tend to behave unrealistically well.

I'm lost here.  Do you mean that users who prefer the old
`display-buffer' behavior get overridden by the application whenever it
passes an argument but do get the old behavior when the application does
not pass an argument?

martin

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> So display-buffer-alist would be a list of (MATCHER . THINGS) where
>> THINGS are lists of (DISPLAY-SPECIFIERS . SOMETHING-ELSE)?  What are the
>> SOMETHING-ELSE and what do they do?

> What the doc-string of `display-buffer-alist' individually describes for
> each specifier.  For the reuse-window specifier it's a <window, buffer,
> frame> triple, for the pop-up-window specifier it's a list of <window,
> side> tuples, and for many other specifiers it's a boolean.

So, IIUC, compared to

    display-buffer-alist ::= list of (CONDITION . RULE)
    RULE                 ::= (FUNCTIONS . ALIST)
    FUNCTIONS            ::= list of FUNCTION

DISPLAY-SPECIFIERS play the role of FUNCTIONS and the SOMETHING-ELSE is
the ALIST, so it contains arguments to pass to each of the FUNCTIONS and
some of those args may be specific to some of the functions while others
may be obeys by all/some of the functions.

So it looks like we're beginning to converge.

> I'm lost here.  Do you mean that users who prefer the old
> `display-buffer' behavior get overridden by the application whenever
> it passes an argument but do get the old behavior when the application
> does not pass an argument?

Yes.


        Stefan

Re: display-buffer-alist simplifications

[martin rudalics]

 > So, IIUC, compared to
 >
 >     display-buffer-alist ::= list of (CONDITION . RULE)
 >     RULE                 ::= (FUNCTIONS . ALIST)
 >     FUNCTIONS            ::= list of FUNCTION
 >
 > DISPLAY-SPECIFIERS play the role of FUNCTIONS and the SOMETHING-ELSE is
 > the ALIST, so it contains arguments to pass to each of the FUNCTIONS and
 > some of those args may be specific to some of the functions while others
 > may be obeys by all/some of the functions.

With the additional twist that whenever a condition fails, the head of
the alist (including that condition) is no more considered/obeyed for
displaying the buffer.

 >> I'm lost here.  Do you mean that users who prefer the old
 >> `display-buffer' behavior get overridden by the application whenever
 >> it passes an argument but do get the old behavior when the application
 >> does not pass an argument?
 >
 > Yes.

Ouch.

martin

Re: display-buffer-alist simplifications

[Štěpán Němec]

On Wed, 10 Aug 2011 09:09:44 +0200
martin rudalics wrote:

>>> I'm lost here.  Do you mean that users who prefer the old
>>> `display-buffer' behavior get overridden by the application whenever
>>> it passes an argument but do get the old behavior when the application
>>> does not pass an argument?
>>
>> Yes.
>
> Ouch.

Bah! Please don't let this happen. Other than being
inconsistent/confusing/crazy (I'm not quite sure what the "old behavior"
means here), wasn't the main point of the rewrite to give power to the
user? IOW, users must _always_ be able to override what the application
specified.

-- 
Štěpán

Re: display-buffer-alist simplifications

[Stefan Monnier]

>>>> I'm lost here.  Do you mean that users who prefer the old
>>>> `display-buffer' behavior get overridden by the application whenever
>>>> it passes an argument but do get the old behavior when the application
>>>> does not pass an argument?
>>> Yes.
>> Ouch.
> Bah! Please don't let this happen. Other than being
> inconsistent/confusing/crazy (I'm not quite sure what the "old behavior"
> means here), wasn't the main point of the rewrite to give power to the
> user? IOW, users must _always_ be able to override what the application
> specified.

Don't worry about that.  We were only talking about the case where the
user does not use buffer-display-alist.


        Stefan

RE: display-buffer-alist simplifications

[Drew Adams]

> >>> I'm lost here.  Do you mean that users who prefer the old
> >>> `display-buffer' behavior get overridden by the 
> >>> application whenever it passes an argument but do get the
> >>> old behavior when the application does not pass an argument?
> >>
> >> Yes.
> > Ouch.
> 
> Bah! Please don't let this happen. Other than being
> inconsistent/confusing/crazy (I'm not quite sure what the 
> "old behavior" means here), wasn't the main point of the
> rewrite to give power to the user? IOW, users must _always_
> be able to override what the application specified.

+1, yes.

But also vice versa!  A user can choose to use a command or mode that overrides
that user's saved option setting. Simple cases are `set-variable',
`customize-set-variable', `customize-set-value', and making a temporary change
in the Customize UI.

Such a command is Lisp code (an "application"). That does not automatically make
it anti-user or user-bullying. This is as true of code written by the same user
and 3rd-party code as it is of predefined option-setting commands such as
`set-variable'.

It's not simply about user option vs application code.  It's about how the
changes are made: by user request (in one form or another) or by programmatic
fiat (i.e., more or less beyond user control). It's all about respecting the
user. A user can choose to run code, and that code, just like a user setting,
should be able to take precedence.

This is what we do generally in Emacs.  We have saved user settings and code can
override those settings. It is up to the particular code to respect a user's
wishes and put itself at the demand (invocation) of users - e.g. in the form of
a command, minor mode, etc. There is no way to determine a priori whether any
given code is respectful of users in this way.

Attempts to order such things strictly are misguided. Each day that goes by
seems to see this discussion reshuffling the proposed override order or adding
new "levels" to it. No such tower of levels will suffice if you try to rely on
it to enforce things strictly. You will simply confuse the hell out of users
(and maintainers!) and frustrate anyone who tries to do anything unforeseen wrt
your order.

Some default ordering is fine, but there should be no attempt to prevent code
from overriding user settings etc. What we do with `default-frame-alist', face
definitons, etc. is reasonable: users can define their default preferences, but
they can also (e.g. using that bogeyman `code'') change things on the fly.

In Emacs more than other places, users can write code themselves, including code
that dynamically changes their own saved settings. This is Emacs 101.

> users must _always_ be able to override what the application specified.

sm> Don't worry about that.  We were only talking about the case where the
sm> user does not use buffer-display-alist.

Even if a user does use that option (or any other), code should still be able to
override such settings. Don't think automatically "code versus user"; think also
"code invoked on demand by user". There is code and there is code. Not all code
that overrides a saved user setting is doing something the user does not want.

Re: display-buffer-alist simplifications

[Juri Linkov]

> I'm lost here.  Do you mean that users who prefer the old
> `display-buffer' behavior get overridden by the application whenever it
> passes an argument but do get the old behavior when the application does
> not pass an argument?

Maybe in precedence levels instead of

1. default global behavior
2. old user settings (pop-up-windows etc)
3. new display-buffer's arg
4. new user settings (display-buffer-alist)

we should consider

1. default global behavior
2. new display-buffer's arg
3. old user settings (pop-up-windows etc)
4. new user settings (display-buffer-alist)

It provides more backward-compatibility.

A command like `message-mail-other-window' are a special case.
When by its definition a command have to override user settings
then it could use a special specifier like:

  (message-pop-to-buffer (message-buffer-name "mail" to)
                         '(display-buffer-other-window (important . t)))

This is like `!important' in CSS gives priority to some specifications.
From http://www.w3.org/TR/CSS2/cascade.html#important-rules :

  CSS attempts to create a balance of power between author and user
  style sheets.  By default, rules in an author's style sheet
  override those in a user's style sheet.  However, for balance,
  an "!important" declaration takes precedence over a normal declaration.
  Both author and user style sheets may contain "!important" declarations,
  and user "!important" rules override author "!important" rules.

BTW: according to the terminology used in CSS, a RULE consists of
a SELECTOR (a list of conditions matching different contexts),
followed by a DECLARATION BLOCK that consists of a PROPERTY NAME,
followed by a PROPERTY VALUE.

Perhaps the term DECLARATION BLOCK is not better than our current
DISPLAY-SPECIFIERS that consists of DISPLAY-FUNCTION(S) and DISPLAY-ALIST.

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> I'm lost here.  Do you mean that users who prefer the old
>> `display-buffer' behavior get overridden by the application whenever it
>> passes an argument but do get the old behavior when the application does
>> not pass an argument?

> Maybe in precedence levels instead of

> 1. default global behavior
> 2. old user settings (pop-up-windows etc)
> 3. new display-buffer's arg
> 4. new user settings (display-buffer-alist)

> we should consider

> 1. default global behavior
> 2. new display-buffer's arg
> 3. old user settings (pop-up-windows etc)
> 4. new user settings (display-buffer-alist)

All the old user settings should be obeyed by the "default global
behavior" because that should use the old code.  We may want to let some
of the old user settings affect the new display commands, but that would
be done in an ad-hoc way.

So we have

1. display-buffer-default-action (whose default value calls the old
   code which obeys old user settings).
2. display-buffer's arg.
3. display-buffer-alist.

> A command like `message-mail-other-window' are a special case.
> When by its definition a command have to override user settings
> then it could use a special specifier like:

>   (message-pop-to-buffer (message-buffer-name "mail" to)
>                          '(display-buffer-other-window (important . t)))

I think that the best way to handle `info-other-window' and the
"C-x 5 prefix command" is to introduce a fourth level:

4. display-buffer-override-action.

which can be let-bound in info-other-window and temporarily set during
the execution of the next command in a hypothetical C-x 5 prefix command.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

> I'd make a "display method" be a function, i.e. one of
> `display-buffer-reuse-window', `display-buffer-pop-up-window', ...
> At which point you can get rid of the idea of a "macro specifier" since
> function definitions work just as well.

Do you mean that a "display method" should work like
`run-hook-with-args-until-success' to try all specified
buffer-displaying methods until one of them succeeds?

Re: display-buffer-alist simplifications

[Stefan Monnier]

>> I'd make a "display method" be a function, i.e. one of
>> `display-buffer-reuse-window', `display-buffer-pop-up-window', ...
>> At which point you can get rid of the idea of a "macro specifier" since
>> function definitions work just as well.
> Do you mean that a "display method" should work like
> `run-hook-with-args-until-success' to try all specified
> buffer-displaying methods until one of them succeeds?

Well, if we want to allow a list of functions (rather than just
a single function), then yes I think that's what I'd use.


        Stefan

Re: display-buffer-alist simplifications

[Juri Linkov]

>   (setq display-buffer-fallback-alist
>     '("\\*\\(shell\\|unsent mail\\|mail\\|inferior-lisp\\|ielm\\)\\*"
>       (display-buffer-method reuse-window same-frame)
>       (reuse-window-window same)))
>
> Just to be sure we are one the same page, here is how I imagine the
> system would work:
>
>  - "Display specifiers" are cons cells (VAR . VALUE).  For example,
>    (reuse-window-window other) means that when Emacs is trying to reuse
>    a window, it must use a window other than the selected one.
>
>  - `display-buffer-method' is a special display specifier.  Its VALUE is
>    a list of "display-methods", one of `reuse-window', `pop-up-window',
>    etc., or a "macro specifier" (any symbol except the reserved symbols
>    `reuse-window' etc).

Adding `display-buffer-method' in the same common format (VAR . VALUES)
to specify priorities of methods is a nice way to simplify the current
complex merging behavior of `display-buffer-alist'.

>    (I'll use the word "macro" for now, but we might want to pick another
>    word since "macro" can be confused with keyboard macros.)

Why do we need "macro specifiers" at all?  With a well-designed list
of possible specifiers and values for (VAR . VALUE), "macro specifiers"
should be unnecessary.  Another reason to doubt their usefulness is that
they can't help to define such complex specifiers like `near-minibuffer'.

So if the user doesn't like how a hard-coded specifier behaves, then
the user could override its default behavior with other parameters
(VAR . VALUE), and finally when this turns out to be impossible to do,
then write own function and specify it's name in `display-buffer-alist'.

>  - `display-buffer-alist' is an alist that maps a matcher (regexp,
>    label, or matcher function) to an alist of display specifiers.
>
>  - `display-buffer-fallback-alist' is an alist of display specifiers.

Perhaps a better name is `display-buffer-default-alist'.

Re: display-buffer-alist simplifications

[Juri Linkov]

> Here is one suggestion.
>
> 1) Expose all the internal "variables" currently living inside
>    display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes
>    and pop-up-window-min-height.
>
> 2) Make the "display methods" specifier just another one of these
>    variables, e.g. call it `display-buffer-method'.
>
> 3) Change display-buffer-alist so that it is just a method of overriding
>    Lisp variables during display-buffer.

One of the goals for the new design was to avoid the abuse
of Lisp variables intended for user customization by code that
let-binds user options like `pop-up-windows', `same-window-buffer-names',
`same-window-regexps', etc.  So I rather like your earlier proposal
to provide `display-buffer-fallback-alist' where users can study all
settings that define the default behavior and easily override them by
just coping some settings from `display-buffer-fallback-alist' to
`display-buffer-alist' and changing their values.

Re: display-buffer-alist simplifications

[martin rudalics]

 > So I rather like your earlier proposal
 > to provide `display-buffer-fallback-alist' where users can study all
 > settings that define the default behavior and easily override them by
 > just coping some settings from `display-buffer-fallback-alist' to
 > `display-buffer-alist' and changing their values.

Any such thing like `display-buffer-fallback-alist' has to cope with the
variables `special-display-buffer-names' and `special-display-regexps'
which may prescribe individual behavior based on the names of buffers.
There is no "global" default value for all buffers unless we are
prepared to sacrifice compatibility with Emacs 23.

martin

Re: display-buffer-alist simplifications

[martin rudalics]

 > Yes, writing such specifications is useful and "inheritance by regexps"
 > is useful.  But actually I meant inheritance for named specifications
 > like macro specifiers (and they are not required to use regexps).

The problem is that I need at least two variables with very complex
doc-strings then - one for the regexps matching part and one for the
macro specifications.  I'm afraid users won't digest such a design.
Obviously I could make the former only an association of regexps and
macro specifiers and leave the complexity in the design of the macro
specifiers ...

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Let's consider the following example setup:
>
> (setq
>  display-buffer-alist
>  '((((regexp . ".*")) (pop-up-window (largest) (lru)))
>    (((regexp . "^\\*Help\\*$")) (pop-up-window-set-height . fit-window-to-buffer))
>    (((regexp . "^\\*.+\\*$")) (pop-up-window-set-height . 20))
>    (((regexp . ".*")) (pop-up-window-min-height . 15))))
>
> This currently means that a user wants to
>
> (1) Pop up a window for any buffer either below the largest or least
>     recently used window.  The minimum height is 15 lines; if Emacs
>     can't make a window that large, don't bother popping up a window.
>
> (2) For "*...*" buffers try setting the window height to 20 lines.  If
>     this is not possible, leave the height alone.
>
> (3) For *Help* buffers try fitting the window to the height of the
>     buffer.
>
> So the minimum height of the popped up window is inherited for all
> "*...*" buffers.

It is a very bad idea for `display-buffer-alist' to behave like this.
While allowing "flexible" behaviors like the above (which I suspect will
not scale well), it deviates from the typical behavior of alists, where
only the first matching entry in the alist takes effect.  In the above
example, if the first entry matches all buffers, all subsequent entries
in `display-buffer-alist' should have no effect.

Please change display-buffer-alist so that only the first matching entry
is applied.

Re: display-buffer-alist simplifications

[martin rudalics]

 > It is a very bad idea for `display-buffer-alist' to behave like this.
 > While allowing "flexible" behaviors like the above (which I suspect will
 > not scale well), it deviates from the typical behavior of alists, where
 > only the first matching entry in the alist takes effect.  In the above
 > example, if the first entry matches all buffers, all subsequent entries
 > in `display-buffer-alist' should have no effect.
 >
 > Please change display-buffer-alist so that only the first matching entry
 > is applied.

So every single entry has to contain all possible rules for the
corresponding buffer?

martin

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> Please change display-buffer-alist so that only the first matching entry
>> is applied.
>
> So every single entry has to contain all possible rules for the
> corresponding buffer?

Yes---but see the suggestion in my other message about solving this by
exposing the rules as Lisp variables, so that setting the default value
is easy.

Re: display-buffer-alist simplifications

[Stephen J. Turnbull]

martin rudalics writes:

 >  > Please change display-buffer-alist so that only the first matching entry
 >  > is applied.
 > 
 > So every single entry has to contain all possible rules for the
 > corresponding buffer?

How about changing the name to `display-buffer-speclist'?

Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Currently, the reuse-window-even-sizes specifier is set for all
> buffers from the value of `even-window-heights' which is t by default.
> This produces a normalized specifier which is respected whenever a
> window is reused but not written into `display-buffer-alist'.  How
> should I proceed here?

A good way to handle this is to say that :even-windows, if nil or
omitted, means to consult `even-window-heights'.  If the value is
`never' or t, that overrides `even-window-heights'.

Re: display-buffer-alist simplifications

[martin rudalics]

 >> Currently, the reuse-window-even-sizes specifier is set for all
 >> buffers from the value of `even-window-heights' which is t by default.
 >> This produces a normalized specifier which is respected whenever a
 >> window is reused but not written into `display-buffer-alist'.  How
 >> should I proceed here?
 >
 > A good way to handle this is to say that :even-windows, if nil or
 > omitted, means to consult `even-window-heights'.  If the value is
 > `never' or t, that overrides `even-window-heights'.

But this is exactly how things are done currently.  Just that you do
want to turn off such merging for `display-buffer-alist'.  Try to get
the "default" value of `display-buffer-alist' via
`display-buffer-alist-set' from a fresh Emacs started with emacs -Q.
Here this gets me (removing all the scrap introduced by applications
overriding default values in some uncoordinated fashion)

((((regexp . ".*"))
   reuse-window
   (reuse-window nil same nil))
  ...
  (((regexp . ".*"))
   pop-up-window
   (pop-up-window
    (largest)
    (lru))
   (pop-up-window-min-height . 40)
   (pop-up-window-min-width . 80))
  (((regexp . ".*"))
   reuse-window
   (reuse-window-even-sizes . t)))

The last line is the value from `even-window-heights' converted to a
`reuse-window-even-sizes' buffer display specifier.

martin