unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 64656@debbugs.gnu.org
Subject: bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list
Date: Sun, 16 Jul 2023 08:24:56 +0300	[thread overview]
Message-ID: <83y1jga0nr.fsf@gnu.org> (raw)
In-Reply-To: <SJ0PR10MB54884D179AB7032967B9D4C8F335A@SJ0PR10MB5488.namprd10.prod.outlook.com> (message from Drew Adams on Sat, 15 Jul 2023 23:35:20 +0000)

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sat, 15 Jul 2023 23:35:20 +0000
> 
> It seems to me that the doc, including in the Elisp manual, doesn't make
> clear that, by default, `completing-read' automatically adds the list of
> all completions provided by the completion table to the list of
> defaults, just after the default value.  That is, by default, it calls
> `minibuffer-default-add-completions'.
> 
> This is not obvious from reading the docs.  For example, it's not
> obvious that if you use `C-h v' and then `M-p', repeating `M-p, you get
> the symbols that are variables, one by one, inserted into the
> minibuffer.
> 
> How so?  Because by default variable `minibuffer-default-add-function'
> is `minibuffer-default-add-completions'.  Again, none of this is
> obvious.  To find it out, a user needs to check what `M-p' is bound to,
> then check the source code for that function, and then the source code
> or the doc string of function `goto-history-element', which it calls.
> 
> In sum, important user-visible behavior isn't described in the manual or
> the "top-level", most-relevant doc strings (e.g. `completing-read').

You have described various aspects of the implementation, but no
"user-visible behavior" and no reason why it would be interesting, let
alone important, to have that in the manual.  Please consider changing
the POV of your description so that it will be clear what important
information is missing and why.  The main purpose of API descriptions
in the ELisp manual is to explain to Lisp programmers how to achieve
this or that behavior, and I cannot bridge the gap between that goal
and what you wrote.

For starters, this:

  It seems to me that the doc, including in the Elisp manual, doesn't make
  clear that, by default, `completing-read' automatically adds the list of
  all completions provided by the completion table to the list of
  defaults, just after the default value.  That is, by default, it calls
  `minibuffer-default-add-completions'.

is a huge turn-off, because it talks about what the code does.  After
reading this, I have no idea why I would need to know these details.
Why do I care that the list of all completions is added to the list of
defaults? why do I care that the code calls
minibuffer-default-add-completions?  Etc. etc.





  reply	other threads:[~2023-07-16  5:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 23:35 bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list Drew Adams
2023-07-16  5:24 ` Eli Zaretskii [this message]
2023-07-16 14:34   ` Drew Adams
2023-07-16 14:58     ` Eli Zaretskii
2023-07-18 20:27       ` Drew Adams
2023-07-19  6:35         ` Juri Linkov
2023-07-19 17:23           ` Drew Adams
2023-10-20  6:47             ` Juri Linkov
2023-10-20 16:48               ` Drew Adams
2023-10-29 18:29                 ` Juri Linkov
2023-10-29 22:15                   ` Drew Adams
2023-10-30  7:44                     ` Juri Linkov
2023-11-13 18:14                       ` Drew Adams
2023-11-14  5:57                         ` Thierry Volpiatto
2023-11-14  7:28                         ` Juri Linkov
2023-11-05 18:11               ` Juri Linkov
2023-11-06  7:28                 ` Juri Linkov
2023-11-09 16:34                   ` Juri Linkov
2023-11-09 16:48                     ` Eli Zaretskii
2023-11-09 17:03                       ` Juri Linkov
2023-11-09 19:31                         ` Eli Zaretskii
2023-11-10  7:45                           ` Juri Linkov
2023-11-10  8:15                             ` Eli Zaretskii
2023-11-12  8:13                               ` Juri Linkov
2023-11-13 17:17                                 ` Juri Linkov
2023-11-13 18:14                                   ` Drew Adams
2023-11-14  7:30                                     ` Juri Linkov
2023-11-15 17:52                                       ` Juri Linkov
2023-11-10 19:51                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-20  6:19         ` Eli Zaretskii
2023-07-20 16:45           ` Drew Adams
2023-07-22  8:07             ` Eli Zaretskii
2023-07-16 13:40 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y1jga0nr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=64656@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).