From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list Date: Thu, 20 Jul 2023 09:19:12 +0300 Message-ID: <834jlz3y1r.fsf@gnu.org> References: <83y1jga0nr.fsf@gnu.org> <83o7kb9a40.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="24680"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64656@debbugs.gnu.org To: Drew Adams , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 20 08:19:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qMN0X-00067z-4o for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Jul 2023 08:19:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qMN0J-0007XX-Mb; Thu, 20 Jul 2023 02:19:11 -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 1qMN0B-0007Rj-R9 for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2023 02:19:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qMN0A-0006xY-F1 for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2023 02:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qMN0A-0002r2-A6 for bug-gnu-emacs@gnu.org; Thu, 20 Jul 2023 02:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jul 2023 06:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64656 X-GNU-PR-Package: emacs Original-Received: via spool by 64656-submit@debbugs.gnu.org id=B64656.168983393910962 (code B ref 64656); Thu, 20 Jul 2023 06:19:02 +0000 Original-Received: (at 64656) by debbugs.gnu.org; 20 Jul 2023 06:18:59 +0000 Original-Received: from localhost ([127.0.0.1]:57543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMN07-0002qj-9g for submit@debbugs.gnu.org; Thu, 20 Jul 2023 02:18:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMN04-0002qV-Hl for 64656@debbugs.gnu.org; Thu, 20 Jul 2023 02:18:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMMzy-0006vJ-Ep; Thu, 20 Jul 2023 02:18:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=u+9FoNYkekxZQdmyiljL0sx6HCpZTH/Dv7CX2RGyzB0=; b=KYej4bZgcNAngA8l0U5v sEofd8B9vLtZDDbgpjB6LLXtQDbLGwHT5Zz8kJvwZ0sL27b4HPUBDzdW+x0U9Aa8i8E11bfjS4tzH ZbSGUyxOx1cJJWpWoss9+CyBvRomu7WueCx9nYRScZRsInBwuqeGvOHSrOyQLBojyWNlgJXj3uTn7 Z+rAbgRsmobnl3x08sSfYLECx4GZGe4R+TzL/NSVx8TSOAJnbNt/wrP9yy50rYr6UgjGEW+BCwBh4 YArUvCd5Ng2L6AOJ/Qh4jWt0T/4XlIK+2I8bkRWBLffKBKsprBjWEdfue4Bl/1YVMZ6M3+QPjiQ4y vIDSiGOAkeRNqA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMMzn-0007jL-Bh; Thu, 20 Jul 2023 02:18:50 -0400 In-Reply-To: (message from Drew Adams on Tue, 18 Jul 2023 20:27:32 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265569 Archived-At: > From: Drew Adams > CC: "64656@debbugs.gnu.org" <64656@debbugs.gnu.org> > Date: Tue, 18 Jul 2023 20:27:32 +0000 > > > > Hope this clarifies the request/bug report. > > > > It doesn't. Sorry, I guess I'm too stupid > > to understand what you are asking. > > Don't be silly or sarcastic, please. This isn't sarcasm, this is frustration. And please avoid ad-hominem if you can, especially when you yourself use language that can easily be interpreted as sarcasm: > A user cares what's available from `M-n'. > (I don't expect another "Why?" for that, > but it comes, I'll try to answer that too.) Isn't that sarcasm? So let's try to drop the attitude and discuss the real problems, okay? (Adding Stefan, because I think he could have insights in this area that is nowadays complicated enough to blow my mind.) > Why does it matter that all initial (i.e., > prior to any user input in the minibuffer) > completions are put into the `M-n' queue? > > Because that set of candidates is often > huge. And because its order isn't designed > for `M-n' or (especially) for the particular > act of input reading. Often its order has > no special reason. > > And the case given as an example, `C-h v', > illustrates that well: (1) zillions of vars, > (2) in no user-expectable/understandable/ > useful order - the order of obarray! This part of your report seems to be a separate issue -- you seem to be saying that "C-h v" and similar commands should not add all the variables to the "future history". It's possible that you are right, although it could be useful if M-s and M-r in the minibuffer would actually search that list -- which they don't currently, due to how this "add to future history" feature is implemented to add elements lazily (see goto-history-element). But that is a separate issue, almost unrelated to the Subject of your report, which is about documentation. Whatever problems we have in this area with "C-h v", they cannot be solved by documentation in the ELisp manual. So what is the documentation issue? You say: > What an Elisp user (not an end user of a > command) really needs to care about is var > `minibuffer-default-add-function', not the > particular function that's its default value. > > Forget for a moment about what various > function values for that variable might do. > The most important thing about that var is > that if nil then the domain of completions > isn't added to the `M-n' queue at all. IOW, > that _turns off_ the automatic filling of > the `M-n' queue. > > An Elisp user needs to know that fact, if > s?he uses `completing-read' and s?he wants > to prevent the kind of confusing overkill > exhibited by `C-h v'. (She then needs to > bind the var to nil around the call to > `completing-read'). > [...] > Elisp users thus need to know that to define > the subset and its order for `M-n' they can > bind var `minibuffer-default-add-function' > to a function that returns such a list. > This isn't obvious. You won't find it by > reading the `completing-read' doc, at least, > though it's just as important to controlling > the behavior as the args to that function. First, M-n is not about completion, it is about minibuffer history. Completion functions use the minibuffer, so the minibuffer history affects them, but they are not the only ones affected. The documentation of completing-read and of read-from-minibuffer already state that DEFAULT is added to the "future history": The argument DEFAULT specifies default values to make available through the history commands. It should be a string, a list of strings, or ‘nil’. The string or strings become the minibuffer’s “future history”, available to the user with ‘M-n’. What is missing here, it seems, is the hint that this addition can be controlled, among other measures, via minibuffer-default-add-function, and the documentation of that variable where the minibuffer history is documented. Is that what you are asking for, or is there anything else? > I mentioned that I think it would help to > make some changes to both the Elisp doc and > the user doc. Why would Emacs users need to know about this? The mechanism to control what and how is added to minibuffer history is not user-level information; users cannot use it to their benefit. > In effect, the heads-up tells a user that > when prompted for input with completion, > in some cases the "future history" of > defaults is effectively useless. And it > doesn't hurt to tell users why: _all_ > possible domain completions are included, > possibly in a meaningless order. If we think that future history in some case is useless, TRT is to change the code so that it ceases to be useless, not to document that it is useless. IOW, we don't document our own bugs, we prefer to fix them. So no, we won't be telling this in user documentation. If we decide that this behavior of "C-h v" and similar commands is not useful, we should change it to be more useful.