Stefan Monnier 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