Earlier quoted context omitted.
I find these a visual noise. What can be achieved with a subheading "Bug fixes", "Features" etc. is repeated in all lines.
Why the emojis are visual noise but "Bug Fix" wouldn't be?
Color attracts the eye.
Terminal Support for Emoji
111–120 of 129 posts
Re: Terminal Support for Emoji
#112Earlier quoted context omitted.
> (How do you scribble "family of three: mom, father, daughter" without any emojis?) Why you need to? We dealt without hieroglyphs just fine in communication.
The tahitans can deal with communication just fine with only 13 letters, so I guess we could probably trim the letters b, c, d and g out of unicode too. With enough optimisation we might just be able to communicate with just a boolean-based language. (i.e. why limit written communication rather than make it richer)
That you can take something too far in one direction doesn't give reason or explanation for anything except "don't take it too far in that direction". There are probably good explanations why not to take things infinitely far in either direction but they don't really help explain where the line should be drawn.
I think the actual argument here is encoding of seemingly arbitrary colored pictorial combinations overcomplicates character encoding. If you want to display a colored drawing of an arbitrary family SVG is already a thing but if you want to textually encode an arbitrary family you should use characters in your language not expect the text encoding to pick up more arbitrary drawings.
To me, using Emoji was probably a great way to force developer's hands on supporting certain encoding features more complicated languages use even in cases they only wanted to support latin text. That said, this job is already done. We don't need to continue putting everything into ever more complex pictorial encodings via Unicode for the rest of time.
Re: Terminal Support for Emoji
#113Earlier quoted context omitted.
I think emojis in commit messages are very overrated. But emojis are great in informal communication when you want to compensate for the fact that your words are completely divorced from inflection, tone, and body language.
I once had a colleague who started every commit message with an emoji. It became tiring very quickly. Still, the odd facepalm, bug or bomb once in a while doesn't really do any harm. I use the robot emoji in my ~/.mailmap so I can easily identify bot commits (dependabot, snykbot etc) when scanning through commit logs locally.
Absolutely, emoji used spontaneously are great. When they are used as qualifiers or attributes constantly, it becomes just as bad as typing "feat:" or "chore:" or something similar in front of every commit message.
Re: Terminal Support for Emoji
#114Interestingly, Microsoft Terminal renders all of these correctly!
Microsoft Terminal is actually pretty good. I was surprised when I configured git bash as my main shell there and when opening it via right-click in Explorer, it correctly translated the path and opened the shell in the correct folder.
I didn't like Windows Terminal when I used it over the last few months at the last $job because my choices of software were limited and it was better than the Windows Console.
There seems to be no way to make the cursor clear and visible on all background colours that I used for CLI and text editing. I ended up having to use a difficult-to-see 50% grey cursor, as a compromise that was better than losing the cursor completely sometimes.
It wouldn't send Control-Space or Control-@ from the keyboard (they are the same character, ^@ aka NUL), which is the key used to set the editing mark in Emacs so used a lot. No key combination is mapped to that character in Windows Terminal, and I couldn't find a way to customise it to do so either. Historical real terminals like the VT100, and of course xterm etc, always did so, which is why it's an essential key in some terminal applications. I compromised by binding Control-] to set-mark-command in Emacs but this was annoying when switching between devices.
Finally, line drawing characters, boxes, progress bar characters and such had ugly gaps, as though line height was incorrect for them.
All of these seem to work fine in every other terminal emulator I've used.
Re: Terminal Support for Emoji
#115I never have understood the push to emojify everything. But commit messages, options in menus, status outputs, you name it: I think we'd be better off leaving it in plain ASCII (or Unicode if your language needs that, just as long as you don't dip into the emoji). Emoji are quite nice for messaging people and occasionally some of the more generic ones can be useful for status indicators (think the red and green circl…
> I think we'd be better off leaving it in plain ASCII (or Unicode if your language needs that, just as long as you don't dip into the emoji). Why such a distinction? Symbols are very useful in commit messages because they can convey a message at a glance that would otherwise require parsing the message. A big, visible symbol for bug fixes and another one for new features makes a lot of sense. Once we’re there, how i…
> Symbols are very useful in commit messages because they can convey a message at a glance that would otherwise require parsing the message.
A good commit message doesn't need symbols to tell you what it is doing. (And no, I don't write perfect commit messages.)
> Once we’re there, how is it better to use things like Chinese characters rather than emojis?
Because there are quite a lot of people in this world who speak Chinese but not English, while nobody speaks only emoji.
> On balance, it is better that they are supported properly even if you personally dislike them.
To be clear, I'm not against emoji or Unicode in general. I just dislike the way they seem to be showing up in commit messages and the like as attributes.
Re: Terminal Support for Emoji
#116Earlier quoted context omitted.
> How do you scribble "family of three: mom, father, daughter" without any emojis? Using nifty little things called jpegs.
How do you propose they get transmitted? In-band in the middle of text (good luck reading that with an unsupported editor), or through servers, necessitating NAT and all that good fun? Since the images can be arbitrary you also open yourself up to bugs in the parser. All around a much, much worse idea compared to text emojis.
> good luck reading that with an unsupported editor
You need a "supported editor" to display Unicode emojis too, as TFA shows. And supposedly it is quite hard. OTOH displaying jpegs is a solved problem.
Re: Terminal Support for Emoji
#117Earlier quoted context omitted.
How do you propose they get transmitted? In-band in the middle of text (good luck reading that with an unsupported editor), or through servers, necessitating NAT and all that good fun? Since the images can be arbitrary you also open yourself up to bugs in the parser. All around a much, much worse idea compared to text emojis.
> good luck reading that with an unsupported editor You need a "supported editor" to display Unicode emojis too, as TFA shows. And supposedly it is quite hard. OTOH displaying jpegs is a solved problem.
> You need a "supported editor" to display Unicode emojis too, as TFA shows.
Let's give this a try. This is roughly what a sentence with an emoji looks like in an unsupported editor:
hello [] world
(with [] being the well-known "placeholder" square). Now let's try the same with an emoji, I went with 16x16 to make this kind of bearable, but realistically you'd want at least 64x64:
hello data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAQABADAREAAhEBAxEB/8QAFwAAAwEAAAAAAAAAAAAAAAAAAAIICv/EABwQAAIDAQEBAQAAAAAAAAAAAAQFAgMGBwEIFP/EABoBAAEFAQAAAAAAAAAAAAAAAAACAwUGCAn/xAAhEQACAwEBAAICAwAAAAAAAAADBAECBQYHCBITFAAVFv/aAAwDAQACEQMRAD8A1xbv6+xizYBjaeOtvSMunT5XmVeTDaMAP1waXJyNft7FFlPoub9OHjK5gylJQmBICnfTMgi+6PJ31n5YubHpnY4S5H1eV89d3MumSj0TmCPdLhNmR0dDQNmtpM65HTrHjKxrGlSiY4JdczZL3ppUPljuLz2OdUaRNLYxkt119xdcp1qvKjcXzcyGqFquRYJq1YKGsNMNQSsFqCg6SYX6+xjPYGDZivWjpVnTYcr06vWBtFy/0qbSlPRsMTNtbb6VnPDSJSoYrfYqHIQxsqKIkUUX+nlHyybyPS+OwjkeZ5b0F3DzL5LvQubwsMu44FFB/PNotus45UjtB/tMehoUIpeb1XC0OhJDeWu7XPa5mqJD0cjGd3En011xHZ/RVK4fN04VGKpyMADaoSHiWlmfxRJLAuQf8hP6/wCB/SXGOkaDZ8hzrbo/P9m4cPaglrLqYUMzY1bMHRKs2rm7sSauQJTQgcNqyXkL2CyC+uZwRYNw5E5634bPnnYdjtF8WzPYuM7vo9DrQPL4mrodHyWlpkufUyT2wzhfpi2Nf9hMn1MvWZvFq0Na/wBrpyHYZHoGDgotdn/juj5vJTwzpuuZS+duLJCoBTRWtrhuuV2wxxRoNCCNF5mYggvrML8fcA+kuydHRbPryFxz3BZFumdXAs2PUzB9D4qbrnlCoCrpLwyxrewKVjCmN1q8ZetVTY0wNNKYVD0NeTeF39G7Pjdsfi+Z45xXBdCj1bDh8TUz+i67TziiPl5Qp3DnfJjjMKTtkn8K8zMfWtzVH9V9h2GN59z+8ir2Udl0nSZTeKuok7lsZ+Eu2Ei7WgxbICNcLlRkmq4bXIebxWZgYvvaf//Z world
Now, which one is more readable?
Re: Terminal Support for Emoji
#118Earlier quoted context omitted.
Interestingly (but commercially) the very popular Line app, which IMO has the best "stickers," lets you do something like this. https://en.wikipedia.org/wiki/Line_(software) If I buy a set of stickers (little animations, much more expressive than emojis) I can send them to anyone in chats, or I can send the set as a gift to that user; in the latter case, the user can add them to their library. Your library is the sta…
Well, as long as you can use these stickers in an in-line way. The graphic should be part of the sentence, not just an addition to it, although the latter should be possible too I guess.
You can’t, but there are a large set of built-in emoji-like inline graphics in addition to the normal emojis. Some of them quite good but the selection seems a bit random. They are privileged over keyboard emojis in that they pop up for selection when you type keywords. AFAIK users can’t create their own.
However, stickers have a culture of their own, and I don’t think it’s inferior to emojis, maybe it’s even better. You can express a lot in a sticker or two, without words, and quickly. And they’re not tiny ambiguous glyphs, they have the room they need.
So far in my Line experience I’m the only one using emojis (I should probably stop) because it seems like the standard is to use text to say specific things and use stickers to convey emotions.
I’m a foreigner and don’t have a million Line friends, but that’s how it looks to me.
Re: Terminal Support for Emoji
#119Earlier quoted context omitted.
Well, as long as you can use these stickers in an in-line way. The graphic should be part of the sentence, not just an addition to it, although the latter should be possible too I guess.
Interestingly, you can insert text to some stickers.
Oh, very interesting. Makes sense, since (mostly Japanese) text features in a lot of them. I’ll have to look for those.
Re: Terminal Support for Emoji
#120Earlier quoted context omitted.
> I think we'd be better off leaving it in plain ASCII (or Unicode if your language needs that, just as long as you don't dip into the emoji). Why such a distinction? Symbols are very useful in commit messages because they can convey a message at a glance that would otherwise require parsing the message. A big, visible symbol for bug fixes and another one for new features makes a lot of sense. Once we’re there, how i…
> Symbols are very useful in commit messages because they can convey a message at a glance that would otherwise require parsing the message. A good commit message doesn't need symbols to tell you what it is doing. (And no, I don't write perfect commit messages.) > Once we’re there, how is it better to use things like Chinese characters rather than emojis? Because there are quite a lot of people in this world who spea…
> Because there are quite a lot of people in this world who speak Chinese but not English, while nobody speaks only emoji.
And even more people using emojis. Fundamentally, as a native speaker of a European language, there is no meaningful distinction between using fancy image characters and fancy characters that look like symbols. The fact that someone somewhere is using them or not is not very relevant.
> To be clear, I'm not against emoji or Unicode in general. I just dislike the way they seem to be showing up in commit messages and the like as attributes.
Right, but then that’s something you solve by policing the commit messages in your projects. Not by policing how other people you’ll never meet express their ideas or emotions.