Support SF Symbols in the same way as emojize

[jmjordan]

I really like the look of SF Symbols compared to emoji. I would like to add them to my plugin the same way you do using the emojize feature. It's possible to paste the SF Symbol into your output script, but this only works if you have the SF Symbols app installed and not all editors can display them.

Proposal:
Add support for SF Symbols using a similar mechanism to emojize=true

Possible solution:
Add an SF symbol to plugin output by using its system name as a token, eg. :square.and.arrow.up:.
App would replace occurrences of these tokens with an SF Symbol if symbolize=true

[melonamin]

We already have it in a form of sfimage=... Have you tried that?

[jmjordan]

Yes, that works great, but it only works for adding symbols to the beginning of a line. I'd like to be able to use them throughout a line of text as well.

[melonamin]

Quick take, this:

#!/bin/bash
echo "Test Symbols :sun.min.fill: :sun.max.fill: :cloud.snow.fill: :eyedropper:"
echo "---"
echo "Test Symbols :sun.min.fill: :sun.max.fill: :cloud.snow.fill:"

Becomes this:

Kind of working:

• :sun.max.fill: :cloud.snow.fill: are colored probably because they support coloring.
• :sun.min.fill: :eyedropper: should adopt text color, but for some reason are black in the menu bar and invisible in the menu

[jmjordan]

I was able to make the icons white by embedding them into a NSTextAttachmentCell but that breaks the layout. I'm worried its going to require implementing a custom NSTextAttachmentCellProtocol.

extension NSTextAttachment {
    static func centeredImage(with image: NSImage, and
                                            font: NSFont) -> NSTextAttachment {
        let imageAttachment = NSTextAttachment()
        imageAttachment.bounds = CGRect(x: 0, y: (font.capHeight - image.size.height).rounded() / 2, width: image.size.width, height: image.size.height)
//        imageAttachment.image = image
        let cell = NSTextAttachmentCell(imageCell: image)
        imageAttachment.attachmentCell = cell
        return imageAttachment
    }
}

[melonamin]

I have no idea what I'm doing, but this seems to be working 🤔

#!/bin/bash
echo "Test :sun.max: :cloud.fill: :gamecontroller.fill: :bookmark: :sun.dust:"
echo "---"
echo "Test :bookmark:"
echo "Test :sun.max:"

[jmjordan]

That looks great!

[jasonsnell]

I'm using this in the new beta and it works, but I've noticed a color mismatch. I'm using Big Sur and of course it dynamically chooses menu bar text color (black or white) based on the contents of the wallpaper. I'm in a mode where all the text is white, but the SFsymbol, which appeared white when using the old method, now displays as black with this method. (The text I've added after the SFsymbol is white!)

More broadly--and forgive me if this is being addressed elsewhere, I didn't see it--I feel like there needs to be a way to deal with Big Sur dynamically changing the text in the menu bar. In Catalina I could just detect the existence of Dark Mode and adjust text colors appropriately, but I don't seem to be able to do that in Big Sur?

[jasonsnell]

Actually I have to add another data point! :smoke: was black but :wind: shows as white. WHAT. Anyway, something weird there.

[jasonsnell]

Another issue. there is a namespace collision between emoji code and SFsymbol code, so :house: renders as an emoji house. Should there be some other way to name SFSymbols so they don't collide with emojis?

[melonamin]

Actually I have to add another data point! :smoke: was black but :wind: shows as white. WHAT. Anyway, something weird there.

This was fixed after I published the beta, I referred to it in this thread ☝️ I will push another build this weekend, stay tuned.

Should there be some other way to name SFSymbols so they don't collide with emojis?

Let me think about that, meanwhile you can disable emoji rendering, this should give you SF Symbol.

[jmjordan]

We could use a different syntax for SFSymbols to avoid collisions. <house> or {house} perhaps?

[melonamin]

I don't know, for some reason I like that we offer a uniform syntax for these two. Should we support having emoji and SF Symbols in one line at the same time? It looks quite weird.

[jmjordan]

That's fair. I don't see why anyone would want to use both SFSymbols and emoji on the same line. If they wanted to they could always use the actual emoji instead of the decoded syntax.

[jasonsnell]

I don't know, for some reason I like that we offer a uniform syntax for these two.

Okay, but if I do :house: I need to explicitly set the mode to emoji for that line because it's got an emoji counterpart... that seems not great? I'm not really talking about mixing so much as searching for relevant sfsymbols only to find that some of them collide with emojis... not great. Is there a way to force one or the other, or is it just "emojis win, use |symbolize=true if you don't like this"...

[jasonsnell]

If they wanted to they could always use the actual emoji instead of the decoded syntax.

This is actually what I've done with emojis up to now. Worked fine.

[melonamin]

Ok, this is how it works now:

#!/bin/bash
echo "Test :smoke: :wind: :house:  | emojize=false"

Emoji wins, but you can explicitly disable it. We can switch to "SF Symbols wins" mode, if you think it is a more sensible default. Either way you can control which one will be used.

Am I missing something?

[jmjordan]

I guess I was thinking that if you enabled symbolize it would automatically disable emojize.

[melonamin]

I guess I was thinking that if you enabled symbolize it would automatically disable emojize.

Sorry, I think I just confused everyone:

• emoji enabled by default
• SF Symbols disabled by default
• enabling SF Symbol doesn't disable emoji

[jasonsnell]

I'm definitely confused, but as long as there's a way to turn on symbols and turn off emojis so that collisions it'll work.

Still might be easier to just keep them both on with separate reference methods, though. So I could do :house: and :symbol:house: for example.

[jasonsnell]

The real issue is I'm not 100% sure why we need emoji shortcuts since files will accept emojis as characters? Shortcuts are nice but they're a convenience since you can just drop in the emoji, whereas there's no other way to reference SFSymbols. I guess that would be my argument for giving SFSymbols priority, but the important thing is to just make a decision. 😉

[melonamin]

New behavior: SF Symbols have priority, emoji will work only if SF Symbols explicitly disabled.