bug#46627: [External] : bug#46627: [PATCH] Add new help command 'describe-command'

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The way I suggest handling these is to put them in the release, then
  > > tell people a command to run to try them.  That makes it easy
  > > to try them out.

  > That is only a viable option if the new feature is opt-in and doesn't
  > change the default behavior in any way, shape or form.

We can make it work for any change.  We just need to define a command
to install the change.  That command would set up key bindings, set variables,
even redefine functions so as to enable the proposed new behavior.

It would be nice to have a command to remove the change, but that is
not essential -- killing that Emacs and starting another would do the
job.

  >   And having the new
  > feature on a branch first does not in any way contradict the trial by
  > a larger audience later, when the feature is released.

Indeed, we can.  I was responding to the point that trialing a feature
on a branch will get responses only from a limited set of people.

Drew wrote:

  > Yes, but that has another downside: what's in a release tends to
  > stick, for various reasons, including user take-up and developer
  > acceptance.

I think that is a miscommunication.  With the scheme I propose, the
code to implement some new behavior is included in a release, but the
default behavior has not been changed, and we have made no commitment
to change it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)