Umlaut issues on MacOS

[timorunge]

Which operating system does the issue occur on?

• I'm running MacOS 10.14.2
• I'm using Alacritty v.0.2.5 (rechecked with 0.2.4 as well)

Files and folders created in Finder seem to have a different way of storing names then the command line has (I took "Ä" in my example).

Alacritty has problems with displaying the ones which are created by the Finder / not via command line. This is not depending on the shell (tested with bash, zsh and fish) or the Font itself. Terminal.app and kitty have no problem with the display of the same.

Ways to reproduce:

cd ~/Desktop
osascript -e 'tell app "Finder" to make new folder with properties {name:"Ä"}'
for i in (ls) ; printf "\n$i\n\n" ; echo $i | hexdump ; end
rm -rf ~/Desktop/*
mkdir Ä
for i in (ls) ; printf "\n$i\n\n" ; echo $i | hexdump ; end

Alacritty
http://trash.timorunge.de/alacritty/Screenshot_2019-01-10_at_20.19.29.png (uploaded since uploads to GH are not working ATM)

Terminal
http://trash.timorunge.de/alacritty/Screenshot_2019-01-10_at_20.49.36.png (uploaded since uploads to GH are not working ATM)

[dm1try]

Alacritty has problems with displaying the ones which are created by the Finder / not via command line.

looks like something related to Unicode support; osascript uses Unicode16 under the hood, while the name encoded by the shell uses utf8.

might be related to #306

[timorunge]

Yeah, I was using osascript just as a reference to show the results of the different charsets.

[dm1try]

TLDR alacritty should be able to display Unicode text with different normalization forms.
the reproducible example could be simplified to:

echo "\u00c4"
echo "A\u0308"

btw, APFS is normalization-insensitive

[laktak]

I have the same issue under both MacOS and Arch with alacritty 0.5.0

[chrisduerr]

This is actually not a bug, Alacritty just doesn't do normalization and the fonts do not position the symbols correctly. So this is a font problem not an Alacritty problem. Normalization shouldn't be required.

[laktak]

@chrisduerr I have tried different fonts, but the issue is always the same.

I have set the font to the default listed in https://github.com/alacritty/alacritty/blob/master/alacritty.yml (monospace) but it has the problem as well.

What font are you using that shows the symbol correctly?

$ echo FAIL $'A\u0308'
FAIL Ä
$ echo OK $'\u00c4'
OK Ä

[chrisduerr]

Fira Mono.

[laktak]

@chrisduerr thank you! The output does look better (it's at least on the correct character) but it's not the same as the correct rendering:

If normalization is a font problem, is there a tool that can fix my font so it works with Alacritty?

[chrisduerr]

It's not supposed to be the same, if you want the same thing, don't use separate characters.

[laktak]

It's not supposed to be the same, if you want the same thing, don't use separate characters.

Not sure if you are having a bad day but that is not helpful.

It's not as if I am typing these myself, they show up in files and file names that are sent to me. FWIW they show up exactly the same in Firefox and elsewhere. Sorry for bothering you.

[chrisduerr]

If you want things normalized, then applications can normalize them. Alacritty just renders what the applications emit, which is perfectly fine. There's nothing wrong going on here, it just doesn't perform a step that is optional.

[tobx]

@chrisduerr You are right, but don't you think the normalization step should be included? It seems to be included in every other Terminal app (e.g. Terminal.app, Hyper, iTerm2)? At least with the same fonts they all render the characters correctly and with correctly I mean that if you buy a Mac (e.g. German) and create a file in Finder, then you want the name in the Terminal (e.g. with ls) to be displayed the same way as it was entered on the keyboard.

I understand that this is not exactly an Alacritty issue, but I am sure it will drive some users away when they cannot list directories correctly.

I totally understand if this is not top priority, too difficult to implement, etc., but calling it "perfectly fine" is at least from a user experience point not correct.

Anyway, I am not leaving Alacritty :)

[laktak]

@tobx you are commenting on a closed issue - the chances that your comment will be noticed are rather low in that case.

[tobx]

@laktak You might be right, but I rather prefer not to when there is already 2 closed issues for it.

[tobx]

@chrisduerr Hi, after using Alacritty for a few years now, I have to say, it is extremely fast. It boots faster than Kitty and even a little faster than the native macOS terminal. I am using exa as ls replacement and it reacts almost instantly. I tried Kitty again and I could not really live with the small delays compared to Alacritty.

I keep saying with many applications that I would prefer more performance and stability instead of all those new features. If this is what it takes, I am happy that Alacritty goes this way. We do not need a second Kitty and I am happy that everyone can choose between maximum performance and more features.

Also I read about how bad the macOS APFS unicode normalization is and I can understand that not every application wants to take care of that.

Thank you for Alacritty.