* Marking old window variables obsolete @ 2012-08-09 9:43 Chong Yidong 2012-08-09 14:12 ` Drew Adams 2012-08-09 14:53 ` Stefan Monnier 0 siblings, 2 replies; 13+ messages in thread From: Chong Yidong @ 2012-08-09 9:43 UTC (permalink / raw) To: emacs-devel The new display-buffer machinery still supports the following variables: special-display-buffer-names special-display-regexps special-display-frame-alist special-display-function same-window-buffer-names same-window-regexps display-buffer-reuse-frames I think we can mark these as obsolete for 24.2. Any objections? There's also pop-up-frames and pop-up-windows, but I think we can wait a few releases before marking those as obsolete. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Marking old window variables obsolete 2012-08-09 9:43 Marking old window variables obsolete Chong Yidong @ 2012-08-09 14:12 ` Drew Adams 2012-08-09 16:01 ` Eli Zaretskii 2012-08-09 14:53 ` Stefan Monnier 1 sibling, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-08-09 14:12 UTC (permalink / raw) To: 'Chong Yidong', emacs-devel > The new display-buffer machinery still supports the following > variables: > > special-display-buffer-names > special-display-regexps > special-display-frame-alist > special-display-function > same-window-buffer-names > same-window-regexps > display-buffer-reuse-frames > > I think we can mark these as obsolete for 24.2. Any objections? > > There's also pop-up-frames and pop-up-windows, but I think we > can wait a few releases before marking those as obsolete. FWIW and for the record, I disagree with _all_ of that proposal. Please do not do this. There should be _no_ hurry to do anything of the sort. Why can't you wait a few releases - or more - for all of the above? In fact, I would like to see these variables continued anyway, as (to me, at least), a much simpler, alternative way to customize buffer display. If the variables have fancy equivalents in the new machinery, fine. Let users choose: fancy or simple, super-general or (presumably) more limited. I do not claim _any_ expertise in this area - far from it. And that's one reason I ask that the simple approach be kept (as well as the more complex). You might be able to do more and better with the new system - or as you say "machinery" (usine a gaz?), but it does not seem (to me) to be so straightforward (simple) to use. It is still not clear to me how to - easily - replace the above user options, and I use them heavily. The doc regarding the new machinery, if not the machinery itself (can't speak to that), is impenetrable, for me. I'm sorry to say that, and I tried to raise the doc problem early, but I still do not see a clear explanation. Perhaps that is just a reflection of how complicated the machinery is - I can't judge, for lack of understanding. Just one, dumb user - who happens to actually _use_ the simple variables you are in a hurry to toss overboard. (Out of curiosity, I wonder how much those who came up with the new machinery ever actually used those variables. I don't argue that the machinery is bad or is implemented badly - on the contrary, I am convinced that Martin and others did a great job. But I wonder about its use value and ease of use, at least for some users.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 14:12 ` Drew Adams @ 2012-08-09 16:01 ` Eli Zaretskii 2012-08-09 16:10 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-08-09 16:01 UTC (permalink / raw) To: Drew Adams; +Cc: cyd, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Thu, 9 Aug 2012 07:12:57 -0700 > > > The new display-buffer machinery still supports the following > > variables: > > > > special-display-buffer-names > > special-display-regexps > > special-display-frame-alist > > special-display-function > > same-window-buffer-names > > same-window-regexps > > display-buffer-reuse-frames > > > > I think we can mark these as obsolete for 24.2. Any objections? > > > > There's also pop-up-frames and pop-up-windows, but I think we > > can wait a few releases before marking those as obsolete. > > FWIW and for the record, I disagree with _all_ of that proposal. Please do not > do this. There should be _no_ hurry to do anything of the sort. Why can't you > wait a few releases - or more - for all of the above? Deprecation does not mean removal. I'm sure you know that. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Marking old window variables obsolete 2012-08-09 16:01 ` Eli Zaretskii @ 2012-08-09 16:10 ` Drew Adams 2012-08-09 16:53 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-08-09 16:10 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: cyd, emacs-devel > > FWIW and for the record, I disagree with _all_ of that proposal. > > Please do not do this. There should be _no_ hurry to do anything > > of the sort. Why can't you wait a few releases - or more - for > > all of the above? > > Deprecation does not mean removal. I'm sure you know that. Of course. No one suggested otherwise. My request is first that we do not deprecate these user options _now_. And second, preferably, that we do not deprecate them at all (i.e., even later), but we instead keep them as an alternative, simpler way to do some (most?) of what the new "machinery" does in a less user-friendly way (in my relatively uninformed opinion). And I also encourage better documenting the new machinery itself. And especially describing, for each such longstanding and useful user option, how to get the same effect with the new, alternative machinery. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 16:10 ` Drew Adams @ 2012-08-09 16:53 ` Eli Zaretskii 2012-08-09 18:16 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-08-09 16:53 UTC (permalink / raw) To: Drew Adams; +Cc: cyd, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Thu, 9 Aug 2012 09:10:47 -0700 > Cc: cyd@gnu.org, emacs-devel@gnu.org > > > > FWIW and for the record, I disagree with _all_ of that proposal. > > > Please do not do this. There should be _no_ hurry to do anything > > > of the sort. Why can't you wait a few releases - or more - for > > > all of the above? > > > > Deprecation does not mean removal. I'm sure you know that. > > Of course. No one suggested otherwise. > > My request is first that we do not deprecate these user options _now_. How else can we encourage users to migrate to the new machinery? ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Marking old window variables obsolete 2012-08-09 16:53 ` Eli Zaretskii @ 2012-08-09 18:16 ` Drew Adams 2012-08-09 18:37 ` Óscar Fuentes 2012-08-09 19:28 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Drew Adams @ 2012-08-09 18:16 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: cyd, emacs-devel > > My request is first that we do not deprecate these user > > options _now_. > > How else can we encourage users to migrate to the new machinery? Sheesh. If that's the only way users can be encouraged to adopt the new machinery, that doesn't say much about how appealing it is, does it? Users generally have little problem adopting new features that they find (or even suspect might be) useful. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 18:16 ` Drew Adams @ 2012-08-09 18:37 ` Óscar Fuentes 2012-08-09 21:51 ` Drew Adams 2012-08-09 19:28 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Óscar Fuentes @ 2012-08-09 18:37 UTC (permalink / raw) To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > Sheesh. If that's the only way users can be encouraged to adopt the new > machinery, that doesn't say much about how appealing it is, does it? > > Users generally have little problem adopting new features that they find (or > even suspect might be) useful. Really? Even if we supposse that everybody reads the NEWS file and are willing to adapt their perfectly working configuration on accordance, your approach would limit the set of acceptable new features to those which are indisputably more useful than the functionality they replace/modify for the taste of (almost?) all the Emacs user population. What's reasonable, IMHO, is to add clear instructions to the docstrings of those variables and functions explaining how to migrate to the new machinery. If those instructions turn to be too complex, it is an indication that the new system is not so good. A good practice is to do those kind of documentation tasks at the design phase of the new machinary as a preemptive usability check. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Marking old window variables obsolete 2012-08-09 18:37 ` Óscar Fuentes @ 2012-08-09 21:51 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2012-08-09 21:51 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > Even if we supposse that everybody reads the NEWS file and are > willing to adapt their perfectly working configuration on accordance, > your approach would limit the set of acceptable new features to those > which are indisputably more useful than the functionality they > replace/modify for the taste of (almost?) all the Emacs user > population. Sorry, but that simply does not follow, at all. None of it. I am _not_ proposing _any_ limitation on what new features are acceptable. And in particular I have not objected to the "new machinery" for controlling buffer display, and I have even said explicitly that I am _glad_ for it to exist. I simply object to deprecating those longstanding user options now. And I prefer that we in fact keep them as a simple, alternative way to customize the behavior. > What's reasonable, IMHO, is to add clear instructions to the > docstrings of those variables and functions explaining how to > migrate to the new machinery. That is also something that I (and Eli also) proposed. You and I are in the same choir on that. Such doc certainly should be part of any future deprecation, if ever that should occur. And it would be helpful even if we do not deprecate the options. The correspondence between the different ways of doing things is something that is good to know, in any case. > If those instructions turn to be too complex, it is an > indication that the new system is not so good. That's also something I suggested. If we cannot even explain that correspondence in simple terms, it's hard to imagine that we would be convinced that the variables should be deprecated, especially so soon. > A good practice is to do those kind of documentation tasks at the > design phase of the new machinary as a preemptive usability check. Again, we are in agreement. And that is why I brought it up back then. http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg00677.html http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00048.html http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg00834.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 18:16 ` Drew Adams 2012-08-09 18:37 ` Óscar Fuentes @ 2012-08-09 19:28 ` Eli Zaretskii 2012-08-09 21:53 ` Drew Adams 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2012-08-09 19:28 UTC (permalink / raw) To: Drew Adams; +Cc: cyd, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <cyd@gnu.org>, <emacs-devel@gnu.org> > Date: Thu, 9 Aug 2012 11:16:12 -0700 > > > > My request is first that we do not deprecate these user > > > options _now_. > > > > How else can we encourage users to migrate to the new machinery? > > Sheesh. If that's the only way users can be encouraged to adopt the new > machinery, that doesn't say much about how appealing it is, does it? > > Users generally have little problem adopting new features that they find (or > even suspect might be) useful. You must be kidding, if you rely in people discovering every new feature among hundreds, let alone study each one of them. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Marking old window variables obsolete 2012-08-09 19:28 ` Eli Zaretskii @ 2012-08-09 21:53 ` Drew Adams 2012-08-10 6:18 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2012-08-09 21:53 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: cyd, emacs-devel > > > > My request is first that we do not deprecate these user > > > > options _now_. > > > > > > How else can we encourage users to migrate to the new machinery? > > > > Sheesh. If that's the only way users can be encouraged to > > adopt the new machinery, that doesn't say much about how appealing > > it is, does it? > > > > Users generally have little problem adopting new features > > that they find (or even suspect might be) useful. > > You must be kidding, if you rely in people discovering every new > feature among hundreds, let alone study each one of them. No, I am not kidding. And you are jumping all over the map. So now it's about users _discovering_ new features? No. With that logic, we should deprecate all over the place, just to make sure users discover new features. "You must be kidding." ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 21:53 ` Drew Adams @ 2012-08-10 6:18 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2012-08-10 6:18 UTC (permalink / raw) To: Drew Adams; +Cc: cyd, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <cyd@gnu.org>, <emacs-devel@gnu.org> > Date: Thu, 9 Aug 2012 14:53:06 -0700 > > > > > > My request is first that we do not deprecate these user > > > > > options _now_. > > > > > > > > How else can we encourage users to migrate to the new machinery? > > > > > > Sheesh. If that's the only way users can be encouraged to > > > adopt the new machinery, that doesn't say much about how appealing > > > it is, does it? > > > > > > Users generally have little problem adopting new features > > > that they find (or even suspect might be) useful. > > > > You must be kidding, if you rely in people discovering every new > > feature among hundreds, let alone study each one of them. > > No, I am not kidding. > > And you are jumping all over the map. So now it's about users _discovering_ new > features? No. Indeed, no. It's about encouraging them to switch. And since we cannot rely on them discovering these features on their own, we do it through deprecation. Deprecation doesn't mean removal. I suggest to save your energy for when the removal is discussed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 9:43 Marking old window variables obsolete Chong Yidong 2012-08-09 14:12 ` Drew Adams @ 2012-08-09 14:53 ` Stefan Monnier 2012-08-09 15:57 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2012-08-09 14:53 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > The new display-buffer machinery still supports the following variables: > special-display-buffer-names > special-display-regexps > special-display-frame-alist > special-display-function > same-window-buffer-names > same-window-regexps > display-buffer-reuse-frames > I think we can mark these as obsolete for 24.2. Any objections? I think I agree, tho I'm not completely sure what are the replacement features for each one of them. Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Marking old window variables obsolete 2012-08-09 14:53 ` Stefan Monnier @ 2012-08-09 15:57 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2012-08-09 15:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Thu, 09 Aug 2012 10:53:07 -0400 > Cc: emacs-devel@gnu.org > > > The new display-buffer machinery still supports the following variables: > > special-display-buffer-names > > special-display-regexps > > special-display-frame-alist > > special-display-function > > same-window-buffer-names > > same-window-regexps > > display-buffer-reuse-frames > > > I think we can mark these as obsolete for 24.2. Any objections? > > I think I agree, tho I'm not completely sure what are the replacement > features for each one of them. Which is why we need to clearly explain with what to replace each one that we deprecate, I think. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-08-10 6:18 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-09 9:43 Marking old window variables obsolete Chong Yidong 2012-08-09 14:12 ` Drew Adams 2012-08-09 16:01 ` Eli Zaretskii 2012-08-09 16:10 ` Drew Adams 2012-08-09 16:53 ` Eli Zaretskii 2012-08-09 18:16 ` Drew Adams 2012-08-09 18:37 ` Óscar Fuentes 2012-08-09 21:51 ` Drew Adams 2012-08-09 19:28 ` Eli Zaretskii 2012-08-09 21:53 ` Drew Adams 2012-08-10 6:18 ` Eli Zaretskii 2012-08-09 14:53 ` Stefan Monnier 2012-08-09 15:57 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.