[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43218: EWW handles default answer incorrectly when changing a select
From: |
Lars Ingebrigtsen |
Subject: |
bug#43218: EWW handles default answer incorrectly when changing a select |
Date: |
Sun, 06 Sep 2020 01:59:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Nicolas Graner <nicolas.graner@universite-paris-saclay.fr> writes:
> 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))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#43218: EWW handles default answer incorrectly when changing a select, Nicolas Graner, 2020/09/05
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/05
- bug#43218: EWW handles default answer incorrectly when changing a select, Nicolas Graner, 2020/09/05
- bug#43218: EWW handles default answer incorrectly when changing a select,
Lars Ingebrigtsen <=
- bug#43218: EWW handles default answer incorrectly when changing a select, Stefan Monnier, 2020/09/05
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Nicolas Graner, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Eli Zaretskii, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Eli Zaretskii, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Nicolas Graner, 2020/09/06
- bug#43218: EWW handles default answer incorrectly when changing a select, Lars Ingebrigtsen, 2020/09/06