Text properties should be kept for default value

[JuanGarcia345]

Hello!

First of all, thank you for this nice piece of software!

While using xref and lsp-mode, the default value passed to completing-read has properties that should be kept, otherwise code navigation may be broken (this is the case for C++ with clangd).

In fact, keeping properties of default value seems to be the default behaviour of completing-read, for the sake of completeness:

(selectrum-mode -1)

(setq
 vanilla-output
 (completing-read "Test (hit RET to choose default): "
                  '(("foo" . 1) ("bar" . 2))
                  nil nil nil nil
                  #("bar" 0 3 (face font-lock-function-name-face fontified t identifier-at-point t))))

(selectrum-mode +1)

(setq
 selectrum-output
 (completing-read "Test (hit RET to choose default): "
                  '(("foo" . 1) ("bar" . 2))
                  nil nil nil nil
                  #("bar" 0 3 (face font-lock-function-name-face fontified t identifier-at-point t))))

(message "%s" (text-properties-at 1 vanilla-output))
(message "%s" (text-properties-at 1 selectrum-output))

This may be related to #107 and #108.

[clemera]

Thanks for reporting. So for usual candidates returning them with text props will trigger errors and for the default you trigger errors if you strip them 🤦. The default also gets returned unchanged for completing-read, completing-read-multiple, read-buffer and read-file-name. To simplify this I think we can handle this within selectrum-read: If minibuffer-completion-table is non-nil we know it's a built-in completion function and we can strip the text properties unless the default-candidate was chosen then we return the default as it was passed.

[JuanGarcia345]

Well that seems pretty right! Anyway one may say that the read family is not that much POLA compliant 😅

[clemera]

Should be fixed by #198?

[raxod502]

This thread is being closed automatically by Tidier because it is labeled with "waiting on response" and has not seen any activity for 90 days. But don't worry—if you have any information that might advance the discussion, leave a comment and I will be happy to reopen the thread :)

[JuanGarcia345]

Sorry about the non-response on my side, #198 fixes the issue. Really nice work! and thank you both @raxod502 @clemera