Post by @rl_dane@polymaths.social
🍵 
Minor quibble, but for the life of me, I cannot figure out why I cannot produce a valid em dash ("—", a.k.a. 0xe28094 or U+2014) on #NetBSD, except with mate-terminal. I've tried (u)xterm, alacritty, and lxterminal, and they all either give me a junk character, or an en-dash followed by a hyphen. When I press the compose key and hit the hyphen three times, it immediately attempts to produce an en-dash after the first two hyphen presses, and then gives me a plain hyphen on top of it.
I've checked the Compose file, and it's set up correctly (as far as I can tell).
I think #OpenBSD has the exact same problem, but I haven't tried installing mate-terminal to find out.
cc: @gumnos
@rl_dane Here on Linux, /usr/share/X11/locale/en_US.UTF-8/Compose has EN DASH as <minus> <minus> <period> and EM DASH as <minus> <minus> <minus>.
If you are using a Compose file with EN DASH as just <minus> <minus>, that probably confuses Compose implementations that can't handle when one compose sequence is a prefix of another.
I believe GTK does not use the standard X11 compose implementation (in particular, GTK does not support mappings where the right-hand-side contains multiple code points) so if you've found a difference between GTK-based apps and other apps, that might be why.
🍵
Hmm, should I just remove the en dash from the Compose file on my (Net|Open)BSD boxen, then?
@rl_dane I'm guessing it's probably not a thing you type often. If it's coming from your personal ~/.Xcompose file rather than some system-wide file, it's probably easiest just to delete it (or at least comment it out).
🍵
No, it's the default Compose file for en_US.UTF-8. And I do use it a good bit! XD
🍵
@rl_dane@polymaths.social @robinp@mastodon.social @gumnos@bsd.cafe next they'll be taking away our emoji-marker lists 😢
(I shall not be sad)
🍵
lol you know I actually maintain my own fork of rofi-emoji? ;)
https://codeberg.org/rldane/scripts/src/branch/main/emoji-picker
P.S., sorry, it was forked from fuzzel-emoji. rofi-emoji seems to be significantly different in design. Oh, yeah, it's written in C. Totally different.
🍵
Elegant! I'll have to see if you have any emojis I don't have yet. ;)
I've got a lot added to mine, including unicode block characters and box drawing characters, and non-emoji symbols like ™ ® ÷ ±, etc.
🍵
@amin@polymaths.social @rl_dane@polymaths.social @robinp@mastodon.social @gumnos@bsd.cafe
Well I actually meant this sort of thing
lists with
🚀 markers as
🌭 emojis
And while we're at it...
🌟 Emojis in Headers 🌟
🍵
en.US.UTF-8. I'm not on that box right now, but I can troubleshoot more later. I might try spinning up a new account just to see if it's something with my config/env/profile that's causing a problem.
🍵
Ok, I created a brand new user and logged into it, stock everything.
I set up the compose key with setxkbmap -option caps:swapescape -option compose:sclk
The command I'm typing into each terminal is printf '<scroll lock>,<minus>,<minus>,<minus>' |hexdump -C
uxterm displays the em dash just fine
Alacritty displays \U+00C2\U+00AD-, and hexdump -C reports c2 ad 2d instead of e2 80 94
lxterminal just displays ?, and hexdump -C reports 3f
mate-terminal shows \U+00E2\U+0080\U+0094, but hexdump -C reports e2 80 94 (correct)
locale on this stock/default account:
LANG=""
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=""
locale on my regular account:
LANG="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="C"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=""
On my regular account, uxterm gives me 0xad2d when I press compose,minus,minus,minus,
Alacritty gives me 0xc2ad2d
lxterminal just gives me 0x3f
and mate-terminal gives me the correct 0xe28094
🍵
In my ~/.xsession file I have
export QT_IM_MODULE=xim
export GTK_IM_MODULE=xim
which neighboring comments suggest were added to make certain programs aware of the X input-mode (I *think* that's what the "xim" means). So I don't know if one or the other of those before launching $TERMINAL would give you better success. Also, does it (still?) work in plain ol' xterm vs the other more exotic terminals? I tested again in my fairly stock OpenBSD+xterm and got the expected results:
$ hexdump -C <<EOF
em-dash: —
en-dash: –
shy:
EOF
00000000 65 6d 2d 64 61 73 68 3a 20 e2 80 94 0a 65 6e 2d |em-dash: ....en-|
00000010 64 61 73 68 3a 20 e2 80 93 0a 73 68 79 3a 20 c2 |dash: ....shy: .|
00000020 ad 0a |..|
00000022
(to test NetBSD, I'd have to swap drives on that OpenBSD junker laptop to put the NetBSD drive in 😆)
🍵
It sounds like your current terminal setup is already broken, so 🤷
And yeah, see you at lunch today…if the problem-machine is a laptop, feel free to drag it along and we can hack-and-snack. 😆
🍵
It is, but it's a clunker, and I don't have it with me right now. XD