bug#43218: EWW handles default answer incorrectly when changing a select

[Drew Adams]

> > Not sure how the prompting gets involved in this problem: if you decide
> > to let the user choose only based on the text (i.e. "one" vs "one"),
> > then there's not much the prompting can do to help: the minibuffer lets
> > the users enter a string and that's that.
> > If they type "one" which one of the two should you pick?
> 
> Yeah, that makes no sense.  I was kinda sorta thinking about how ido
> presents choices, but that's pretty much irrelevant in this case.

No, it does make sense.  Or rather, it can make sense.

Obviously, if all a user has to go on is the display
name of candidates, then she can't tell one from the
other.

But if other information, in addition to the display
name, is communicated in some way, either by default
or on demand, then it can make perfect sense.

The point is that the `completing-read' behavior,
which shows only the car of an alist entry (plus
possibly an annotation), is quite limited.

Examples of showing additional info:

* In Icicles search, there may be multiple search
  hits with the same text, at different locations.
  (1) The order in *Completions* can tell you where
  they are, relatively.  (2) You can hit a key to
  go to any search hit, to see exactly where it is,
  without that location being your final destination
  choice.

* In Bookmark+, you can have "autofile" bookmarks,
  whose names are the nondir destination file names.
  That's convenient.  But in the bookmark display
  list, or when jumping to a bookmark (completion)
  you can see what the destination file is.

There are other examples, with different behaviors
and use cases.

The point is that the car of an alist entry (which
is a string) does not, in general, carry all of the
information about the alist entry.  And that string
is all that `completing-read' shows (plus possibly
an annotation), and it is all that can be completed
against or otherwise used to act on.

There are ways for users to get the convenience of
seeing only those display strings, but at the same
time being able to identify/distinguish candidates
that have the same display string but have other
associated information (part of the full candidate).

It is false to think that both the user and
completion need necessarily be blind to such full
information, i.e., such differences.  After all,
`completing-read' knows the full candidate.  In
vanilla Emacs it just simply ignores it for its
job of completing.  That info is essentially
thrown away.

(Note that this is another case where an alist
is richer than a hash table or an obarray, which
exclude duplicate keys.)
___

A related question is whether `completing-read'
should remove duplicate candidates (where the
notion of "same" compares the display strings).
Obviously, if duplicates are removed then you
never see more than one `foo' candidate, and you
can't take advantage of the kinds of things I've
mentioned.

The answer to that "whether" question is that
it depends on the reason for completion and the
particular completion behavior required by the
command that calls `completing-read'.

In Icicles, variable `icicle-transform-function'
is a function that transforms the set of
completion candidates before they're displayed.
By default, no transformation is done, but you
can toggle this anytime during completion with
`C-$'.

When active, the default transformation is to
remove duplicates.  So by default, `C-$'
toggles removal of duplicate candidates.