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

[Drew Adams]

> > Activate the select and change its value to 'two'.
> > Activate it again and answer <RET> to the prompt for value: the
> > displayed value returns to 'one'.
> >
> > This is not critical as this situation is rare and the value sent to the
> > server will be correct anyway, but it is confusing to the user who does
> > not usually know the value of each option.
> 
> That's true...  there's also a general problem with how the values are
> selected: We're doing a completing-read over the display names, and then
> mapping that back to the values.  But this is perfectly valid:
> 
> <select name="a">
> <option value="1">one</option>
> <option value="2">one</option>
> </select>
> 
> But there's no way to select the second value in eww.
> 
> Unfortunately, the Emacs primitives for prompting are very
> text-oriented, and don't allow putting properties on the values we're
> completing over, not even with:
> 
> ---
> minibuffer-allow-text-properties is a variable defined in ‘src/minibuf.c’.
> Its value is nil
> 
>   Probably introduced at or before Emacs version 20.
> 
> Documentation:
> Non-nil means ‘read-from-minibuffer’ should not discard text properties.
> This also affects ‘read-string’, but it does not affect ‘read-minibuffer’,
> ‘read-no-blanks-input’, or any of the functions that do minibuffer input
> with completion; they always discard text properties.
> ---
> 
> I wonder what the logic behind this is?  And I also have a vague feeling
> I've asked this before...
> 
> Perhaps Stefan knows and or remembers.  :-)
> 
> So the test case is:
> 
> (let ((minibuffer-allow-text-properties t))
>   (completing-read "Foo: " (list (propertize "foo" 'data 'bar))
>                    nil 'require-match))
> => "foo"
> 
> instead of #("foo" 0 3 (data bar))

Huge apologies for jumping in here, possibly
missing the point completely, and probably
not providing much that helps operationally.

But I think I know what you're talking about.

If so, first, note this:

(let ((minibuffer-allow-text-properties t))
  (read-from-minibuffer
    "Foo: " nil nil nil nil
    (propertize "foo" 'data 'bar)))

Use `M-n RET'.  The doc tells you that it only
returns a propertized string that was in the
_minibuffer_ when you hit RET.

That's not the case for a chosen
`completing-read' candidate.  As you quoted
from the doc string:

> the functions that do minibuffer input with
> completion ... always discard text properties.

Second, I can speak a bit to how Icicles deals
with this sort of thing.

I tried (more than once) to get vanilla Emacs
to let you use propertized strings as completion
candidates, both (1) for display in *Completions*
and (2) as returned value for `completing-read'.

I see that in the Icicles doc I mention that
in 2007 RMS agreed to fix Emacs to provide #1,
but AFAIK that never happened.

Icicles redefines `display-completion-alist'
so that it does display propertized candidates.

And Icicles redefines `completing-read' so  it
returns a propertized display-candidate string
that you choose.

You can do more.  But already those two simple
additions go a long way.

Wrt the problem I think you raise above, which
is dealing with multiple candidates that have
the same display string but are associated with
different "values" in some sense (the simplest
being the cdr of an alist cons whose car is the
display candidate):

1. When you cycle among candidates or use mouse-2
to choose one, there's the notion of "current
candidate", so Icicles knows which alist element
you choose (not just which display string).

2. If you bind `icicle-whole-cand-as-text-prop-p'
to non-nil then an entire alist element is put
on its car (the display string) as a property, so
when `completing-read' returns that string the
full candidate (the alist element) can be recovered.
This takes care of distinguishing element
("foo" . 42) from element ("foo" 5 4 3).

#2 is just this:

(let ((text-cand  (copy-sequence (car cand))))
  (put-text-property 0 (length text-cand)
                     'icicle-whole-candidate
                     (cdr cand) text-cand)
  (setcar cand text-cand)
  text-cand)

Then:

(and icicle-whole-candidate-as-text-prop-p
     (get-text-property
       0 'icicle-whole-candidate string))

(I use the same "trick" in Bookmark+ to handle
different bookmarks that have the same name.)

Here are two doc pages that discuss this a bit:

https://www.emacswiki.org/emacs/Icicles_-_Programming_with_Fancy_Candidates#fancy_candidates

https://www.emacswiki.org/emacs/Icicles_-_Candidates_with_Text_Properties