4 ms·

Have you tried this lately? On a Debian Jessie machine using the en_US.UTF-8 locale, I encountered no problems doing this, though I picked œ instead of ö. I d

by jepler 11y ago

Have you tried this lately? On a Debian Jessie machine using the en_US.UTF-8 locale, I encountered no problems doing this, though I picked œ instead of ö. I did have a little bit of pain from git (git status showed \305\223 for œ) until I did "git config core.quotepath false". Not sure how this'll come through on ycombinator, so it's also on a pastebin for 24 hours: https://paste.debian.net/311370/ https://paste.debian.net/311370/ ~$ cd src ~/src$ mkdir œuvre ~/src$ cd œuvre ~/src/œuvre$ printf '#include <stdio.h>\nint main() {puts("hello œuvre");}\n' > œuvre.c ~/src/œuvre$ g++ œuvre.c -o œuvre ~/src/œuvre$ ./œuvre hello œuvre

simoncion 11y ago
I can also confirm success when compiling a file with a path "ömlaut/asdf.cpp". $ g++ --version | head -n 1 g++ (Gentoo Hardened 4.9.3 p1.1, pie-0.6.2) 4.9.3 $ uname -r -m 4.1.6-hardened i686 $ echo $LANG en_US.UTF-8 $ bash --version | head -n 1 GNU bash, version 4.3.42(1)-release (i686-pc-linux-gnu)
eridius 11y ago
That's a bit different. Presumably you're running this in a terminal emulator. Terminal emulators (and programmers editors), if they're set to a monospace font, operate on a grid. For characters in the selected monospace font this is just like normal font rendering, but when fallback fonts are used, it still uses the layout from the original monospace font (i.e. the grid) instead of the layout from the fallback font. This means that the fallback font rendering doesn't screw with the columns. Naturally there's still the issue of properly identifying double-wide characters. But as long as you can correctly identify them (and for the ambiguous characters it generally treats them all the same, either as narrow or as wide depending on the software in question), you can simply render them with 2 cells instead of 1, and everything remains lined up. But the article here was showing monospaced text in a web browser, and a web browser doesn't do any of this (nor a rich text editor). Font fallback usually attempts to maintain properties like monospacing, but the fallback font may still have different metrics, meaning it won't line up with the monospaced text from the source font (and depending on the fonts available, if you have no monospaced font with asian glyphs it would have to fall back to a non-monospaced font). I suspect what's going on with the locale stuff here is simply that the locale affects the fallback list, and it ends up picking a different font that happens to have the right metrics to line up. But I can't say for certain that this is the explanation.
- deleted 11y ago
  [deleted]
  - eridius 11y ago
    How strange. When I read jepler's comment it actually appeared as a top-level comment instead of a reply, which is why I assumed his terminal commands were intended to represent a rendering error, not a GCC error. But looking at it now, there is indeed a parent comment. Also, your first line there was quite reasonable, but the footnote is incredibly patronizing. I did not appreciate it in the slightest.
    - deleted 11y ago
      [deleted]
    - jepler 11y ago
      I apologize for the misunderstanding. I also didn't intend to sound patronizing to anyone; I wanted to show Kenji exactly what I was doing in case it was helpful to him or encouraged him to try naming his projects with non-ASCII characters again.
      - eridius 11y ago
        You weren't patronizing. It was another comment that has since been deleted. The confusion was I misinterpreted your comment because I thought it was a top-level comment and so I lost the context (I believe it was a rendering bug in the beta version of Safari I was using).

by jepler 11y ago

simoncion 11y ago

I can also confirm success when compiling a file with a path "ömlaut/asdf.cpp". $ g++ --version | head -n 1 g++ (Gentoo Hardened 4.9.3 p1.1, pie-0.6.2) 4.9.3 $ uname -r -m 4.1.6-hardened i686 $ echo $LANG en_US.UTF-8 $ bash --version | head -n 1 GNU bash, version 4.3.42(1)-release (i686-pc-linux-gnu)

eridius 11y ago

That's a bit different. Presumably you're running this in a terminal emulator. Terminal emulators (and programmers editors), if they're set to a monospace font, operate on a grid. For characters in the selected monospace font this is just like normal font rendering, but when fallback fonts are used, it still uses the layout from the original monospace font (i.e. the grid) instead of the layout from the fallback font. This means that the fallback font rendering doesn't screw with the columns. Naturally there's still the issue of properly identifying double-wide characters. But as long as you can correctly identify them (and for the ambiguous characters it generally treats them all the same, either as narrow or as wide depending on the software in question), you can simply render them with 2 cells instead of 1, and everything remains lined up. But the article here was showing monospaced text in a web browser, and a web browser doesn't do any of this (nor a rich text editor). Font fallback usually attempts to maintain properties like monospacing, but the fallback font may still have different metrics, meaning it won't line up with the monospaced text from the source font (and depending on the fonts available, if you have no monospaced font with asian glyphs it would have to fall back to a non-monospaced font). I suspect what's going on with the locale stuff here is simply that the locale affects the fallback list, and it ends up picking a different font that happens to have the right metrics to line up. But I can't say for certain that this is the explanation.

deleted 11y ago
[deleted]
- eridius 11y ago
  How strange. When I read jepler's comment it actually appeared as a top-level comment instead of a reply, which is why I assumed his terminal commands were intended to represent a rendering error, not a GCC error. But looking at it now, there is indeed a parent comment. Also, your first line there was quite reasonable, but the footnote is incredibly patronizing. I did not appreciate it in the slightest.
  - deleted 11y ago
    [deleted]
  - jepler 11y ago
    I apologize for the misunderstanding. I also didn't intend to sound patronizing to anyone; I wanted to show Kenji exactly what I was doing in case it was helpful to him or encouraged him to try naming his projects with non-ASCII characters again.
    - eridius 11y ago
      You weren't patronizing. It was another comment that has since been deleted. The confusion was I misinterpreted your comment because I thought it was a top-level comment and so I lost the context (I believe it was a rendering bug in the beta version of Safari I was using).