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