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: Sun, 29 Oct 2023 22:15:10 +0000	[thread overview]
Message-ID: <SJ0PR10MB548812D0E66D035323490954F3A2A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <86h6m9v1sx.fsf@mail.linkov.net>

> > Pull this misfeature out of Emacs; it
> > never should have been added (and IIRC
> > that was done without any discussion?).
> 
> This feature was removed by bug#5214 and bug#5364,
> then later added back by the request in bug#12490
> where you participated and raised no objections.

Seriously?

The only "participation" I had in bug #12490
was to say that "We should never bind `C-s'
in the minibuffer to anything.  We shouldn't
remove the ability to use Isearch there (using
the global `C-s' binding)."

I said nothing there about any question of
jamming the completion domain (initial
candidates) into the `M-n' queue.  I had no idea
that was going on.

That wasn't the subject of bug #12490, at all!

And looking now, I really don't see that it has
anything to do with that thread - or with bugs
#5214 and #5364.  So I don't see what you're on
about, here.

That someone might have abused bug report #12490
to do what you say is news to me (and it's not
kosher IMO).  I no doubt did not follow that
particular bug thread with a fine-tooth comb.
If that was done then it snuck by me, I guess.

But I certainly have voiced my opposition to
stuffing the `M-n' queue with the completion
domain.  Multiple times, and likely in multiple
threads.

I wasn't aware that this purposeful regression
was reverted in bug threads #5214 and #5364.
I didn't participate in either of those threads,
and was no doubt unaware that they had anything
to do with this problem.

And I don't even see that what you say happened.

In bug #12490 I see you say this, at the outset,
in reply to OP's complaint that he could no
longer _search in the minibuffer_:

 > I want to report, that most used function stop working in Emacs 24
 > (tested 2 versions 24.1.1 and latest 24.2.1). I use Search in
 > Mini buffer a lot (don't know if people use it or not). If you call
 > search C-s when inside minibuffer like C-h f C-s you can search the
 > content of Minibuffer like search for functions or for buffer name to
 > switch like C-x b C-s (better then ido mode). And in Emacs 24 M-x C-s
 > stop working so I you can't search for interactive function to execute
 > anymore. It was working in 23.3 provided by Ubuntu (package
 > 23.3+1-1ubuntu4).

 Sorry, this feature has been removed by http://debbugs.gnu.org/5214
 and http://debbugs.gnu.org/5364

 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.

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.

Don't remove programmer (and user) control by
smothering `M-n' with the completion candidates.
Please pull this misfeature out.






  reply	other threads:[~2023-10-29 22:15 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 [this message]
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=SJ0PR10MB548812D0E66D035323490954F3A2A@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).