Marking old window variables obsolete

Marking old window variables obsolete

[Chong Yidong]

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.

RE: Marking old window variables obsolete

[Drew Adams]

> 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.)

Re: Marking old window variables obsolete

[Stefan Monnier]

> 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

Re: Marking old window variables obsolete

[Eli Zaretskii]

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

Re: Marking old window variables obsolete

[Eli Zaretskii]

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

RE: Marking old window variables obsolete

[Drew Adams]

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

Re: Marking old window variables obsolete

[Eli Zaretskii]

> 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?

RE: Marking old window variables obsolete

[Drew Adams]

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

Re: Marking old window variables obsolete

[Óscar Fuentes]

"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.

Re: Marking old window variables obsolete

[Eli Zaretskii]

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

RE: Marking old window variables obsolete

[Drew Adams]

> 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

RE: Marking old window variables obsolete

[Drew Adams]

> > > > 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."

Re: Marking old window variables obsolete

[Eli Zaretskii]

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