GNU bug report logs - #76182
31.0.50; minibuffer-allow-text-properties not reliable

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76182 in the body.
You can then email your comments to 76182 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Mon, 10 Feb 2025 21:58:07 +0530

Despite what the docstring says, setting the variable to t does not seem
to be reliable.  Take the following scenario:

        1. emacs -Q
        2. Paste in
            (let ((cand (list (propertize "test" 'prop 1)
                              (propertize "test1" 'prop 2))))
              (minibuffer-with-setup-hook
                  (lambda ()
                    (setq-local minibuffer-allow-text-properties t))
                (get-text-property 0 'prop (completing-read "test: " cand nil t))))
           *scratch* buffer or wherever.
        3. Evaluate the form.
        4. In the minibuffer prompt, type "test" then press RET.
        5. Observe how the return value is nil.
        6. Evaluate the form again but this time press TAB and RET.
        7. Observe how it returns 1 as expected.
        8. Evaluate the form again but this time type "te", press TAB,
           type "1" and press RET.
        9. Observe how it returns nil.  Here if you examine the string
           returned, you will find that the text-property is retained
           only for indices 2--5.

Is this expected?  I would expect the form to always return the value of
the property 'prop' regardless how I completed the string.
    


In GNU Emacs 31.0.50 (build 30, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.2, Xaw scroll bars) of 2025-01-23 built on astatine
Repository revision: 7dcc7605d58165dac233bcc029509f1ad9807f72
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --with-sound=alsa --with-x-toolkit=lucid --without-xaw3d
 --without-gconf --without-libsystemd --with-cairo CFLAGS=-O2'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: ta_IN.UTF-8
  value of $LC_NUMERIC: ta_IN.UTF-8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug dabbrev mail-extr message sendmail mailcap
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache
epa derived epg rfc6068 epg-config gnus-util text-property-search
time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils
gmm-utils mailheader cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames emacs)

Memory information:
((conses 16 40867 18961) (symbols 48 5442 3) (strings 32 13609 1705)
 (string-bytes 1 317745) (vectors 16 9505)
 (vector-slots 8 114289 8442) (floats 8 26 11) (intervals 56 342 43)
 (buffers 984 11))

Message #8 received at 76182 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: 76182 <at> debbugs.gnu.org
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Tue, 11 Feb 2025 14:11:09 +0200

> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Mon, 10 Feb 2025 21:58:07 +0530
> 
> Despite what the docstring says, setting the variable to t does not seem
> to be reliable.  Take the following scenario:
> 
>         1. emacs -Q
>         2. Paste in
>             (let ((cand (list (propertize "test" 'prop 1)
>                               (propertize "test1" 'prop 2))))
>               (minibuffer-with-setup-hook
>                   (lambda ()
>                     (setq-local minibuffer-allow-text-properties t))
>                 (get-text-property 0 'prop (completing-read "test: " cand nil t))))
>            *scratch* buffer or wherever.
>         3. Evaluate the form.
>         4. In the minibuffer prompt, type "test" then press RET.
>         5. Observe how the return value is nil.
>         6. Evaluate the form again but this time press TAB and RET.
>         7. Observe how it returns 1 as expected.
>         8. Evaluate the form again but this time type "te", press TAB,
>            type "1" and press RET.
>         9. Observe how it returns nil.  Here if you examine the string
>            returned, you will find that the text-property is retained
>            only for indices 2--5.
> 
> Is this expected?  I would expect the form to always return the value of
> the property 'prop' regardless how I completed the string.

Juri, any comments?

Message #11 received at 76182 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76182 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Tue, 11 Feb 2025 19:14:05 +0200

>> Despite what the docstring says, setting the variable to t does not seem
>> to be reliable.  Take the following scenario:
>> 
>>         1. emacs -Q
>>         2. Paste in
>>             (let ((cand (list (propertize "test" 'prop 1)
>>                               (propertize "test1" 'prop 2))))
>>               (minibuffer-with-setup-hook
>>                   (lambda ()
>>                     (setq-local minibuffer-allow-text-properties t))
>>                 (get-text-property 0 'prop (completing-read "test: " cand nil t))))
>>            *scratch* buffer or wherever.
>>         3. Evaluate the form.
>>         4. In the minibuffer prompt, type "test" then press RET.
>>         5. Observe how the return value is nil.
>>         6. Evaluate the form again but this time press TAB and RET.
>>         7. Observe how it returns 1 as expected.
>>         8. Evaluate the form again but this time type "te", press TAB,
>>            type "1" and press RET.
>>         9. Observe how it returns nil.  Here if you examine the string
>>            returned, you will find that the text-property is retained
>>            only for indices 2--5.
>> 
>> Is this expected?  I would expect the form to always return the value of
>> the property 'prop' regardless how I completed the string.
>
> Juri, any comments?

This reminds the recent discussion at
https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00819.html
that required documenting this limitation in the docstring of
'imenu-flatten':

  Since the values `annotation' and `group' rely on text properties,
  you can use them only by selecting candidates from the completions
  buffer, not by typing in the minibuffer.  This also means that
  if you use `minibuffer-next-completion' (`M-<down>') to select
  a completion while point stays in the minibuffer, you need
  to customize `minibuffer-completion-auto-choose' to nil that
  doesn't insert completion candidates to the minibuffer.

Message #14 received at 76182 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76182 <at> debbugs.gnu.org
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Wed, 12 Feb 2025 16:59:42 +0530

[செவ்வாய் பிப்ரவரி 11, 2025] Juri Linkov wrote:

> This reminds the recent discussion at
> https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00819.html
> that required documenting this limitation in the docstring of
> 'imenu-flatten':
>
>   Since the values `annotation' and `group' rely on text properties,
>   you can use them only by selecting candidates from the completions
>   buffer, not by typing in the minibuffer.  This also means that
>   if you use `minibuffer-next-completion' (`M-<down>') to select
>   a completion while point stays in the minibuffer, you need
>   to customize `minibuffer-completion-auto-choose' to nil that
>   doesn't insert completion candidates to the minibuffer.

If it is much too difficult to make it reliable in all cases, shouldn't
this be called out in the docstring of minibuffer-allow-text-properties
itself?

Message #17 received at 76182 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76182 <at> debbugs.gnu.org
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Wed, 12 Feb 2025 19:10:40 +0200

>> This reminds the recent discussion at
>> https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00819.html
>> that required documenting this limitation in the docstring of
>> 'imenu-flatten':
>>
>>   Since the values `annotation' and `group' rely on text properties,
>>   you can use them only by selecting candidates from the completions
>>   buffer, not by typing in the minibuffer.  This also means that
>>   if you use `minibuffer-next-completion' (`M-<down>') to select
>>   a completion while point stays in the minibuffer, you need
>>   to customize `minibuffer-completion-auto-choose' to nil that
>>   doesn't insert completion candidates to the minibuffer.
>
> If it is much too difficult to make it reliable in all cases, shouldn't
> this be called out in the docstring of minibuffer-allow-text-properties
> itself?

Agreed, the docstring of minibuffer-allow-text-properties
is the most suitable place to document this limitation.

Regarding to how difficult is to make it reliable,
a better question is whether it's possible at all.

How could you get text properties from the completion candidate,
when you type text in the minibuffer and don't use completion?

Message #20 received at 76182 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76182 <at> debbugs.gnu.org
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Wed, 12 Feb 2025 23:14:08 +0530

[புதன் பிப்ரவரி 12, 2025] Juri Linkov wrote:

>>> This reminds the recent discussion at
>>> https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00819.html
>>> that required documenting this limitation in the docstring of
>>> 'imenu-flatten':
>>>
>>>   Since the values `annotation' and `group' rely on text properties,
>>>   you can use them only by selecting candidates from the completions
>>>   buffer, not by typing in the minibuffer.  This also means that
>>>   if you use `minibuffer-next-completion' (`M-<down>') to select
>>>   a completion while point stays in the minibuffer, you need
>>>   to customize `minibuffer-completion-auto-choose' to nil that
>>>   doesn't insert completion candidates to the minibuffer.
>>
>> If it is much too difficult to make it reliable in all cases, shouldn't
>> this be called out in the docstring of minibuffer-allow-text-properties
>> itself?
>
> Agreed, the docstring of minibuffer-allow-text-properties
> is the most suitable place to document this limitation.

Thank you for taking care of the documentation.

> Regarding to how difficult is to make it reliable,
> a better question is whether it's possible at all.
>
> How could you get text properties from the completion candidate,
> when you type text in the minibuffer and don't use completion?

That is essentially the conclusion I came to too.  The best way to
"stash metadata" associated with a completion candidate is to use an
alist or a hashtable (or an obarray??) I suppose (so you would end doing
    (alist-get (completing-read ...) candidates nil nil #'equal)).

If that is indeed the conclusion, then this bug can be closed once the
documentation is updated to reflect this limitation.

Message #25 received at 76182-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 76182-done <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Sat, 01 Mar 2025 14:05:07 +0200

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76182 <at> debbugs.gnu.org
> Date: Wed, 12 Feb 2025 23:14:08 +0530
> 
> [புதன் பிப்ரவரி 12, 2025] Juri Linkov wrote:
> 
> >>> This reminds the recent discussion at
> >>> https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00819.html
> >>> that required documenting this limitation in the docstring of
> >>> 'imenu-flatten':
> >>>
> >>>   Since the values `annotation' and `group' rely on text properties,
> >>>   you can use them only by selecting candidates from the completions
> >>>   buffer, not by typing in the minibuffer.  This also means that
> >>>   if you use `minibuffer-next-completion' (`M-<down>') to select
> >>>   a completion while point stays in the minibuffer, you need
> >>>   to customize `minibuffer-completion-auto-choose' to nil that
> >>>   doesn't insert completion candidates to the minibuffer.
> >>
> >> If it is much too difficult to make it reliable in all cases, shouldn't
> >> this be called out in the docstring of minibuffer-allow-text-properties
> >> itself?
> >
> > Agreed, the docstring of minibuffer-allow-text-properties
> > is the most suitable place to document this limitation.
> 
> Thank you for taking care of the documentation.
> 
> > Regarding to how difficult is to make it reliable,
> > a better question is whether it's possible at all.
> >
> > How could you get text properties from the completion candidate,
> > when you type text in the minibuffer and don't use completion?
> 
> That is essentially the conclusion I came to too.  The best way to
> "stash metadata" associated with a completion candidate is to use an
> alist or a hashtable (or an obarray??) I suppose (so you would end doing
>     (alist-get (completing-read ...) candidates nil nil #'equal)).
> 
> If that is indeed the conclusion, then this bug can be closed once the
> documentation is updated to reflect this limitation.

Closing.

Message #28 received at 76182-done <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76182-done <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#76182: 31.0.50; minibuffer-allow-text-properties not reliable
Date: Sat, 01 Mar 2025 20:02:43 +0530

[சனி மார்ச் 01, 2025] Eli Zaretskii wrote:

>> > How could you get text properties from the completion candidate,
>> > when you type text in the minibuffer and don't use completion?
>> 
>> That is essentially the conclusion I came to too.  The best way to
>> "stash metadata" associated with a completion candidate is to use an
>> alist or a hashtable (or an obarray??) I suppose (so you would end doing
>>     (alist-get (completing-read ...) candidates nil nil #'equal)).
>> 
>> If that is indeed the conclusion, then this bug can be closed once the
>> documentation is updated to reflect this limitation.
>
> Closing.

AFAICT, minibuffer-allow-text-properties still doesn't document this
caveat.  imenu-flatten has something:

    Since the values ‘annotation’ and ‘group’ rely on text properties,
    you can use them only by selecting candidates from the completions
    buffer, not by typing in the minibuffer.  This also means that
    if you use ‘minibuffer-next-completion’ (‘M-<down>’) to select
    a completion while point stays in the minibuffer, you need
    to customize ‘minibuffer-completion-auto-choose’ to nil that
    doesn’t insert completion candidates to the minibuffer.
    Also note that for using the value ‘group’ you need to customize
    ‘completions-group’ to the value t, and ‘completions-format’
    to the value ‘vertical’.

but it would be better to document this "gotcha" in
minibuffer-allow-text-properties instead.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.