Selectrum: Invisible text properties in candidates lead to odd cursor behavior

[minad]

See the discussion in https://github.com/minad/consult/issues/161.

I changed some of the Consult tofu prefixes from 'display "" to 'invisible t which arguably is the cleaner solution and works better with default completion and icomplete.

When tab completing such candidates and then moving to the beginning via arrow keys or C-a, the cursor jumps in weird ways or is even hidden. I believe the culprit is the function selectrum--fix-minibuffer-message or some other function which performs cursor adjustments.

cc @oantolin @clemera.

[clemera]

minibuffer-message isn't involved I think it is some display issue in combination of the after-string overlay and the (put-text-property 0 1 'cursor t minibuf-after-string) we use.

[clemera]

I don't know how we could fix that, maybe this is some general display thing, I'm tempted to simply strip any invisible leading chars by default, than the copying issue would also be gone.

[clemera]

Even setting disable-point-adjustment did not work...

[clemera]

BTW it is not an issue of the overlay as that is coming after the input text, does it work with default completion/icomplete?

[minad]

With default completion/icomplete I have no problems when moving to the beginning. What kind of overlay is put there by Selectrum?

Have you been able to reproduce the error? I give you a more precise description this may help.

M-x consult-line RET TAB <left> <left>....

When arriving at the beginning the cursor jumps to the end! This is definitely a Selectrum bug. Selectrum somehow adjusts the cursor position.

[clemera]

There is no overlay at the prompt start, only after the input comes the overlay but it jumps to the position of the overlay start when entering the invisible char. I believe this is a display bug and Selectrum isn't to blame but the question is why it works with icomplete then.

[clemera]

See also (info "(elisp) Adjusting Point") and (info "(elisp) Invisible Text")

[minad]

I guess I will fix it such that the tofus will only be fried when selectrum is not active. But I am not entirely happy with that. However the bug is also not that common and won't be triggered too often. Maybe we can figure it out, there is no real hurry.

[clemera]

The point doesn't actually move when you move it forwards again it will be back at the start.

[minad]

I see, so it is really only a display issue.

[clemera]

Would it harm the filtering when removing the invisible chars on insertion?

[minad]

Would it harm the filtering when removing the invisible chars?

I am unsure, you know better. But from my intuition I think it is a bad idea :grin:

EDIT: I would not add hacks on top of hacks, in particular since it is in a different package!

[clemera]

As far as I remember they are only used to distinguish duplicates, and that should only matter when you submit a candidate, so for insertion I guess it would be save to remove them.

[minad]

As far as I remember they are only used to distinguish duplicates, and that should only matter when you submit a candidate, so for insertion I guess it would be save to remove them.

Yes, but I would not do it because of adding hacks on top of hacks. Let's find a better solution.

[clemera]

You could do it for Selectrum on the consult side maybe :)

[clemera]

I mean replacing the display property with invisible property is also a hack.

[minad]

I mean replacing the display property with invisible property is also hack.

Do you think 'invisible t is worse than 'display "" or 'display " "? But I already said that it is a hack. We should not add hacks to Selectrum in order make the Consult hack to work.

[clemera]

No, I meant using after-change-functions to do that. It is a hack to make the char disappear for default completion so adding one for Selectrum wouldn't harm I think, but you judge ;)

[minad]

No, I meant using after-change-functions to do that. It is a hack to make the char disappear for default completion so adding one for Selectrum wouldn't harm I think, but you judge ;)

Well, I just saw that this particular issue also holds for consult-buffer now even if we don't use the after-change-functions hack, since the buffer candidates also have the invisible property in front!

[minad]

I will try something else and report back!

[oantolin]

Would it harm the filtering when removing the invisible chars on insertion?

Right now if you insert candidate it matches only itself. If you remove the invisible characters it could conceivably match other candidates too.

[clemera]

Good point, so currently its either worse matching on insertion or problems with the inserted string itself.

[minad]

The best solution I have found until now is to use 'invisible t for default completion and 'display " " for Selectrum in the consult--fry-tofu-function. This fixes all issues, but there is this space in front which may annoy some Selectrum users, like me.

EDIT: I could use a zero width space but this introduces some rendering issues on its own including a compressed cursor. And some people have this glyph thing activated.

[clemera]

And some people have this glyph thing activated.

Yeah, me too :smile:

[minad]

I know :laughing:

[minad]

Maybe I will just accept the cursor jumping behavior for now.

[clemera]

I would prefer not exact matching results but neither is optimal.

[clemera]

Usually I insert a candidate to C-a C-k...

[minad]

Well, but it is really only a rendering issue which does not affect functionality.

[clemera]

It does affect my neurons in a bad way :laughing: I hope we will find a way to fix the display issue at times.

[oantolin]

Usually I insert a candidate to C-a C-k...

This makes me so sad, @clemera! The "right" way is embark-act(-noexit), w, of course. 😉

[clemera]

We even have M-w bound in Selectrum from the early days which could also get used, but embark would be the right way! I need to get rid of that habit really.

[minad]

See #272, this can be closed without further action here. But maybe it makes still sense to report upstream - I only don't know what exactly should be reported. (Btw, Vertico also had the cursor problem)