* Pop-up-windows vs display-buffer-take-action @ 2023-02-15 15:26 T.V Raman 2023-02-15 16:46 ` [External] : " Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: T.V Raman @ 2023-02-15 15:26 UTC (permalink / raw) To: emacs-devel 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 🦮 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 15:26 Pop-up-windows vs display-buffer-take-action T.V Raman @ 2023-02-15 16:46 ` Drew Adams 2023-02-15 17:20 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2023-02-15 16:46 UTC (permalink / raw) To: T.V Raman, emacs-devel@gnu.org > 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?) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 16:46 ` [External] : " Drew Adams @ 2023-02-15 17:20 ` Eli Zaretskii 2023-02-15 17:38 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2023-02-15 17:20 UTC (permalink / raw) To: Drew Adams; +Cc: raman, emacs-devel > 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 17:20 ` Eli Zaretskii @ 2023-02-15 17:38 ` Drew Adams 2023-02-15 18:07 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2023-02-15 17:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: raman@google.com, emacs-devel@gnu.org > > > 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"? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 17:38 ` Drew Adams @ 2023-02-15 18:07 ` Eli Zaretskii 2023-02-15 20:00 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2023-02-15 18:07 UTC (permalink / raw) To: Drew Adams; +Cc: raman, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 18:07 ` Eli Zaretskii @ 2023-02-15 20:00 ` Drew Adams 2023-02-15 20:10 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2023-02-15 20:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: raman@google.com, emacs-devel@gnu.org > > > > `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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 20:00 ` Drew Adams @ 2023-02-15 20:10 ` Eli Zaretskii 2023-02-15 20:49 ` T.V Raman 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2023-02-15 20:10 UTC (permalink / raw) To: Drew Adams; +Cc: raman, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 20:10 ` Eli Zaretskii @ 2023-02-15 20:49 ` T.V Raman 2023-02-16 7:37 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: T.V Raman @ 2023-02-15 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Drew Adams, emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Pop-up-windows vs display-buffer-take-action 2023-02-15 20:49 ` T.V Raman @ 2023-02-16 7:37 ` Eli Zaretskii 0 siblings, 0 replies; 9+ messages in thread From: Eli Zaretskii @ 2023-02-16 7:37 UTC (permalink / raw) To: T.V Raman; +Cc: drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-02-16 7:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-02-15 15:26 Pop-up-windows vs display-buffer-take-action T.V Raman 2023-02-15 16:46 ` [External] : " Drew Adams 2023-02-15 17:20 ` Eli Zaretskii 2023-02-15 17:38 ` Drew Adams 2023-02-15 18:07 ` Eli Zaretskii 2023-02-15 20:00 ` Drew Adams 2023-02-15 20:10 ` Eli Zaretskii 2023-02-15 20:49 ` T.V Raman 2023-02-16 7:37 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).