face conflict in README instructions with mouse highlight

[emacs-citar]

face conflict in README instructions with mouse highlight

[bdarcus]

I didn't notice because I never use the mouse with this :-)

I see this on both selectrum and vertico, now that I look.

Edit: I'm not that knowledgeable about Emacs faces.

PS - I opened a new issue, since it's orthogonal to the other one.

[bdarcus]

Actually, I just tested by setting selectrum-mouse-highlight to nil, but had no impact.

@clemera @minad - I see the same in both selectrum and vertico.

Basically, we want use a "dim" or "inactive" face on annotations, but when mousing over the candidates, you can see in the above screenshots what happens.

Is this expected, and if yes, is there a workaround?

If not, we can submit an issue.

This is the setting he is using:

(setq bibtex-actions-symbols
  `((pdf . (,(all-the-icons-icon-for-file "foo.pdf" :face 'all-the-icons-dred) .
            ,(all-the-icons-icon-for-file "foo.pdf" :face 'bibtex-actions-icon-dim)))
    (note . (,(all-the-icons-icon-for-file "foo.txt") .
            ,(all-the-icons-icon-for-file "foo.txt" :face 'bibtex-actions-icon-dim)))        
    (link . 
        (,(all-the-icons-faicon "external-link-square" :v-adjust 0.02 :face 'all-the-icons-dpurple) .
        ,(all-the-icons-faicon "external-link-square" :v-adjust 0.02 :face 'bibtex-actions-icon-dim)))))
;; Here we define a face to dim non 'active' icons, but preserve alignment
(defface bibtex-actions-icon-dim
    '((((background dark)) :foreground "#282c34")
     (((background light)) :foreground "#fafafa"))
     "Face for obscuring/dimming icons"
     :group 'all-the-icons-faces)

[minad]

I am not using the mouse, so this is low priority for me. I am also not using icons. But the screenshots look beautiful 👍 I like the work you are doing here!

[bdarcus]

I am not using the mouse, so this is low priority for me.

Me too. But does that suggest you think it's an issue with the completion systems?

I am also not using icons. But the screenshots look beautiful I like the work you are doing here!

Thanks! Inspired in part by your work, and help!

[apc]

I don't use the mouse either. So perhaps you can help me here. Is there a way of making it so the mouse doesn't, just by virtue of the mouse pointer being where it is, change the faces of anything? I don't have to do anything to the mouse for this to happen: if it so happens that the pointer was right above where a line in the mini buffer shows up, that line gets highlighted whether I like it or not.

[minad]

Me too. But does that suggest you think it's an issue with the completion systems?

Usually face issues are issues with the theme or with the Emacs display engine. Often the completion system doesn't have to do much with this.

[apc]

Ok, I guess mouse-highlight is the variable I didn’t know about?

[bdarcus]

Usually face issues are issues with the theme or with the Emacs display engine.

OK; good to know.

We're seeing the behavior on two different themes, including (on mine) modus-operandi, which I know has explicit support for selectrum and vertico.

In any case, @apc, you should probably take a look there first, if you want to sort this out?

[apc]

I'll keep looking. I tried the modus themes and the color change happens with all faces on the mini buffer. When the mouse is over a line, everything on the line is set to the same color as the default face. Also, it has nothing to do with all-the-icons: I'm using plain old propertize

(setq bibtex-actions-symbols
        `((pdf . (,(propertize "⌘" 'face `(:foreground ,(face-attribute 'default :foreground))) .
                  ,(propertize "⌘" 'face `(:foreground ,(face-attribute 'default :background)))))
          (note . (,(propertize "✎" 'face `(:foreground ,(face-attribute 'default :foreground))) .
                  ,(propertize "✎" 'face `(:foreground ,(face-attribute 'default :background)))))))

This is what it looks like, with modus-operandi, when the mouse isn't hovering over the line:

And this is what it looks like when the mouse is hovering (note that the color of selectrum-prescient-primary-highlight, for example, changes to the color of the default face when the mouse is over the entry.

But this doesn't seem to be related to bibtex-actions at all. Note the contrast below with something like consult-line, for example, again using modus-operandi:

The puzzling thing is that selectrum-prescient-mouse-highlight has all properties set to unspecified, so I don't know why it's changing the color of the text.

Face: selectrum-mouse-highlight (sample) (customize this face)

Documentation:
Face used for candidates during mouse hovering.

Defined in ‘selectrum.el’.


           Family: unspecified
          Foundry: unspecified
            Width: unspecified
           Height: unspecified
           Weight: unspecified
            Slant: unspecified
       Foreground: unspecified
DistantForeground: unspecified
       Background: unspecified
        Underline: t
         Overline: unspecified
   Strike-through: unspecified
              Box: unspecified
          Inverse: unspecified
          Stipple: unspecified
             Font: unspecified
          Fontset: unspecified
           Extend: unspecified
          Inherit: selectrum-current-candidate

[back]

You can close this (again!) as far as I'm concerned.

[apc]

FYI: this appears to be a known issue.

[bdarcus]

@apc - any chance you submitted a bug report to Emacs?

…

On Sun, Apr 18, 2021, 8:36 PM apc ***@***.***> wrote: FYI: this appears to be a known issue <radian-software/selectrum#508>. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAI3U56QR7QPXYID5KLJTTJN3HVANCNFSM43EGZAVQ> .

[apc]

No, I haven't. I don't think I understand overlays and faces and all that well enough to know if this would be a bug report or a feature request...

[bdarcus]

I don't think I understand overlays and faces and all that well enough to know if this would be a bug report

I'd call it a bug report, given what you turned up.

And it's easily reproducible, as you've demonstrated.