Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
fish_config prompt rendering is wrong #2924
Consider the preview for the Terlar theme:
On my terminal it actually renders like this:
There are issues:
A PR for 1 is incoming. 2 is caused because that color changes depending on exit status... and for some reason that's always not 0 in the demonstrations I guess.
added a commit
Apr 10, 2016
referenced this issue
Apr 10, 2016
In this case the ugly glyph is caused by the webapp simply using "Courier New"1 as the font for everything. Since the glyph is not present in Courier New the browser is using it's preferred fallback for that glyph, Apple Color Emoji. The fix with a better font list has the side-effect of making the webapp generally look nicer. Who the hell uses Courier New on a terminal? (Or generally likes it?
The color issue isn't that it needs to match my color setting, I'm not referring to (hard to see) dark blue asterisk being a different shade of blue, but the "➤" on the new line not being white. This one is caused because that color changes depending on exist status and I guess something failed internally before it generated the ANSI for that.
: it was actually using Courier New with a fallback of "monospace" which will use the browser's set monospace... which in most browsers is actually Courier or Courier New.
Regardless of the Courier (New) font, AFAICT, lots of front-end devs love those colorful emoji.
… Ah, emoji is not displaying well (#2199), so using single-width chars could be a saner default.
Huh, I knew that but I assumed this was a webconfig bug and that prompt author couldn't have intended for the color lightning bolt to come through. But I could be mistaken! I don't keep up with the times.
Obviously, after this change, a glyph only available in Apple Color Emoji will still show a color emoji glyph in the preview. On a Mac the glyph substitution works apparently the same way in Terminal.app as it does in webkit (crazy, but true, leads to no fun when a variable width substitution is picked) - so I think after this change it should still be more likely to be the glyph they'll see later.