Pop-up-windows vs display-buffer-take-action

Pop-up-windows vs display-buffer-take-action

[T.V Raman]

I notice that pop-up-windows is now deprecated and the doc says to use
the more complex display-buffer-take-action; however that newer option
appears much more complex to configure;  a recipe for getting
something close to the old pop-up-windows t would be nice.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

RE: [External] : Pop-up-windows vs display-buffer-take-action

[Drew Adams]

> I notice that pop-up-windows is now deprecated and the doc says to use
> the more complex display-buffer-take-action; however that newer option
> appears much more complex to configure;  a recipe for getting
> something close to the old pop-up-windows t would be nice.

+1000.

`pop-up-windows' shouldn't have been deprecated.

There's no reason to let the "perfect", Rube
Goldberg, hyper-complicated, `display-buffer-*"
apparatus be the enemy of the good-old, simple,
`pop-up-windows' behavior.

I need `pop-up-windows'.  But then, I've given
up on Emacs 28+ (even 27+) for my own use,
because of other unfortunate breakage.

Emacs 28 added this to the doc string of
`pop-up-windows':

 This variable is provided mainly for backward
 compatibility and should not be used in new code.

Used in code?  It's a _user option_.

Maybe what was meant was that new vanilla
Emacs code will no longer bother to respect
it.  (But if so, why put a guideline for Emacs
development in a user-option doc string?)

Re: [External] : Pop-up-windows vs display-buffer-take-action

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 15 Feb 2023 16:46:28 +0000
> 
> > I notice that pop-up-windows is now deprecated and the doc says to use
> > the more complex display-buffer-take-action; however that newer option
> > appears much more complex to configure;  a recipe for getting
> > something close to the old pop-up-windows t would be nice.
> 
> +1000.
> 
> `pop-up-windows' shouldn't have been deprecated.

Are we now going to pick up fights lost 12 years ago?  Really?

And where do you see that this variable is deprecated, btw?

RE: [External] : Pop-up-windows vs display-buffer-take-action

[Drew Adams]

> > > I notice that pop-up-windows is now deprecated and the doc says to use
> > > the more complex display-buffer-take-action; however that newer option
> > > appears much more complex to configure;  a recipe for getting
> > > something close to the old pop-up-windows t would be nice.
> >
> > +1000.
> >
> > `pop-up-windows' shouldn't have been deprecated.
> 
> Are we now going to pick up fights lost 12 years ago?  Really?

Not picking any fights.  Expressing my sadness
that this happened.  (But you lifted my spirits
by suggesting/hinting (?), below, that it's
_not_ deprecated.)

> And where do you see that this variable is deprecated, btw?

You're right that I didn't see the word
"deprecated" as such.  If you think
"deprecated" is not meant, so much the better.
Glad to hear that.

To be clearer, the (28.2) doc string says this:

 This variable is provided mainly for backward
 compatibility and should not be used in new code.
 To make 'display-buffer' behave as if this were t,
 customize 'display-buffer-base-action' instead.

What I pointed out wrt referring to "used in new
code" stands.  This seems to be telling someone
(users of the option in new code? who is that?
what kinds of code use options?) that they
should customize a different option.

If this wants to tell users to use one option
instead of another, why is it talking about using
the other (apparently nondeprecated) option "in
code"?

Re: [External] : Pop-up-windows vs display-buffer-take-action

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "raman@google.com" <raman@google.com>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>
> Date: Wed, 15 Feb 2023 17:38:34 +0000
> 
> > And where do you see that this variable is deprecated, btw?
> 
> You're right that I didn't see the word
> "deprecated" as such.  If you think
> "deprecated" is not meant, so much the better.
> Glad to hear that.
> 
> To be clearer, the (28.2) doc string says this:
> 
>  This variable is provided mainly for backward
>  compatibility and should not be used in new code.
>  To make 'display-buffer' behave as if this were t,
>  customize 'display-buffer-base-action' instead.

That doesn't sound like deprecation to me.

> What I pointed out wrt referring to "used in new
> code" stands.

That's a recommendation, nothing more, nothing less.

RE: [External] : Pop-up-windows vs display-buffer-take-action

[Drew Adams]

> > > > `pop-up-windows' shouldn't have been deprecated.
> > >
> > > Are we now going to pick up fights lost 12 years
> > > ago?  Really?
> >
> > Not picking any fights.  Expressing my sadness
> > that this happened.  (But you lifted my spirits
> > by suggesting/hinting (?), below, that it's
> > _not_ deprecated.)
> >
> > > And where do you see that this variable is deprecated, btw?
> >
> > You're right that I didn't see the word
> > "deprecated" as such.  If you think
> > "deprecated" is not meant, so much the better.
> > Glad to hear that.
> >
> > To be clearer, the (28.2) doc string says this:
> >
> >  This variable is provided mainly for backward
> >  compatibility and should not be used in new code.
> >  To make 'display-buffer' behave as if this were t,
> >  customize 'display-buffer-base-action' instead.
> 
> That doesn't sound like deprecation to me.

Good to know.  It sounded like it to me.

So then what was the "fight" "lost 12 years
ago"?  Did it have anything at all to do
with this thread?

It can't have been about that addition (in
Emacs 28) to the doc string.  Emacs 28 was
released only a year ago. 

> > What I pointed out wrt referring to 
> > "used in new code" stands.
> 
> That's a recommendation, nothing more, nothing less.

But just what's being recommended to users
about this option?

It doesn't just recommend to use option
`display-buffer-base-action' instead.

It specifically says that user option
`pop-up-windows' "should not be used in
new code."  What does it mean to "use" a
user option in code?  And whose "new code"
is it talking about - code by users of the
option?

Are we recommending to users of option
`pop-up-windows" not to use it in new code
(whatever that might mean)?  Or are we just
recommending to users to use
`display-buffer-base-action' instead of
option `pop-up-windows'?

Do you perhaps see the statement about not
using `pop-up-windows' in new code as
meaningless, and think it should be removed?

If not, do you at least see that it's not
clear?  If so, please consider clarifying
what's meant by use of the option in code.
____

In any case, T.V. Raman's point/request was
this (which I've also requested in the past):

  that newer option appears much more complex
  to configure;  a recipe for getting
  something close to the old pop-up-windows t
  would be nice.

Indeed.  How to get that behavior, or even
close to it, with `display-buffer-base-action'?
That's never been answered, to my knowledge.

If `pop-up-windows' can do what it does then
the all-inclusive, enhanced `display-buffer'
paraphernalia should also be able to do it, no?

And in particular, we should be able to then
offer users a simple Boolean option or mode
(or at least close to it) to do that, based
on the `display-buffer' scaffolding, no?

So far, I think the answer given has been,
alas, "no".  And yet we tell users to use
`display-buffer-base-action' as a substitute?

If Emacs can't do it, how do we expect users
to do it?

Re: [External] : Pop-up-windows vs display-buffer-take-action

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "raman@google.com" <raman@google.com>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>
> Date: Wed, 15 Feb 2023 20:00:35 +0000
> 
> So then what was the "fight" "lost 12 years
> ago"?

That sentence being inserted into the manual.

> It can't have been about that addition (in
> Emacs 28) to the doc string.  Emacs 28 was
> released only a year ago. 

This text in the manual is from 2011.

> But just what's being recommended to users
> about this option?

What the text says: don't use it in Lisp programs.  And please don't
expect me to explain more, because I don't know about display-buffer
actions more than the next guy.  I never use them, and try very hard
to stay as far as possible from them, to keep my sanity.
>   that newer option appears much more complex
>   to configure;  a recipe for getting
>   something close to the old pop-up-windows t
>   would be nice.
> 
> Indeed.  How to get that behavior, or even
> close to it, with `display-buffer-base-action'?
> That's never been answered, to my knowledge.

My answer: keep using pop-up-windows.

Re: [External] : Pop-up-windows vs display-buffer-take-action

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 774 bytes --]

Given what you say, it would be useful to users if we trimmed the doc
string of  pop-up-windows which presently reads:

pop-up-windows is a variable defined in window.el.

Its value is nil
Original value was t

Non-nil means display-buffer should make a new window.
This variable is provided mainly for backward compatibility and
should not be used in new code.  To make display-buffer behave
as if this were t, customize display-buffer-base-action
instead.  See Info node (elisp) Choosing Window Options in the
Emacs Lisp manual for an example.
Drop everything except the first sentence would be my recommendation.

  You can customize this variable.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: [External] : Pop-up-windows vs display-buffer-take-action

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: Drew Adams <drew.adams@oracle.com>,  emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 12:49:14 -0800
> 
> Given what you say, it would be useful to users if we trimmed the doc
> string of  pop-up-windows which presently reads:

Sorry, but I disagree.  I see nothing wrong in the current doc string:
it is completely legitimate for Emacs developers to advise users and
Lisp programmers about the best practices, as it is legitimate for the
users and programmers to decide to ignore the advice, if they have
good reasons.