all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 55205@debbugs.gnu.org
Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates
Date: Sun, 01 May 2022 20:39:22 +0200	[thread overview]
Message-ID: <8735htdrmt.fsf@gnus.org> (raw)
In-Reply-To: <ebfd6bb6-1db3-9cba-499c-4bdf45f97a82@daniel-mendler.de> (Daniel Mendler's message of "Sun, 1 May 2022 20:27:41 +0200")

Daniel Mendler <mail@daniel-mendler.de> writes:

> However when completing a string in the minibuffer, the completed string
> can also be typed by the user and as such won't have the text properties
> attached in the first place. The completion UI would then have to lookup
> the input string in the list of propertized candidate strings. Of course
> this makes only sense for REQUIRE-MATCH non-nil.

Ah, yes, I was thinking about the REQUIRE-MATCH case.

> One motivation for text property preservation is the disambiguation of
> equal strings. I argue that equal candidate strings are not a good idea
> since the user has no way to distinguish them TAB completing.

I've got an imdb interface where I choose among different movies (some
with the same name) by putting the movie poster in the completion
string to disambiguate.  That's the first place I ran into the problem,
years ago (and it seems like people keep trying to do things like that,
and then giving up).

If I remember correctly, I ended up copying most of the completion
machinery into the package just to avoid the stripping.

(It's a somewhat marginal problem, since it's seldom there's several
movies with the same name in the same year, but it happens.  But you
could imagine the same issue when completing, say, names in an org, and
displaying pics of the people to disambiguate.)

> It boils down to the question if we treat completion as step-by-step
> text completion (by pressing TAB) or as a selection process of a
> candidate. Due to the way these different UIs behave, selection vs
> completion is a gray zone.

Hm, yes.

> For unique candidate strings and REQUIRE-MATCH non-nil, looking up
> metadata in a hash table or an alist after the return of
> completing-read is only a small inconvenience.

Yes, but if the strings are identical (except for the text properties),
then that's not really an option.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2022-05-01 18:39 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01  8:27 bug#55205: 28.1.50; completion--replace illegally mutates completion candidates Daniel Mendler
2022-05-01 11:53 ` Lars Ingebrigtsen
2022-05-01 12:17   ` Eli Zaretskii
2022-05-01 20:11     ` Dmitry Gutov
2022-05-02  2:23       ` Eli Zaretskii
2022-05-02  9:46         ` Dmitry Gutov
2022-05-02 14:27           ` Eli Zaretskii
2022-05-02 21:06             ` Dmitry Gutov
2022-05-02 16:01     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-02 16:24       ` Eli Zaretskii
2022-05-02 16:34         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-02 16:38           ` Daniel Mendler
2022-05-02 16:47             ` Eli Zaretskii
2022-05-02 16:43           ` Eli Zaretskii
2022-05-02 16:48             ` Daniel Mendler
2022-05-02 16:53               ` Eli Zaretskii
2022-05-02 16:57                 ` Daniel Mendler
2022-05-02 17:53                   ` Eli Zaretskii
2022-05-02 18:35                     ` Daniel Mendler
2022-05-02 21:18                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 12:40   ` Daniel Mendler
2022-05-01 12:49     ` Eli Zaretskii
2022-05-01 12:54       ` Daniel Mendler
2022-05-01 13:16         ` Eli Zaretskii
2022-05-01 13:19           ` Daniel Mendler
2022-05-01 13:21             ` Daniel Mendler
2022-05-01 12:50     ` Daniel Mendler
2022-05-01 17:07   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 17:26     ` Lars Ingebrigtsen
2022-05-01 17:36       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 17:48         ` Lars Ingebrigtsen
2022-05-01 18:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 18:27       ` Daniel Mendler
2022-05-01 18:39         ` Lars Ingebrigtsen [this message]
2022-05-01 19:01           ` Daniel Mendler
2022-05-01 19:07             ` Lars Ingebrigtsen
2022-05-01 20:52               ` Dmitry Gutov
2022-05-01 20:54                 ` Lars Ingebrigtsen
2022-05-01 21:30                   ` Dmitry Gutov
2022-05-01 21:43                     ` Lars Ingebrigtsen
2022-05-02  6:31           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-02  8:11             ` Lars Ingebrigtsen
2022-05-02  9:00               ` Daniel Mendler
2022-05-02 12:23               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-03 10:13                 ` Lars Ingebrigtsen
2022-05-03 12:55                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-04  7:48                     ` Lars Ingebrigtsen
2022-05-04  8:24                       ` Daniel Mendler
2022-05-04  8:51                         ` Daniel Mendler
2022-05-02  8:49             ` Daniel Mendler
2022-05-02  9:04               ` Lars Ingebrigtsen
2022-05-02  9:57                 ` Daniel Mendler
2022-05-02 10:07                   ` Lars Ingebrigtsen
2022-05-02 10:17                     ` Daniel Mendler
2022-05-01 17:39     ` Eli Zaretskii
2022-05-01 18:06     ` Daniel Mendler
2022-05-02  0:34   ` Richard Stallman

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=8735htdrmt.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=55205@debbugs.gnu.org \
    --cc=mail@daniel-mendler.de \
    --cc=monnier@iro.umontreal.ca \
    /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.