From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Heime <heimeborgia@protonmail.com>
Cc: "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
Date: Sat, 19 Aug 2023 16:20:07 +0000 [thread overview]
Message-ID: <SJ0PR10MB54888895C68C14E6201481C4F318A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83a5un35h6.fsf@gnu.org>
> You can try starting a discussion on emacs-devel if you want. But the
> above-mentioned change was not done arbitrarily, and does have its
> merit in many situations,
I don't see that it has merit in any situation.
I haven't seen a single example cited where it
has merit. Can you point to one? I really
don't see any value in this behavior.
And I think you agreed that it's obvious that in
some cases (such as the `C-h v' example cited in
bug #64656) it's _clearly_ not helpful but harmful.
> so be prepared for hearing people who think
> they like the current situation and object to changing it. Drew's
> opinion on this are not new, and have been heard (and rejected)
> before.
I searched but didn't see anywhere where my opinion
on this was rejected. I think the relevant thread
is that of bug #64656, which you intentionally kept
open for this very question: whether COLLECTION
should be automatically added to "future history".
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64656
Below are some relevant extracts from what I wrote
there. The question I posed of what value this
"feature" has was never answered. I'd like to hear
about "its merit in many situations". You didn't
point to any situations in that bug thread. Do you
have any (let only "many") in mind?
It's an honest question. I don't get the point of
this feature. What am I missing?
From bug #64656:
___
But I'm asking about the general idea behind
this default behavior: What use case(s) does
it really help with? Even with a small list
of (empty-input) completions, and even when
those are in some meaningful/useful order,
what's the use case for adding them to `M-n',
which is a carefully designed default or list
of defaults? Why use the completion domain
as a set of defaults - at all?
___
1. I'm asking whether this feature (addition
of completion domain automatically)
shouldn't be revisited, maybe even removed,
and at least default to OFF.
2. If that revisit is NOT to be, then I'm
asking that the doc at least (a) point out
that this automatic behavior can be
problematic, and (b) tell users how to
(i) turn it off and (ii) control it a bit
if not turned off. That control can include
limiting the size and sorting the elements
to be added.
___
ELI> If we think that future history in some case
ELI> is useless, TRT is to change the code so
ELI> that it ceases to be useless,
100% agreement. That's why that was my first
priority request. Fix this and there likely
will be no, or little, need to change the doc.
I didn't assume that others would agree that
the behavior is harmful.
I thought too that I might just be missing
something. The behavior seems so bizarre to
me that I don't understand why it would have
been adopted. Benefit of the doubt made me
guess I'm maybe just misunderstanding.
___
next prev parent reply other threads:[~2023-08-19 16:20 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 0:47 bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 5:49 ` Eli Zaretskii
2023-08-17 6:05 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 7:20 ` Eli Zaretskii
2023-08-17 10:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 10:45 ` Eli Zaretskii
2023-08-18 0:35 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 1:47 ` Drew Adams
2023-08-18 3:49 ` Eli Zaretskii
2023-08-18 5:13 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 5:36 ` Eli Zaretskii
2023-08-18 5:56 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 6:32 ` Eli Zaretskii
2023-08-18 8:40 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:14 ` Eli Zaretskii
2023-08-18 12:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:30 ` Eli Zaretskii
2023-08-18 12:55 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 13:27 ` Eli Zaretskii
2023-08-18 13:36 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 15:23 ` Drew Adams
2023-08-18 15:16 ` Drew Adams
2023-08-18 15:43 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 17:33 ` Drew Adams
2023-08-18 19:12 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:03 ` Drew Adams
2023-08-19 1:55 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 2:34 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 4:14 ` Drew Adams
2023-08-19 4:22 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 4:46 ` Drew Adams
2023-08-19 5:05 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19 6:34 ` Eli Zaretskii
2023-08-19 16:20 ` Drew Adams [this message]
2023-08-19 19:19 ` Eli Zaretskii
2023-08-19 20:56 ` Drew Adams
2023-08-20 16:39 ` Juri Linkov
2023-08-21 0:23 ` Drew Adams
2023-08-21 4:34 ` Christopher Dimech
2023-08-20 5:42 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20 6:12 ` Michael Heerdegen
2023-08-20 6:23 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20 6:34 ` Christopher Dimech
2023-08-21 0:25 ` Drew Adams
2023-08-21 4:26 ` bug#65348: RE: [External] : " Christopher Dimech
2023-08-21 5:23 ` Drew Adams
2023-08-21 6:29 ` Christopher Dimech
2023-08-21 7:21 ` bug#65348: " Christopher Dimech
2023-08-21 11:40 ` Eli Zaretskii
2023-08-21 12:07 ` Christopher Dimech
2023-08-21 12:25 ` Eli Zaretskii
2023-08-21 13:27 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-21 16:08 ` Drew Adams
2023-08-18 19:45 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:07 ` 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=SJ0PR10MB54888895C68C14E6201481C4F318A@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=65348@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=heimeborgia@protonmail.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).