`pop-up-frames' and binding/setting user options [was: Documenting buffer display]

`pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

>  > I disagree. If the behavior is documented in
>  > the command's doc string, as it should be, then
>  > the user is aware of it. Using a given command
>  > is a user choice. There is no reason to put on
>  > the hair shirt of not binding a user option in
>  > a user command, as long as the behavior is
>  > documented and the command ends always by
>  > restoring the user's preferred value for the
>  > option.
> 
> A user option has to be respected.

A _user_ has to be respected.  A user has a right
to define or use a command that changes the value
of a user option, whether that change is temporary
(for the duration of the command) or stays in
effect after the command.

This should be obvious.  Think toggle command, as
the most obvious case.  Emacs defines commands
that toggle or otherwise set option values - and
so do users define such commands.

What makes that use case OK?  (1) That's the very
intention of the command: to change the option
value.  And (2) the command doc makes this quite
clear to users.  If you don't want to change the
option value then you don't invoke the command.
Nothing special here.

And BTW, it makes perfect sense for a command
that acts just like an other-window command, but
uses other-frame instead of other-window, to
bind `pop-up-frames'.

That's precisely the meaning of `pop-up-frames':
make other-window commands use other-frame.  And
such a command leaves the option value just as
it was, when done.

We create user options for user convenience.
They are not something that should limit users.

> If the designer of a command sees no other way to
> have a command do what it is supposed to do than by
> overriding a user option we have a severe design problem.

I disagree with such must-not-be-any-other-way
rigidity.  There is no reason, IMO, why a
command definition cannot change an option value,
as long as the command doc makes that behavior
clear.  And in particular when that's the very
raison d'etre for the command.

As I said, I recognize that my opinion is maybe
not the policy of Emacs (or perhaps of only an
inflexible interpretation of the policy - dunno).
Such a rigid policy is not wise, IMO.

> 'display-buffer' has no design problem because
> programmers can always ask it to do what they want
> by specifying the ACTION argument appropriately.

(No one has said that `display-buffer' has a
design problem, AFAIK.)

There is more than one way to do something in
Emacs.  Just because users can manipulate
`display-buffer' to do something, that's no
reason that they should be limited to using it
directly.

That there exists one way to do something is not
a reason not to sometimes do it another way.
Otherwise we would never create high-level
convenience constructs and would just encourage
users to directly use low-level building blocks.

And, as that long-ago article from RMS about the
utility (for Emacs) of dynamic binding shows, the
fact that you can pass arguments to functions is
no good substitute for being able to change the
behavior of a function by dynamically binding a
variable.  Especially when the variable is well
known to users and well documented.

No one argues that global variables cannot make
for debugging difficulties.  They clearly couple
code parts in a non-modular way.  Lisp is not
Haskell, and there are many, many ways in Lisp
to couple code (and data) so that the behavior
is not obvious and not just local.

Just because you can do all kinds of things that
couple code (and data) in Lisp is no reason that
you should do so gratuitously and in silly ways.

But it's also not a reason to forbid developers
from making use of such possibilities when they
make sense.  That Emacs gives you plenty of rope
that you can use to hang yourself is not a reason
for it not to give you rope or to tell you not to
use this or that rope it provides.

> Telling programmers to bind a user option
> instead is an invitation to bad design.

Did anyone tell programmers that they must always
bind a variable instead of passing an argument to
a function?  I don't think so.

Who's making a black-&-white pronouncement of
what everyone should always do or not do?  If
that's happening it's not happening in the
direction of must-bind-variable.

>  > Secondly, users themselves define commands,
>  > and the ability to bind such a variable -
>  > whether it is an option or not, is very
>  > useful for users.
> 
> And when such users become programmers we get
> our problems through the backdoor, compare the
> recent "open bookmark in other frame" thread.

What's your problem with that thread?  I guess
it's this code:

(let ((pop-up-frames  t))
  (bookmark-jump-other-window bookmark))

Nothing could be simpler, clearer, or more
elegant for a command that jumps to a bookmark
in another frame, IMO.

Telling someone that they must instead use
`display-buffer' ACTION hoops to accomplish
the same thing leads them down the garden path,
on a wild goose chase, over the river & through
the woods, and around Robin Hood's barn.  IMO.

But I didn't insist on that code.  Far from it.
I could see such a complaint coming from some
quarters, which is why I suggested to "do the
equivalent of [that code], or similar".  And:

  Non-nil `pop-up-frames' just makes
  "other-window" commands use "other-frame".

  I wrote "the equivalent of this, or similar",
  because someone will perhaps say that there is
  a more "modern" way to do the same thing,
  involving a `display-buffer' ACTION or
  something...

  The above code DTRT, but someone might prefer
  a different formulation that does the same
  thing, or similar.

Why did I write such qualification, even at
the outset?  Why anticipate the possibility of
a knee-jerk reaction to binding a user option?
Why indeed.

Now I even wonder, since you pointed to that
thread, whether my showing `pop-up-frames'
there was perhaps a catalyst for your recent
discouragement of `pop-up-frames' in the doc.

(To reiterate: I do applaud your trying to
clarify the buffer-display doc, other than
the proposed change wrt `pop-up-buffers'.)

To be extra clear: As I said there, I have no
objection to someone writing the Emacs code
for an other-frame bookmark-jump command in a
way that is more round-about, in order to
avoid using `pop-up-frames'.

I personally wouldn't (and didn't) do that.  I
defined it in my code just as I wrote it there.

But I make no pretense of imposing such a "bad
design" style on Emacs.  My wish is only for
Emacs to not discourage it, and for Emacs to
continue to support helpful constructs such as
`pop-up-frames' and `special-display-regexps'.
I still hope it will.

And more generally, I wish that Emacs would
not discourage, let alone forbid, the useful
binding and setting of user options in
commands.

That it sometimes might not make sense for
a command to change the value of an option
is no reason to insist that it doesn't make
sense in general.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Eli Zaretskii]

> Date: Sun, 21 Oct 2018 09:10:20 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > A user option has to be respected.
> 
> A _user_ has to be respected.

Yes.  And they _are_ respected.

I don't really understand what are you arguing about here.  There's
nothing wrong in deprecating certain interfaces if we find that they
get in the way of Emacs development and/or maintenance.  As long as
the "old ways" are supported and documented, no one and nothing is
harmed.  You've voiced your opinion in favor of pop-up-frames etc.,
and against favoring display-buffer and friends, and we happen to
disagree with it.  There's no need to continue arguing that same
argument, as the disagreement is clear.  It is entirely okay for Emacs
developers to try to encourage users to use the interfaces we favor,
even if you happen to disagree.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[martin rudalics]

 > And BTW, it makes perfect sense for a command
 > that acts just like an other-window command, but
 > uses other-frame instead of other-window, to
 > bind `pop-up-frames'.
 >
 > That's precisely the meaning of `pop-up-frames':
 > make other-window commands use other-frame.

No.  The call to that command might conflict with the user's intention
to usually pop up a new frame for most buffers but to not pop up a new
frame for some _specific buffer_ whose name is specified in
'display-buffer-alist'.  The binding of 'pop-up-frames' might defeat
precisely that latter intention (even if we do our best to avoid it).

 > We create user options for user convenience.
 > They are not something that should limit users.

Overriding the customization of 'display-buffer-alist' does limit the
user.

 > Did anyone tell programmers that they must always
 > bind a variable instead of passing an argument to
 > a function?  I don't think so.

On the contrary we tell programmers to not bind a variable and always
pass an argument instead.

 > What's your problem with that thread?  I guess
 > it's this code:
 >
 > (let ((pop-up-frames  t))
 >    (bookmark-jump-other-window bookmark))
 >
 > Nothing could be simpler, clearer, or more
 > elegant for a command that jumps to a bookmark
 > in another frame, IMO.

Unless it's a specific bookmark the user wants to handle specifically.

 > Now I even wonder, since you pointed to that
 > thread, whether my showing `pop-up-frames'
 > there was perhaps a catalyst for your recent
 > discouragement of `pop-up-frames' in the doc.

Quite on the contrary.  The only thing I appreciated in that thread
was what you wrote (and cited here).

martin

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

>  > And BTW, it makes perfect sense for a command
>  > that acts just like an other-window command, but
>  > uses other-frame instead of other-window, to
>  > bind `pop-up-frames'.
>  >
>  > That's precisely the meaning of `pop-up-frames':
>  > make other-window commands use other-frame.
> 
> No.  The call to that command might conflict with the user's intention
> to usually pop up a new frame for most buffers but to not pop up a new
> frame for some _specific buffer_ whose name is specified in
> 'display-buffer-alist'.  The binding of 'pop-up-frames' might defeat
> precisely that latter intention (even if we do our best to avoid it).

Users can do lots of things that conflict with each other.

The point here is that it is a _user_ choice to use the
command.  If the command doc makes clear what its behavior
is then I see no problem.  Any user who does _not_ want
a command that overrides particular user settings should
simply not use that command.

And it is pretty easy for a user to writer her own such
commands.  It is especially easy to write a command that
provides non-nil `pop-up-frames' behavior.

Granted, it is a bit more difficult to write a command
that does that using `display-buffer-alist', and even
more difficult to write a command that provides
`pop-up-frames'-like behavior except for particular
buffers.  In such cases users can have recourse to
`display-buffer-alist'.

But for the simple case, `pop-up-frames' is handy.
That's the point of it.
 
>  > We create user options for user convenience.
>  > They are not something that should limit users.
> 
> Overriding the customization of 'display-buffer-alist'
> does limit the user.

A command that the user does not invoke does not override
anything.  She decides whether to invoke it.

>  > Did anyone tell programmers that they must always
>  > bind a variable instead of passing an argument to
>  > a function?  I don't think so.
> 
> On the contrary we tell programmers to not bind a variable
> and always pass an argument instead.

I don't.  I don't tell them to do any such thing _always_.

Telling people that is black-&-white, and misleading.
Emacs Lisp has dynamic binding (as well as lexical
binding) for a reason.  It's not C, and it's not Scheme.

Not to mention that you cannot "always pass an argument"
instead.  Not without recoding the world, at least.  See
RMS's article for good, simple examples.

Emacs Lisp is for Emacs - an interactive program.  Sure,
all of the advantages of lexical scoping are nice, but
performance, for example, is in many instances not as
important for Emacs as for other programming contexts.
Optimization is, for Emacs, a nice-to-have, in general.

Likewise, the better ability to reason about program
behavior that lexical scoping brings.  Likewise, the
reduced funarg problems.

But (1) we have lexical scoping now (and I, for one,
am in favor of it being on by default, as in Common
Lisp), and (2) if we really want solid semantic
behavior (no funarg problems at all) then we should
move to a purely functional, fully lazy language.
I don't see #2 happening, and it need not.  Emacs
Lisp is a good language for Emacs.

Emacs Lisp is a general programming language, but it
is also specifically aimed at Emacs - human-scale,
interactive use.

>  > What's your problem with that thread?  I guess
>  > it's this code:
>  >
>  > (let ((pop-up-frames  t))
>  >    (bookmark-jump-other-window bookmark))
>  >
>  > Nothing could be simpler, clearer, or more
>  > elegant for a command that jumps to a bookmark
>  > in another frame, IMO.
> 
> Unless it's a specific bookmark the user wants to handle specifically.

Maybe you meant "buffer" instead of "bookmark".
(I often make that typo, in both directions.)

But maybe you did mean bookmark.  And the bookmark
code gives you the possibility of treating specific
bookmarks differently.  And this code is for a
_command_ whose job is specifically to pop to the
bookmark in another frame.  If you don't want that
behavior for a particular bookmark then you won't
use that command - you'll use a different command.

So there are multiple ways around your problem.
Two of them are: (1) specify specific behavior for
a specific bookmark and (2) use a different command.

If you do want specific _buffers_ to be handled
specially then you can of course have recourse to
the general toolkit that is `display-buffer-alist'.
No problem.

And even before doing that you might well get what
you want just by using `special-display-buffer-names'
or `special-display-regexps'.

Those things don't pretend to do all that the
`display-buffer-alist' toolkit does - that's not
their aim.  They are conveniences.  Having them -
in _addition_ to `display-buffer-alist' - is an
advantage, not a disadvantage.

>  > Now I even wonder, since you pointed to that
>  > thread, whether my showing `pop-up-frames'
>  > there was perhaps a catalyst for your recent
>  > discouragement of `pop-up-frames' in the doc.
> 
> Quite on the contrary.  The only thing I appreciated
> in that thread was what you wrote (and cited here).

Glad it helped in some way.  I'm looking for an
Emacs that continues to allow conveniences such as
`pop-up-frames' to cohabit peacefully with more
powerful constructs such as `display-buffer-alist'.

And thank you again for working on the doc for
all of this - that's truly helpful.  `display-buffer',
like font-lock, keymaps, syntax tables, and a few
other things in Emacs Lisp, is powerful and
complicated.

But it is more likely that an ordinary user will
need to do the kinds of things that `display-buffer'
offers than that she will need to fiddle with those
other complex things (font-lock etc.).

This means that it is good to help users a bit more
with this doc, making it easy to understand.  It also
means, IMO, that it is good to promote, not discourage,
simple conveniences such as `pop-up-frames' and
`special-display-*'.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[martin rudalics]

 > Not to mention that you cannot "always pass an argument"
 > instead.

The canonical way for a program to affect the behavior of
'display-buffer' is to pass an argument.  Everything else is
discouraged.  'display-buffer-overriding-action' is the only
construct to override the user and should be used with care.

 > Not without recoding the world, at least.  See
 > RMS's article for good, simple examples.
 >
 > Emacs Lisp is for Emacs - an interactive program.  Sure,
 > all of the advantages of lexical scoping are nice, but
 > performance, for example, is in many instances not as
 > important for Emacs as for other programming contexts.
 > Optimization is, for Emacs, a nice-to-have, in general.
 >
 > Likewise, the better ability to reason about program
 > behavior that lexical scoping brings.  Likewise, the
 > reduced funarg problems.
 >
 > But (1) we have lexical scoping now (and I, for one,
 > am in favor of it being on by default, as in Common
 > Lisp), and (2) if we really want solid semantic
 > behavior (no funarg problems at all) then we should
 > move to a purely functional, fully lazy language.
 > I don't see #2 happening, and it need not.  Emacs
 > Lisp is a good language for Emacs.

What do all these have to do with the subject at hand?

 >> Unless it's a specific bookmark the user wants to handle specifically.
 >
 > Maybe you meant "buffer" instead of "bookmark".

I meant bookmark - a position in a buffer stored for later perusal.
Why else would we be discussing 'display-buffer' in this context?

 > (I often make that typo, in both directions.)
 >
 > But maybe you did mean bookmark.  And the bookmark
 > code gives you the possibility of treating specific
 > bookmarks differently.  And this code is for a
 > _command_ whose job is specifically to pop to the
 > bookmark in another frame.  If you don't want that
 > behavior for a particular bookmark then you won't
 > use that command - you'll use a different command.

This command would be for usually popping up the bookmark in another
frame and the user would know that.  However, for certain, specified
bookmarks the user might want to use the selected frame instead and
still use the same command.  If this command forces the use of the
selected frame by binding some global variable instead of passing an
appropriate action argument, it inhibits the user to customize its
behavior.  Just like calling 'switch-to-buffer' inhibits the user to
pop to a buffer in another window or frame.

 > So there are multiple ways around your problem.
 > Two of them are: (1) specify specific behavior for
 > a specific bookmark and (2) use a different command.
 >
 > If you do want specific _buffers_ to be handled
 > specially then you can of course have recourse to
 > the general toolkit that is `display-buffer-alist'.
 > No problem.

Unless the application overrides it.

martin

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

> This command would be for usually popping up the bookmark in another
> frame and the user would know that.  However, for certain, specified
> bookmarks the user might want to use the selected frame instead and
> still use the same command.

Why would someone choose to use an `other-frame'
command to get some behavior other than `other-frame'?

Especially since there are other bookmark jumping
commands that do not use another frame?  The point
of the thread that this discussion responds to was
to add an other-frame bookmark jump command.  We
already have other bookmark-jump commands for the
same window and for another window.

And it is trivial to define your own bookmark jump
command to do whatever you like that is special,
whether for a specific bookmark, specific jump
behavior, or whatever.

In particular, predefined command `bookmark-jump',
and some other jump commands, just invoke the
general function `bookmark--jump-via', which accepts
(surprise!) a DISPLAY-FUNCTION argument.

That's the _only_ difference between some of those
jump commands: the DISPLAY-FUNCTION argument passed.

But since `bookmark-jump' itself accepts an optional
DISPLAY-FUNCTION argument (which it just passes on
to `bookmark--jump-via'), you can just as well call
`bookmark-jump' instead of `bookmark--jump-via'.
And BTW, that's what `bookmark-jump-other-window' does.

And yes, if one prefers, `bookmark-jump-other-frame'
could also be defined the same way (either of those
ways).  Or it could be defined by calling
`bookmark-jump-other-window' while binding
`pop-up-frames'.  It doesn't matter to me which
approach is taken for that.  And it shouldn't matter
to users - same behavior, AFAIK.

> If this command forces the use of the
> selected frame by binding some global variable instead of passing an
> appropriate action argument,

If the action argument passed just says to use another
frame then the result is the same, no?  It certainly
seems the same in the question at hand,
`bookmark-jump-other-frame'.  In both cases the
command "forces the use" of some particular display
action.

> it inhibits the user to customize its
> behavior.  Just like calling 'switch-to-buffer' inhibits the user to
> pop to a buffer in another window or frame.

A command that calls `switch-to-buffer' has different
behavior from one that pops to a buffer in another
window or frame.  So what?  We have different commands
for these possibilities.  Each of those commands
"inhibits the user", providing only a specific
buffer-display behavior.

(But not `bookmark-jump' (or `bookmark--jump-via',
which is not a command) - it doesn't inhibit using it
to display a buffer anyway you like.)

>  > So there are multiple ways around your problem.
>  > Two of them are: (1) specify specific behavior for
>  > a specific bookmark and (2) use a different command.
>  >
>  > If you do want specific _buffers_ to be handled
>  > specially then you can of course have recourse to
>  > the general toolkit that is `display-buffer-alist'.
>  > No problem.
> 
> Unless the application overrides it.

Each of those specific bookmark jump commands
specifies a particular buffer-display behavior
(except `bookmark-jump', which accepts a behavior
argument).  Is that what you call the application
overriding it?

Again, if you want specific display behavior you
can get it.  If you want one of the predefined
behaviors you can have that too.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[martin rudalics]

 >> This command would be for usually popping up the bookmark in another
 >> frame and the user would know that.  However, for certain, specified
 >> bookmarks the user might want to use the selected frame instead and
 >> still use the same command.
 >
 > Why would someone choose to use an `other-frame'
 > command to get some behavior other than `other-frame'?

Because for a user 'other-frame' may be TRT for most bookmarks but not
for a few specific ones.

 > Each of those specific bookmark jump commands
 > specifies a particular buffer-display behavior
 > (except `bookmark-jump', which accepts a behavior
 > argument).  Is that what you call the application
 > overriding it?

No.  It's the way the command specifies the behavior: If it does so by
binding a global variable, the result may be equivocal when the user
has customized 'display-buffer-alist'.  If it does so by setting the
ACTION argument, the result is unequivocal.

martin

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

>  >> This command would be for usually popping up the bookmark in another
>  >> frame and the user would know that.  However, for certain, specified
>  >> bookmarks the user might want to use the selected frame instead and
>  >> still use the same command.
>  >
>  > Why would someone choose to use an `other-frame'
>  > command to get some behavior other than `other-frame'?
> 
> Because for a user 'other-frame' may be TRT for most bookmarks but not
> for a few specific ones.

Sure, we both acknowledged that.  But why would you
choose to use an `other-frame' command for those
specific bookmarks for which it is not TRT?  That's
the question.

>  > Each of those specific bookmark jump commands
>  > specifies a particular buffer-display behavior
>  > (except `bookmark-jump', which accepts a behavior
>  > argument).  Is that what you call the application
>  > overriding it?
> 
> No.  It's the way the command specifies the behavior: If it does so by
> binding a global variable, the result may be equivocal when the user
> has customized 'display-buffer-alist'.  If it does so by setting the
> ACTION argument, the result is unequivocal.

Specifics, please.  If by equivocal you mean here that
a user may not get what she expects sometimes then I
imagine that the answer is to not use that approach in
that case.

So far, you haven't shown (AFAICT) any difference
between binding `pop-up-frames' and imposing the same
behavior by passing an ACTION argument.  But if there
is a difference in some case then I'd think the answer
would be to use whichever of those approaches DTRT,
and not the other.

Is your argument against `pop-up-frames' only that
of a maintainer - not wanting to bother maintaining
support?  Or is it that you see it as a bad thing
for users to be able to use `pop-up-frames'?

Saying that in some case (which I haven't seen
demonstrated yet) it doesn't do the same thing that
passing an equivalent argument does, does not
invalidate its usefulness.  At most it would be an
argument for not using it in those hypothetical
problematic cases.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Stefan Monnier]

> Sure, we both acknowledged that.  But why would you
> choose to use an `other-frame' command for those
> specific bookmarks for which it is not TRT?  That's
> the question.

Because the user doesn't want to have to think about it.  So he always
uses the same key-binding and then configures display-buffer-alist to
adjust the behavior for those corner cases where another frame is not
the right destination.


        Stefan

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

> > Sure, we both acknowledged that.  But why would you
> > choose to use an `other-frame' command for those
> > specific bookmarks for which it is not TRT?  That's
> > the question.
> 
> Because the user doesn't want to have to think about it.  So he always
> uses the same key-binding and then configures display-buffer-alist to
> adjust the behavior for those corner cases where another frame is not
> the right destination.

Nothing wrong with doing that.  That's similar to
using `special-display-buffer-names'.  (Not the same,
but similar.)

There are alternative ways to get such an effect
(including by doing the same thing for a different
one of the bookmark-jump commands).  We have
same-window, other-window, and other-frame.  Any
of them could have its effect overridden in the
way you suggest.

And there are other approaches, including using
a command that calls `bookmark-jump' passing a
DISPLAY-FUNC argument what the user wants.  That's
much more trivial for a user to do than fiddling
with `display-buffer-alist' to accomplish the same
thing.

None of this seems to me to be an argument against
`pop-up-frames'.  Nor does it seem to be an argument
against having more than one bookmark-jump command,
for a different display behaviors.

See Eli's message today for reasons for the latter.
More generally, see his msg for general arguments
in favor of not promoting user customization of
`display-buffer-alist' as the starting point for
adjusting specific buffer display, especially
command-specific actions.

His arguments are mine too in this regard.

And I add user conveniences such as `pop-up-frames'
and `special-display-*' options to things that we
should promote, not discourage, as user starting
points for getting some specific buffer display
and window selection behavior.

`display-buffer-alist' is great to have.  But
specific this-window, other-window, and other-frame
commands, as well as options such as `pop-up-frames'
and `special-display-*', are better starting points
for most users.

I don't object to `display-buffer-alist'.
I object to promoting its use to the exclusion of
other, simpler ways of doing some of what it does.
I object to _immediately_ throwing users down that
rabbit hole.

I recognize that `display-buffer' is a complex
subject, and its complete and correct doc is
bound to be somewhat hard to grasp.  I don't
have a problem with the doc being complete and
correct - au contraire.

What I object to is having the doc end up being
_only_ that, or even pushing users to that as
the starting point.  As Eli said tactfully,
`display-buffer-alist' should not be the _first
resort_.  Emacs provides some simpler ways to
do some of what it offers, and those are better
starting points, in general.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Stefan Monnier]

> That's similar to using `special-display-buffer-names'.
> (Not the same, but similar.)

You're confused: it's exactly the same.  `display-buffer-alist` is
nothing but a replacement for `special-display-buffer-names`.

You can do exactly the same with either of them.
We had to introduce `display-buffer-alist` to replace
`special-display-buffer-names` only for "minor" consistency reasons, to
better interact with other ways to specify how to display a buffer.


        Stefan

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Stefan Monnier]

>> That's similar to using `special-display-buffer-names'.
>> (Not the same, but similar.)
> You're confused: it's exactly the same.  `display-buffer-alist` is
> nothing but a replacement for `special-display-buffer-names`.

Hmm... rereading the above, I believe my wording was very poorly chosen.
I didn't mean it to sound so critical.  Also this whole part of your
message was in the end largely irrelevant to your actual message.
So, please try and just ignore the above, sorry,


        Stefan

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

> >> That's similar to using `special-display-buffer-names'.
> >> (Not the same, but similar.)
> > You're confused: it's exactly the same.  `display-buffer-alist` is
> > nothing but a replacement for `special-display-buffer-names`.
> 
> Hmm... rereading the above, I believe my wording was very poorly chosen.
> I didn't mean it to sound so critical.  Also this whole part of your
> message was in the end largely irrelevant to your actual message.
> So, please try and just ignore the above, sorry,

No problem.  We're all trying to work something out
here, and maybe come to an approximate consensus.
Opinions can be strong sometimes even when the real
differences seem slight to others.  And email is not
necessarily the easiest way to find common ground.

RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[Drew Adams]

> > That's similar to using `special-display-buffer-names'.
> > (Not the same, but similar.)
> 
> You're confused: it's exactly the same.  `display-buffer-alist` is
> nothing but a replacement for `special-display-buffer-names`.

I should have said "I'm not sure it's always exactly
the same, but it's at least quite similar."

> You can do exactly the same with either of them.
> We had to introduce `display-buffer-alist` to replace
> `special-display-buffer-names` only for "minor" consistency reasons, to
> better interact with other ways to specify how to display a buffer.

Very good.

Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[martin rudalics]

 > Sure, we both acknowledged that.  But why would you
 > choose to use an `other-frame' command for those
 > specific bookmarks for which it is not TRT?  That's
 > the question.

Because it might be the nearest existing approximation of what the
user wants.

 > Is your argument against `pop-up-frames' only that
 > of a maintainer - not wanting to bother maintaining
 > support?  Or is it that you see it as a bad thing
 > for users to be able to use `pop-up-frames'?
 >
 > Saying that in some case (which I haven't seen
 > demonstrated yet) it doesn't do the same thing that
 > passing an equivalent argument does, does not
 > invalidate its usefulness.  At most it would be an
 > argument for not using it in those hypothetical
 > problematic cases.

'pop-up-frames' cannot be considered in isolation.  It is accompanied
by two additional options - 'pop-up-frame-function' which specifies
the function to call when 'pop-up-frames' is non-nil and
'pop-up-frame-alist' which specifies the parameters passed to that
function.  The implementation of the latter is not guaranteed to
always do what the user wants as I now mention in the manual text and
I have no idea how to fix that.  IMO 'display-buffer-pop-up-frame'
should never have used 'pop-up-frame-function' and
'pop-up-frame-alist' in the first place.  This is a design flaw that
AFAICT cannot be corrected at the present stage without introducing
yet another behavioral incompatibility.  And it has minor importance
because there is no need to use 'pop-up-frames' nowadays.

martin