From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: command mode-specificity [was: scratch/command 064f146 1/2: Change...] Date: Wed, 17 Feb 2021 18:36:20 +0100 Message-ID: <875z2qbnqj.fsf@telefonica.net> References: <87wnv7spji.fsf@gnus.org> <875z2rslqk.fsf@gnus.org> <87r1lfr647.fsf@gnus.org> <87pn0zfs4u.fsf@telefonica.net> <83mtw27l21.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34935"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:GCtpIuaoglw31bpOH1zgBwd7hUg= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 18:37:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lCQlM-0008tR-Fz for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 18:37:20 +0100 Original-Received: from localhost ([::1]:58790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCQlL-0001Ue-HJ for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 12:37:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCQkX-0000DW-Dn for emacs-devel@gnu.org; Wed, 17 Feb 2021 12:36:29 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:52130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCQkV-0001JV-O5 for emacs-devel@gnu.org; Wed, 17 Feb 2021 12:36:29 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lCQkT-0007dL-FX for emacs-devel@gnu.org; Wed, 17 Feb 2021 18:36:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265026 Archived-At: Eli Zaretskii writes: >> From: Óscar Fuentes >> 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.