From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: emacs-30 73c1252bb6b: Fix link to major mode variable in docstring Date: Tue, 09 Jul 2024 01:26:03 +0200 Message-ID: <87cynnihys.fsf@web.de> References: <171956993509.30805.5525504753117432129@vcs2.savannah.gnu.org> <20240628101855.7E69DC2BC60@vcs2.savannah.gnu.org> <87bk37x4dg.fsf@posteo.net> Reply-To: Michael Heerdegen 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="16895"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Thierry Volpiatto To: emacs-devel@gnu.org Cancel-Lock: sha1:B9KQ2GfNSMip7pLj802DOuSPGYk= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 09 01:26:33 2024 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 1sQxkf-0004E1-TM for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Jul 2024 01:26:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQxjn-0005Dr-Pi; Mon, 08 Jul 2024 19:25:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQxjd-0005D7-7G for emacs-devel@gnu.org; Mon, 08 Jul 2024 19:25:32 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQxjX-0003oZ-NP for emacs-devel@gnu.org; Mon, 08 Jul 2024 19:25:28 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sQxjS-0002Ub-TI for emacs-devel@gnu.org; Tue, 09 Jul 2024 01:25:18 +0200 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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321550 Archived-At: Thierry Volpiatto writes: > Stefan Kangas writes: > > > Eshel Yaron writes: > > > >> I think it's not always correct to say "the variable" here, because that > >> "%s" may be replaced with a form that's not just a variable. E.g. now > >> C-h f global-auto-revert-mode RET says: > >> > >> To check whether the minor mode is enabled in the current buffer, > >> evaluate the variable ‘(default-value 'global-auto-revert-mode)’. > > > > Thanks, you're right. Now reverted. > > No, this is not right, reverting fix nothing, we are just back to previous > bug, this is unrelated, the bug is in `easy-mmode--mode-docstring` which > have a misleading arg called 'getter' and naturally `define-minor-mode` > pass 'getter' to it instead of passing 'mode'. No, this is what we want: in some cases what the user should eval to check whether a mode is enabled is _not_ the mode variable, but some other expression. This is why we have that sentence! To inform the user about what to eval exactly. The code receives that expression via the argument named GETTER. Also not that in your original recipe (I just tried it), you do _not_ just get to the very same page. Instead I get to a new help page listing _all_ things named `...-mode' - the mode variable has been added. And I think this is the best behavior our current heuristic can come up with, and in this case a minor issue. What we could do is maybe: generate different text in the two cases (expression is the mode variable vs. it is different), or even better, add the text only in the "special" case where the mode variable is not the thing to eval. Michael.