RE: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]

[Drew Adams]

> > I'm not the one claiming that this new (proposed?
> > already added?) feature is needed, and that most
> > commands are mode-specific.  My guess is that it's
> > not needed and most commands are not mode-specific.
> >
> > You're the one proposing a change.  What's the
> > evidence for the need for it?
> 
> How do you expect to *prove* to you that I will
> benefit from the change?

How does one usually convince Emacs Dev to make
some change?  Reasoned argument, examples, use
cases...?  In the case of a claim that most
commands are mode-specific, maybe actually show
that somehow?

It's standard Emacs Dev practice, I believe, for
those proposing a change give supporting reasons.
Change requires more support than status quo.

That's my impression, at least.  It's also my
preference.

If changes were typically made willy nilly, with
no discussion or reasons presented, and if the
burden of convincing were on those NOT promoting
some change, we'd have more churn and more
dissatisfaction all 'round.  Don't you agree?

> Is there some sort of accepted dialectics for that purpose?

Respectful discourse?

> I explained many times, now and on the previous
> discussion about this feature long time ago, why
> it would be so helpful to me that I will be
> happy to devote many hours to tag as many
> commands as possible.

I don't have any problem with the _possibility_
for someone to tag something any way they want,
or with someone providing some code that _lets_
users take advantage of such tags.

The problem isn't with providing new possibilities
for users.  The problem is with changing what
already exists - the default behavior.

I've argued in _favor_ of users being able to
more easily filter completion candidates.
That's not a problem.

Add something to Emacs as an option, then wait
and see how much it's taken up by users.  If
it turns out that zillions think it should take
more prominence, or even become new default
behavior, then that'll get done.  That's not
the same as just flipping default behavior for
one's favorite shiny new thing.

One good way such new-feature change can take
place is for someone to code it up in a
3rd-party library, and for users in the wider
world to start using it.  Later, after we've
seen what that experiment's given, think about
maybe doing the same or something similar in
vanilla Emacs.

> Then you handwave away common-sense arguments
> as irrelevant or conflicting with some sort
> of imagined scenario,

I have no idea what you're talking about there.
Specifics, please.

> or because it goes against some personal habits
> of abusing a feature

One person's "abuse" of some existing Emacs
behavior/feature is another person's handy use
case.

To be quite clear, I doubt that any of what's
being discussed about this new behavior will
affect me much, personally.  For example, I use
Icicles, which has its own replacement for `M-x'.

(Of course, if code changes are incompatible
then I will perhaps have to modify some of my
code accordingly.  But as a _user_ my guess is
that I won't be affected much, if at all.)

My concern is for Emacs, not just for my own
use of it.

The burden of convincing is on those who intend
to _change_ the existing behavior.  This is
normal.

Someone might think their change is wonderful,
but it might remove or negatively impact Emacs
uses by others.  Is that not something to take
into consideration?

> (M-x for remembering commands instead of C-h a?

I, for one, said nothing about M-x for
remembering commands.  I have no idea what
you're on about, here.

> Seriously? And why that is an impediment for
> improving M-x to better function for its stated
> purpose?)

Again, no idea what you're taking about.  The
burden of convincing to make some change (e.g.
to "improve M-x to better function" is on the
promoter of the change.  That general rule has
nothing to do with me.

> You don't see a benefit on this feature *for you*.
> Fair enough. You are uneasy with the changes on
> `interactive'.

Again, what I've written about this reflects
what I think (so far) _for Emacs_.  It's not
really about my personal use of Emacs.  I live
in my own little Icicles world, somewhat
insulated from your `M-x' etc.  But I care about
Emacs - beyond my own habits and use of it.

Pretty much everything has benefits and
drawbacks. See above.  Propose something that's
optional and opt-in, and I expect there will be
little contest.

> I wholeheartedly sympathize with you here, for
> the reasons you expressed and some more. But
> please don't come with "what's the evidence for
> the need of it?", 

Why?  That's standard procedure, no?  Propose a
change and convince people that it would be a
good thing - better done than not done.

> because you are sending a clear signal about
> being utterly uninterested on other's opinions.

No, I don't think I am.

But I do think that an attitude of not needing
to give reasons in favor of some desired change,
in particular an incompatible or default change,
kinda qualifies as showing disinterest and
disrespect for longstanding Emacs behavior, and
thus for its users.

I don't even need to express my opinion about
a proposed change.  It's up to those promoting
it to convince others that the change is needed
or a great idea.  I'm not convinced, in this
case, but I don't decide anything here.

It's not me you need to convince.  That said,
I will say that I - for one - am not convinced.