Marginalia annotators show small arrow with selectrum-extend-current-candiate-highlight

[minad]

This issue has been reported multiple times before in Marginalia, see minad/marginalia#42. Marginalia uses the full width for the annotations and Selectrum appends the overlay when selectrum-extend-current-candiate-highlight is set. Then Emacs shows the small line overflow arrow. Can this be avoided?

[clemera]

We already have the selectrum-right-margin-padding option but that is only a workaround and also doesn't have any effect when using marginalia, yet (as it is currently only used for right margin text not annotations). After reading through info a bit it seems we can make use of fringe-indicator-alist. I tested with the following which successfully hides the truncation arrows for me:

(setq-local fringe-indicator-alist '((truncation nil nil)))

[minad]

I just looked into the code and thought about a potential workaround (For this reason I also stumbled over #451). The problem is that Selectrum adds this additional string with the space display property. Maybe this can be solved in another way for example by using overlays.

[clemera]

We only use the buffer string returned from the temp buffer, the overlays would be lost but we could probably just insert the space directly when this does avoid the arrows.

[minad]

It seems to me there is no easy fix for this issue. But since the ugly arrow is only shown for the current candidate if Marginalia is activated I think I can live with it.

[clemera]

What about the local fringe-indicator-alist?

[minad]

I am not sure about that one. It would be nice since we also had complaints in Marginalia. This would certainly simplify things. But I think it is too intrusive. Is it not intentional that you can also scroll around in Selectrum for long candidates?

[clemera]

Is it not intentional that you can also scroll around in Selectrum for long candidates?

Yes, but you would still be able to do that you just wouldn't get an indication that there is more but maybe that is less of a problem than seeing that arrow all the time.

[minad]

No, right now under normal circumstances there is no arrow. There is only an arrow when we have an overflow so it is actually a useful indicator. I think I would like to keep it.

[clemera]

I see it all the time on the current candidate when activating marginalia-mode but I don't use it by default and haven't updated for a while.

[minad]

Yes, I also see it all the time on the current candidate. But only on the current candidate, which I don't find too problematic. I think the correct solution would be to check if the current candidate already extends over the full line, since marginalia also adds these 'display space :align-to properties. I don't know if there is an easy way to check if a string expands?

[clemera]

I don't know, maybe we should also report it upstream? As I see it the arrow should just not be shown in the current candidate case (when it doesn't extends beyond the window).

[clemera]

Oh I have to look into it more closely, I wasn't aware of that this is only because of the duplicated space alignment.

[clemera]

It seems we would need to have a way to detect that the annotation already aligns to the right fringe, the only way I know about that could work is to scan for the use of this in the display property.

[clemera]

The following is a hackish way to check that right-fringe alignment is already involved in some way:

(cl-loop for pos from 0 to (1- (length displayed-candidate))
         for disp = (get-text-property pos 'display displayed-candidate)
         if (and (consp disp)
                 (memq 'right-fringe (cadr (memq :align-to disp))))
         return t)

[minad]

Marginalia uses 'right afaik. But this ist certainly not a robust solution.

[clemera]

Yeah, it is not, I already corrected some flaws ;) Can't think of something better currently.

[clemera]

If the highlighting of the selected candidate would be handled when creating the actual display string in selectrum--candidates-buffer we could propertize the newline character instead which should avoid this problem.

[clemera]

As mentioned in #484 highlighting can be off for candidates with padding due to scrolling (with extended highlighting). The fix should be the same as mentioned above.