bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

`completing-read` REQUIRE-MATCH arg in describe-variable == t,
describe-symbol == t and describe-function == 'confirm ?

I see no reasons why `describe-function` uses 'confirm but maybe I am
missing something?

Thanks.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2023-07-27 built on IPad-S340
Repository revision: 184fc9b0200cf991c250bb3d6b158eaea2ee7806
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux Mint 21.2

Configured using:
 'configure --bindir=/usr/local/sbin/emacs-30.0.50 --with-mailutils
 --with-cairo --without-dbus --without-gconf --without-gsettings
 --with-x-toolkit=lucid --without-tree-sitter
 --without-native-compilation'

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

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: 

Minor modes in effect:
  emms-mode-line-mode: t
  emms-playing-time-display-mode: t
  emms-playing-time-mode: t
  bug-reference-prog-mode: t
  server-mode: t
  psession-mode: t
  psession-savehist-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-git-gutter-mode: t
  git-gutter-mode: t
  display-time-mode: t
  winner-mode: t
  tv-save-place-mode: t
  helm-epa-mode: t
  helm-descbinds-mode: t
  helm-top-poll-mode: t
  helm-adaptive-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-ff-icon-mode: t
  helm-popup-tip-mode: t
  async-bytecomp-package-mode: t
  dired-async-mode: t
  minibuffer-depth-indicate-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/local/share/emacs/30.0.50/lisp/progmodes/eglot hides ~/elisp/eglot

Features:
(shadow epa-mail face-remap emacsbug addressbook-bookmark tv-mu4e-config
config-w3m mu4e-contrib eshell esh-cmd generator esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util mu4e-patch mu4e
mu4e-org org-config ob-gnuplot org-crypt org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list
org-footnote org-faces org-entities noutline outline ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys
oc org-loaddefs org-version org-compat org-macs mu4e-notification
notifications mu4e-main mu4e-view gnus-art mm-uu mml2015 mm-view
mml-smime smime gnutls dig gnus-sum gnus-group gnus-undo gnus-start
gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec
gnus-int gnus-range gnus-win gnus nnheader range appt diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs mu4e-headers mu4e-thread
mu4e-compose mu4e-draft mu4e-actions smtpmail mu4e-search mu4e-lists
mu4e-bookmarks mu4e-mark mu4e-message shr pixel-fill kinsoku url-file
svg dom flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders
mu4e-context mu4e-query-items mu4e-server mu4e-modeline mu4e-vars
mu4e-helpers mu4e-config mu4e-window ido message sendmail yank-media
puny rfc822 mml mml-sec gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader mu4e-obsolete image-file
image-converter char-fold helm-x-files helm-for-files helm-bookmark
bookmark helm-command cl-extra helm-elisp helm-eval edebug debug
backtrace find-func helm-info emms-config emms-librefm-stream
emms-librefm-scrobbler emms-playlist-limit emms-i18n emms-history
emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks
emms-cue emms-mode-line-icon emms-browser sort emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-lyrics emms-url emms-streams emms-show-all
emms-tag-editor emms-tag-tracktag emms-mark emms-mode-line emms-cache
emms-info-native bindat emms-info-exiftool emms-info-tinytag
emms-info-metaflac emms-info-opusinfo emms-info-ogginfo
emms-info-mp3info emms-playlist-mode emms-player-vlc emms-player-mpv
emms-playing-time emms-info emms-later-do emms-player-mplayer
emms-player-simple emms-source-playlist emms-source-file locate
emms-setup emms emms-compat emms-auto helm-external helm-net
tramp-archive tramp-gvfs dbus xml ffap helm-ls-git vc-git diff-mode vc
vc-dispatcher jka-compr flymake-shellcheck cus-start flymake-proc
flymake project warnings thingatpt sh-script smie treesit executable
bug-reference naquadah-theme server imenu psession frameset undo-tree
diff queue pcase git-gutter mule-util dired-extension time winner
describe-variable help-fns radix-tree help-mode tv-utils
tv-save-place.el advice init-helm epa derived epg rfc6068 epg-config
helm-epa isl helm-descbinds all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons cus-edit pp icons wid-edit helm-sys popup
helm-adaptive helm-mode helm-misc helm-files image-dired
image-dired-tags image-dired-external image-dired-util image-mode exif
filenotify tramp rx tramp-loaddefs trampver tramp-integration files-x
tramp-compat xdg shell pcomplete parse-time iso8601 time-date
helm-buffers helm-occur helm-tags helm-locate helm-grep wgrep-helm wgrep
grep compile text-property-search comint ansi-osc ring helm-regexp
format-spec ansi-color helm-utils helm-help helm-types
helm-extensions-autoloads helm-autoloads helm helm-global-bindings
helm-easymenu edmacro kmacro helm-core easy-mmode async-bytecomp
helm-source helm-multi-match helm-lib dired-async async dired-aux dired
dired-loaddefs mb-depth avoid cus-load info w3m-load package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars 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 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 inotify lcms2 dynamic-setting font-render-setting cairo
x-toolkit xinput2 x multi-tty move-toolbar make-network-process emacs)

Memory information:
((conses 16 651411 74012) (symbols 48 34461 5)
 (strings 32 200613 7614) (string-bytes 1 5933701) (vectors 16 74764)
 (vector-slots 8 1675050 65239) (floats 8 2537 169)
 (intervals 56 9689 2431) (buffers 976 112))
<#secure method=pgpmime mode=sign>

-- 
Thierry

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Date: Thu, 27 Jul 2023 14:52:14 +0000
> 
> 
> `completing-read` REQUIRE-MATCH arg in describe-variable == t,
> describe-symbol == t and describe-function == 'confirm ?
> 
> I see no reasons why `describe-function` uses 'confirm but maybe I am
> missing something?

Stefan (CC'ed) made that change last September, and it looks
deliberate.

Stefan?

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> `completing-read` REQUIRE-MATCH arg in describe-variable == t,
>> describe-symbol == t and describe-function == 'confirm ?
>> 
>> I see no reasons why `describe-function` uses 'confirm but maybe I am
>> missing something?
>
> Stefan (CC'ed) made that change last September, and it looks
> deliberate.
>
> Stefan?

I'm not sure what was the situation that motivated it, because I failed
to write it in the comment or commit message :-(
I suspect it might have been when a function is advised but not yet defined.


        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> `completing-read` REQUIRE-MATCH arg in describe-variable == t,
>>> describe-symbol == t and describe-function == 'confirm ?
>>> 
>>> I see no reasons why `describe-function` uses 'confirm but maybe I am
>>> missing something?
>>
>> Stefan (CC'ed) made that change last September, and it looks
>> deliberate.
>>
>> Stefan?
>
> I'm not sure what was the situation that motivated it, because I failed
> to write it in the comment or commit message :-(
> I suspect it might have been when a function is advised but not yet defined.

Hmm, how could this happen?  The problem is that with Helm completion I
have an extra unknow symbol on top of list when I start typing (this is
expected when require-match is non-nil), not very
annoying but I am pretty sure I will have bug reports about this.

>
>         Stefan


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> I suspect it might have been when a function is advised but not yet defined.
> Hmm, how could this happen?

It happens all the time: just call `advice-add` before the function is defined.

> The problem is that with Helm completion I have an extra unknown
> symbol on top of list when I start typing (this is expected when
> require-match is non-nil),

Could you characterize this "unknown symbol" a bit more?  I'm having
trouble guessing why/how/where `confirm` would have such an effect.

Maybe we can fix that without preventing the use of "not quite
defined" functions.


        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I suspect it might have been when a function is advised but not yet defined.
>> Hmm, how could this happen?
>
> It happens all the time: just call `advice-add` before the function is defined.

I hardly see how one would do this, sorry.

>> The problem is that with Helm completion I have an extra unknown
>> symbol on top of list when I start typing (this is expected when
>> require-match is non-nil),
>
> Could you characterize this "unknown symbol" a bit more?  I'm having
> trouble guessing why/how/where `confirm` would have such an effect.

In Helm, if require-match is 'confirm, when you write in minibuffer something
that doesn't match one of the candidates this string is appended on top
of list and is prefixed (with display prop) with [?]. By contrast when
require-match is nil nothing is appended on top of list and pressing RET
doesn't exit minibuffer (helm-buffer is empty in such case).
IOW the behavior of require-match is the same than with vanilla Emacs.

> Maybe we can fix that without preventing the use of "not quite
> defined" functions.

Sorry, as said above I don't understand what you want to achieve here.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]


Thierry Volpiatto <thievol@posteo.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> I suspect it might have been when a function is advised but not yet defined.
>>> Hmm, how could this happen?
>>
>> It happens all the time: just call `advice-add` before the function is defined.
>
> I hardly see how one would do this, sorry.
>
>>> The problem is that with Helm completion I have an extra unknown
>>> symbol on top of list when I start typing (this is expected when
>>> require-match is non-nil),
>>
>> Could you characterize this "unknown symbol" a bit more?  I'm having
>> trouble guessing why/how/where `confirm` would have such an effect.
>
> In Helm, if require-match is 'confirm, when you write in minibuffer something
> that doesn't match one of the candidates this string is appended on top
> of list and is prefixed (with display prop) with [?]. By contrast when
> require-match is nil nothing is appended on top of list and pressing RET
> doesn't exit minibuffer (helm-buffer is empty in such case).
> IOW the behavior of require-match is the same than with vanilla Emacs.
>
>> Maybe we can fix that without preventing the use of "not quite
>> defined" functions.
>
> Sorry, as said above I don't understand what you want to achieve here.

I made a change in Helm to allow overriding require-match if needed, see
https://github.com/emacs-helm/helm/commit/4cfa25d930cf4084d46e58dc403c5a5b67782a23

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 64902@debbugs.gnu.org
> Date: Fri, 28 Jul 2023 16:16:42 +0000
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>> I suspect it might have been when a function is advised but not yet defined.
> >> Hmm, how could this happen?
> >
> > It happens all the time: just call `advice-add` before the function is defined.
> 
> I hardly see how one would do this, sorry.
> 
> >> The problem is that with Helm completion I have an extra unknown
> >> symbol on top of list when I start typing (this is expected when
> >> require-match is non-nil),
> >
> > Could you characterize this "unknown symbol" a bit more?  I'm having
> > trouble guessing why/how/where `confirm` would have such an effect.
> 
> In Helm, if require-match is 'confirm, when you write in minibuffer something
> that doesn't match one of the candidates this string is appended on top
> of list and is prefixed (with display prop) with [?]. By contrast when
> require-match is nil nothing is appended on top of list and pressing RET
> doesn't exit minibuffer (helm-buffer is empty in such case).
> IOW the behavior of require-match is the same than with vanilla Emacs.
> 
> > Maybe we can fix that without preventing the use of "not quite
> > defined" functions.
> 
> Sorry, as said above I don't understand what you want to achieve here.

I've now added a comment to that particular call to completing-read,
and I'm therefore closing this bug.

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> The problem is that with Helm completion I have an extra unknown
>>> symbol on top of list when I start typing (this is expected when
>>> require-match is non-nil),
>> Could you characterize this "unknown symbol" a bit more?  I'm having
>> trouble guessing why/how/where `confirm` would have such an effect.
> In Helm, if require-match is 'confirm, when you write in minibuffer something
> that doesn't match one of the candidates this string is appended on top
> of list and is prefixed (with display prop) with [?]. By contrast when
> require-match is nil nothing is appended on top of list and pressing RET
> doesn't exit minibuffer (helm-buffer is empty in such case).
> IOW the behavior of require-match is the same than with vanilla Emacs.

I see.  So IIUC every piece works "correctly", but since it's *very*
rare to want to use this ?-prefixed option in the case of
`describe-function`, it looks/feels like a bug.

The core of the problem is that in the normal UI, `confirm` is very
lightweight (you'll basically only notice it when you do try to enter
the name of a function that's not defined) whereas in the Helm UI it's
harder to hide it.

And I guess for other cases (like `find-file`) the use of the ?-prefixed
option is sufficiently common to deserve being more visible?



        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> The core of the problem is that in the normal UI, `confirm` is very
> lightweight (you'll basically only notice it when you do try to enter
> the name of a function that's not defined) whereas in the Helm UI it's
> harder to hide it.

In the long run, maybe the better option would be to move the `confirm`
info from `require-match` to `test-completion`: make it so
`test-completion` can return a value which says "this may be a valid
completion but it requires confirmation from the user".

This way `describe-function` could distinguish between names which are
sure to correspond to nothing (e.g. there is no matching symbol in
`obarray`, or there is but it has both `symbol-function` and
`symbol-plist` are empty) and names where `symbol-function` is nil, but
there are some properties defined.


        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The core of the problem is that in the normal UI, `confirm` is very
>> lightweight (you'll basically only notice it when you do try to enter
>> the name of a function that's not defined) whereas in the Helm UI it's
>> harder to hide it.
>
> In the long run, maybe the better option would be to move the `confirm`
> info from `require-match` to `test-completion`: make it so
> `test-completion` can return a value which says "this may be a valid
> completion but it requires confirmation from the user".

I still don't understand why you insist to have confirmation from user,
describe-function give you only an information, it doesn't run a command
or a function, what's the problem of exiting directly?

> This way `describe-function` could distinguish between names which are
> sure to correspond to nothing (e.g. there is no matching symbol in
> `obarray`, or there is but it has both `symbol-function` and
> `symbol-plist` are empty) and names where `symbol-function` is nil, but
> there are some properties defined.

Not sure to understand what the predicate would be:

(and (symbol-function sym) (symbol-plist sym))
or
(or (symbol-function sym) (symbol-plist sym))
or
(symbol-function sym) alone
or
(symbol-plist sym) alone

In the example shown in screenshot I sent before I used symbol-function
alone, isn't it enough?

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I still don't understand why you insist to have confirmation from user,

Hmm... maybe you're right and we don't need the confirmation.

>> This way `describe-function` could distinguish between names which are
>> sure to correspond to nothing (e.g. there is no matching symbol in
>> `obarray`, or there is but it has both `symbol-function` and
>> `symbol-plist` are empty) and names where `symbol-function` is nil, but
>> there are some properties defined.
>
> Not sure to understand what the predicate would be:
>
> (and (symbol-function sym) (symbol-plist sym))

No.

> (or (symbol-function sym) (symbol-plist sym))

Yes.

> In the example shown in screenshot I sent before I used symbol-function
> alone, isn't it enough?

Having tried now I see that the command signals an error when
symbol-function is void.  Apparently this use-case is not tested enough
to keep it working, so I've changed my mind: I just reverted
my change.

Thanks for bringing it up :-)


        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]


Hello Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Having tried now I see that the command signals an error when
> symbol-function is void.

Assuming that "the command" is `describe-function` and you mean the
argument SYMBOL of `symbol-function` is void (I hardly see why
`symbol-function` would be void), I can't reproduce your
error, here a small recipe:

(defun advice-foo-test ()
  (message "Hello"))

(advice-add 'foo-test :override 'advice-foo-test)

C-h f foo-test RET
=>
,----
| foo-test is .
| 
| [Missing arglist.]
| 
| Not documented.
`----
(symbol-function 'foo-test)
=> nil (no errors)

(foo-test)
=> Error:Void function foo-test (as expected)


> Apparently this use-case is not tested enough to keep it working, so
> I've changed my mind: I just reverted my change.

Ok, thanks.

> Thanks for bringing it up :-)

You are welcome.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Having tried now I see that the command signals an error when
>> symbol-function is void.
>
> Assuming that "the command" is `describe-function` and you mean the
> argument SYMBOL of `symbol-function` is void (I hardly see why
> `symbol-function` would be void), I can't reproduce your
> error, here a small recipe:

Yes, in some cases it does "work".

> (defun advice-foo-test ()
>   (message "Hello"))
>
> (advice-add 'foo-test :override 'advice-foo-test)

Notice that even after reverting my commit, `describe-function` still
accepts (and completes) `foo-test` :-)
[ This is because it adds a `function-documentation` property.  ]

> ,----
> | foo-test is .
> | 
> | [Missing arglist.]
> | 
> | Not documented.
> `----

It doesn't signal an error, but the *Help* above is rather poor :-(


        Stefan

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Having tried now I see that the command signals an error when
>>> symbol-function is void.
>>
>> Assuming that "the command" is `describe-function` and you mean the
>> argument SYMBOL of `symbol-function` is void (I hardly see why
>> `symbol-function` would be void), I can't reproduce your
>> error, here a small recipe:
>
> Yes, in some cases it does "work".

So in which cases does it fails?

>> (defun advice-foo-test ()
>>   (message "Hello"))
>>
>> (advice-add 'foo-test :override 'advice-foo-test)
>
> Notice that even after reverting my commit, `describe-function` still
> accepts (and completes) `foo-test` :-)

Yes I already noticed this ;-)

> 
> [ This is because it adds a `function-documentation` property.  ]

Ok, thanks to explain this.

>> ,----
>> | foo-test is .
>> | 
>> | [Missing arglist.]
>> | 
>> | Not documented.
>> `----
>
> It doesn't signal an error, but the *Help* above is rather poor :-(

Yes it is why now Helm adds a brief description in such case when
completions-detailed is enabled.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#64902: 30.0.50; REQUIRE-MATCH completing-read arg in describe-* commands

[Thierry Volpiatto]

[-- Attachment #1.1: Type: text/plain, Size: 2112 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> The problem is that with Helm completion I have an extra unknown
>>>> symbol on top of list when I start typing (this is expected when
>>>> require-match is non-nil),
>>> Could you characterize this "unknown symbol" a bit more?  I'm having
>>> trouble guessing why/how/where `confirm` would have such an effect.
>> In Helm, if require-match is 'confirm, when you write in minibuffer something
>> that doesn't match one of the candidates this string is appended on top
>> of list and is prefixed (with display prop) with [?]. By contrast when
>> require-match is nil nothing is appended on top of list and pressing RET
>> doesn't exit minibuffer (helm-buffer is empty in such case).
>> IOW the behavior of require-match is the same than with vanilla Emacs.
>
> I see.  So IIUC every piece works "correctly", but since it's *very*
> rare to want to use this ?-prefixed option in the case of
> `describe-function`, it looks/feels like a bug.

No, it is just annoying.

> The core of the problem is that in the normal UI, `confirm` is very
> lightweight (you'll basically only notice it when you do try to enter
> the name of a function that's not defined) whereas in the Helm UI it's
> harder to hide it.

I think 'confirm doesn't help, having to press twice on RET doesn't
explain what's going wrong to the user, I would expect something like:

i foo-test Not already defined

with "i" like invalid, foo-test highlighted, and "Not already defined"
explaining briefly what the symbol is.
This would show up only when completions-detailed is non nil.
See attached screenshot of C-h f with completions-detailed non nil.

> And I guess for other cases (like `find-file`) the use of the ?-prefixed
> option is sufficiently common to deserve being more visible?

For files the prefix is [+], which mean create a new file or directory
when pressing RET (will create a dir when new filename ends with "/"),
when using icons, the prefix is an icon for dir or file instead of [+].

>
>
>         Stefan


-- 
Thierry

[-- Attachment #1.2: Capture d’écran_2023-08-05_08-39-03.png --]
[-- Type: image/png, Size: 260755 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]