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.
next prev parent 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).