From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 43218@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
Nicolas Graner <nicolas.graner@universite-paris-saclay.fr>
Subject: bug#43218: EWW handles default answer incorrectly when changing a select
Date: Sun, 6 Sep 2020 10:18:57 -0700 (PDT) [thread overview]
Message-ID: <627f040f-2c8f-4a5a-807d-5b4ec0237a03@default> (raw)
In-Reply-To: <87tuwaesn3.fsf@gnus.org>
> > The point is that the `completing-read' behavior,
> > which shows only the car of an alist entry (plus
> > possibly an annotation), is quite limited.
>
> Yeah. And I now remember why the question seemed so familiar to me -- I
> think I asked the same question a couple a years ago when I wrote a mode
> for doing IMDB searches, and I ended up with (I see now; I'd forgotten
> all about this):...
>
> But I guess I still wonder why `completing-read' strips the text
> properties from the completions? If it's historical reasons, why
> not allow minibuffer-allow-text-properties to override that?
`completing-read' is likely older than text properties
on strings. (It was coded only in C for a long time.)
As I said, `minibuffer-allow-text-properties' only has
an effect on text that is in the minibuffer. When you
complete against candidates, the result may or may not
ever get put into the minibuffer, and it has no text
properties.
next prev parent reply other threads:[~2020-09-06 17:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-05 10:44 bug#43218: EWW handles default answer incorrectly when changing a select Nicolas Graner
2020-09-05 13:51 ` Lars Ingebrigtsen
2020-09-05 17:18 ` Nicolas Graner
2020-09-05 23:59 ` Lars Ingebrigtsen
2020-09-06 1:55 ` Stefan Monnier
2020-09-06 11:48 ` Lars Ingebrigtsen
2020-09-06 12:29 ` Nicolas Graner
2020-09-06 12:35 ` Lars Ingebrigtsen
2020-09-06 14:40 ` Eli Zaretskii
2020-09-06 14:41 ` Lars Ingebrigtsen
2020-09-06 14:57 ` Eli Zaretskii
2020-09-06 17:05 ` Lars Ingebrigtsen
2020-09-06 17:56 ` Nicolas Graner
2020-09-06 19:32 ` Lars Ingebrigtsen
2020-09-06 17:06 ` Drew Adams
2020-09-06 17:12 ` Lars Ingebrigtsen
2020-09-06 17:18 ` Drew Adams [this message]
2020-09-06 17:26 ` Lars Ingebrigtsen
2020-09-06 18:57 ` Stefan Monnier
2020-09-06 22:49 ` Lars Ingebrigtsen
2020-09-06 22:56 ` Lars Ingebrigtsen
2020-09-06 4:41 ` 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=627f040f-2c8f-4a5a-807d-5b4ec0237a03@default \
--to=drew.adams@oracle.com \
--cc=43218@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=nicolas.graner@universite-paris-saclay.fr \
/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).