bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively

[Drew Adams]

> 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.
___