unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"64656@debbugs.gnu.org" <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: Mon, 13 Nov 2023 18:14:15 +0000	[thread overview]
Message-ID: <SJ0PR10MB548850C979AE1F20F642092FF3B3A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <861qdc1s3s.fsf@mail.linkov.net>

> >  But it's easy to restore it with a simple patch that prepends the
> >  current default value (a command at point) to the sorted list of
> >  all available command names:
> >
> > And even that doesn't seem to have much, if
> > anything, to do with adding all of the initial
> > completions to the `M-n' queue.
> > So I really don't follow you, here.
> 
> All available command names mentioned above
> are extracted from initial completions.

And?  That's the problem.  The completion domain
("initial completions") shouldn't be added to
the `M-n' queue.  At least not by default, and
IMHO, never automatically.  Any programmer is
free to add anything at all to the `M-n' queue,
including all of the initial completions, simply
by adding it to DEFAULTS.  That's what DEFAULTS
is for: to add to the `M-n' queue.

> > To be very clear, I'm opposed to the misfeature
> > of automatically jamming the initial completions
> > onto the `M-n' queue.  We have arg DEFAULTS for
> > that.  Callers of `completing-read' etc. can
> > provide exactly the list of DEFAULTS they want
> > to prepend to the `M-n' queue.
> 
> Indeed, ideally callers of `completing-read' should
> provide the exact list of defaults.

Why only "ideally"?  Anyone is always free to
add whatever they want `M-n' using DEFAULTS in
their call to `completing-read'.

> The problem
> is that it's too late to identify the existing callers
> and to add an explicit list of defaults to them.

_Programmers_ can define DEFAULTS as they like.
No one needs to, or should, try to add anything
automatically to the `M-n' queue, overriding
what a programmer has explicitly decided should
be there using DEFAULTS.

Or perhaps you mean existing `completing-read'
calls in the vanilla Emacs code, not user code?

If so, I'd say don't worry about it.  Don't
second-guess what the `M-n' queue should be for
existing `completing-read' calls.  Or if you
really want to, go ahead, investigate them one
by one.

Each call to `completing-read' deserves its own 
consideration wrt DEFAULTS (the `M-n' queue).
Nothing should ever automatically trounce what
a programmer has explicitly decided should be
in the `M-n' queue (with DEFAULTS).

> > Don't remove programmer (and user) control by
> > smothering `M-n' with the completion candidates.
> 
> This doesn't remove programmer (and user) control
> because it's still easy to add own default values
> to `M-n' and to remove initial completions from `M-n'.

It's not so easy to remove initial completions.
At a minimum, how to do that needs to be added
to the doc (this bug report).  But as Eli said,
it's more important to fix the bug of their
automatic addition than to document a workaround.





  reply	other threads:[~2023-11-13 18:14 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
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 [this message]
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=SJ0PR10MB548850C979AE1F20F642092FF3B3A@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=64656@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    /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).