-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be more strict about affixation functions #351
Comments
…e a string"" This reverts commit 09aaad9. Thank you @jakanakaevangeli. CC @clemera, radian-software/selectrum#351 Fix #46
Why did you close it? Selectrum should be more strict and not accept nil values from affixations. My Marginalia fix ensures that we are always returning strings. |
Thanks, I wasn't looking closely but it appeared to me nil values are accepted |
Isn't your fix handling the situation when the affixation function returns nil? So upstream Emacs affixation functions return nil values no? |
No, my fix fixes the marginalia annotation functions which may return nil. The marginalia affixation function is a small wrapper function. |
What does happen with default completion when there the affixation returns a nil value, is there an error? |
I haven't followed how the issue evolved on the Marginalia side, sooner or later I should install Emacs 28 do be able to check such things myself. I'm still waiting for the native compile branch to get merged into master :) |
What does happen with default completion when there the affixation
returns a nil value, is there an error?
Yup, very early into completion--insert-strings, string-width is used on
every sub-element of each element of affix-fun's return value.
|
Okay, thanks! |
See minad/marginalia#46 (comment). It seems Emacs 28 does has problems with nil values in the results and Selectrum ignores those.
The text was updated successfully, but these errors were encountered: