Em dash is too short

[moubry]

Source Code Pro's em dash feels too short—like it’s more of an en dash.

This character is rarely (never?) used for programming. However, I use it in documentation blocks above code.

[pauldhunt]

@moubry please post some examples.

[frankrolf]

The width of the emdash is somewhat limited by the standard character width of 600 units.
Right now, the hyphen is 430 units wide, the endash is 440 units, the emdash 560.
Maybe there is a point about making the emdash flush to the left and right margin, Paul?

[krono]

Please don't :)
A minimal visible white between the preceding/following character and the emdash is (just in my opinion) increasing legibility and reducing the need of manual kerning.

For example, look at the emdash of the original Palatino and the one of the Linotype Palatino.

[frankrolf]

Hmm – are we really comparing the same kind of issue here?
Source Code Pro is a monospaced font for coding, that means that even the emdash needs to have the same width as all the other characters. I hope nobody will go in and manually kern a monospaced text.
Palatino is a proportional font, and on top of that used in a totally different area.
In writing code, I can imagine few uses for the emdash, apart from making a horizontal line in your documentation string (but then again, we also have Box Drawing Characters which might be more appropriate for that).

[krono]

I understand your concern, you are probably right, most people won't use an emdash for coding.
I just don't think that the em dash should touch other characters, but there's clearly more expertise on your side.

However, it is still difficult to discern the “three dashes” (-, –, —) easily, but this is not limited to source code pro:

[pauldhunt]

this problem is a bit tricky for several reasons: firstly because this is a monospaced font i only have 60% of the full em to work with (each glyph is 600 em units wide). This already forces the em dash to be much narrower than it would be in a proportional font. Secondly for coding the hyphen for coding has been made to match the design of the minus symbol and the mathematical characters have been designed to harmonize with the size and weight of the other numerical glyphs.

I will go ahead and make the em dashes the full width of 600 em to make it more distinct from from the en dash, but there will still be some confusion between endash and hyphen, unless you use the stylistic set with typographic alternates that substitutes a much shorter hyphen for the default form.

If you have further suggestions, I would love to hear your proposed solutions.

[moubry]

Sounds great.

[quicknir]

@pauldhunt Hi, realize I'm coming to this quite a bit after the fact. Could you make the dash shorter then? I know this will sound absurd, but: I just wasted something like a full day trouble-shooting a Nagios server. The culprit turned out to be that I had copied and pasted text from somewhere, and that text had a typo in it, such that I ended up with an en dash instead of a regular dash for a command line command. I've had to switch away from this font in the console for the time being.

[pauldhunt]

@quicknir i need unicode values for what you are calling 'en dash' and 'regular dash'.

[kenlunde]

My guess is U+2013 (EN DASH) and U+002D (HYPHEN-MINUS).

[quicknir]

En dash in UTF 8 is 0xE2 0x80 0x93, or U+2013 if you prefer. Here it is: –. As for dash, I simply mean the ascii character on your keyboard: -. It seems to have the technical name: hyphen-minus, and have code 0x2D, or U+002D. As you can see, these are plainly distinguishable in the font that github uses. In Source Code Pro they are nearly (or perhaps totally) indistinguishable.

[quicknir]

@kenlunde Well played!

[pauldhunt]

@quicknir i don’t think i will change the default shape of the hyphen-minus to suit your personal usage. this is a difficult issue to try to address as several competing factors come in to play. firstly you have the requirement that all characters must have the same width, which results in smallish em and en dashes. also, for coding fonts the preference for the hyphen-minus is that it should, in fact, be the same design as the minus, which needs to be rather large to fit in with the other mathematical symbols. this results in an en dash and a hyphen that often look quite similar in size, unless the en dash is made to be the same size as the em dash. it is not fair to compare these characters to a normal font (such as the one GitHub uses for text) as they are not subject to these requirements. it seems the only reasonable option is to make the en dash indistinguishable from the em dash, but i’m not sure i want to do that either. unfortunately, all designs must make compromises and if the set of compromises I have made in SCP make it unusable for your purposes, then I will in no means be hurt by your using another font. of course you can always make a branch of this project that does exactly what you need it to do. best regards.

[kenlunde]

@quicknir: @pauldhunt has spoken—in written form—very wisely. Also, what is important is using the correct character (aka Unicode code point) regardless of how a particular font displays it using its glyphs.

[quicknir]

@pauldhunt If I can try one appeal: When would the difference between an em dash and an en dash matter in programming? No mainstream programming language uses em dash or en dash as legal characters that I'm aware of. Surely for a language designed primarily for programming it is more useful to distinguish a legal characters from two likely illegal characters, than to risk confusing legal and illegal characters. Instead of hyphen/en/em being 430/440/600 which it seems is now the case, could have 430/550/600 so that the en is closer to the em than to the hyphen.

[BatmanAoD]

According to the Unicode standard, the em-dash has ambiguous width. Despite only supporting monospace text, Vim and NeoVim permit such ambiguous-width characters to occupy two columns: https://neovim.io/doc/user/options.html#'ambiwidth'

Why not permit the actual dash character in the font to be two character widths, and let the application using the font decide whether to "squish" it into one column or not?

[kenlunde]

Apologies for poking a stick into a proverbial hornets' nest, but another idea is to use the current glyph for U+2014 as a placeholder, then use the 'ccmp' (Glyph Composition/Decomposition) GSUB feature to decompose uni2014 into two instances of uni2013. This gives the desired result (occupying two columns) while preserving the monospaced nature of the glyphs.

[BatmanAoD]

In response to my earlier comment: upon further experimentation, it seems that Vim and NeoVim actually don't permit a wider-than-character-width dash character.

Not knowing much of anything about fonts, though, @kenlunde's suggestion sounds promising.