emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : Re: command mode-specificity [was: scratch/command 064f


From: Óscar Fuentes
Subject: Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...]
Date: Wed, 17 Feb 2021 18:36:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 17 Feb 2021 01:35:29 +0100
>> 
>> 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.
>
> No one is arguing that having this filtering as an optional behavior
> can be useful.  The argument, at least from my side, was that I don't
> think it can, in its current too radical shape, be the default,
> because it is both backward-incompatible and provides no "fire
> escape".
>
> If the implementation were to change, such that it didn't actually
> remove commands from the list of completion candidate, then perhaps we
> could make this the default (but even then I'm not sure).

As I said several times, that would nullify the feature to a great
extent. The user would still see a long-ish list of candidates, and then
have to notice where the "applicable" commands end and the rest begin,
hence some type of cue would be needed, and then each completion
framework would need to implement the cue.

>> Then you handwave away common-sense arguments as irrelevant or
>> conflicting with some sort of imagined scenario, or because it goes
>> against some personal habits of abusing a feature (M-x for remembering
>> commands instead of C-h a? Seriously?
>
> Please cool down.  One person's must-have feature is another person's
> "imagined scenario" or "personal habits of abusing".  User options
> exist in Emacs because we try not to be too judgmental, and let each
> one have their preferences.

My message came across as somewhat harsher than intended, but please
realize that when one gives detailed explanations about something, again
and again, and is sistematically confronted with responses such as "you
need to demonstrate (an unspecified goal based on some vague criteria)",
"I use M-x for something else and wont adapt my workflow", "this is
madness", etc, it is quite frustrating. And then when you try to
understand the details of the opposition, the best answer you can get is
something akin to "because reasons."

For all I care, the feature can be released as disabled by default, as I
don't want to impose nothing on anybody.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]