all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.