Hacker News Reader

> The comment character in Git commit messages can be a problem when you insist on prepending your commits with some "id" and the id starts with `#`

https://git-scm.com/docs/git-commit#Documentation/git-commit...

See "commit cleanup".

There’s surprising layers to this. That the reporter in that thread says that git-commit will “happily” accept `#` in commit messages is half-true: it will accept it if you don’t edit the message since the `default` cleanup (that you linked to) will not remove comments if the message is given through things like `-m` and not an editing session. So `git commit -m'#something' is fine. But then try to do rebase and cherry-pick and whatever else later, maybe get a merge commit message with a commented "conflicted" files. Well it can get confusing.

> Maybe it was hard to use backtick in the 70’s and 80’s, but today[2] you could use backtick to start a string and a single quote to end it.

That's how quoting works by default in m4 and TeX, both defined in the 70s. Unfortunately Unicode retconned the ASCII apostrophe character ' to be a vertical line, maybe out of a misguided deference to Microsoft Windows, and now we all have to suffer the consequences. (Unless we're using Computer Modern fonts or other fonts that predate this error, such as VGA font ROM dumps.)

In the 70s and 80s, and into the current millennium on Unix, `x' did look like ‘x’, but now instead it looks like dogshit. Even if you are willing to require a custom font for readability, though, that doesn't solve the problem; you need some way to include an apostrophe in your quoted string!

As for end delimiters, C itself supports multicharacter literals, which are potentially useful for things like Macintosh type and creator codes, or FTP commands. Unfortunately, following the Unicode botch theme, the standard failed to define an endianness or minimum width for them, so they're not very useful today. You can use them as enum values if you want to make your memory dumps easier to read in the debugger, and that's about it. I think Microsoft's compiler botched them so badly that even that's not an option if you need your code to run on it.

> Unfortunately Unicode retconned the ASCII apostrophe character ' to be a vertical line

Unicode does not precribe the appearance of characters. Although in the code chart¹ it says »neutral (vertical) glyph with mixed usage« (next to »apostrophe-quote« and »single quote«), font vendors have to deal with this mixed usage. And with Unicode the correct quotation marks have their own code points, making it unnecessary to design fonts where the ASCII apostrophe takes their form, but rendering all other uses pretty ugly.

I would regard using ` and ' as paired quotation marks as a hack from times when typographic expression was simply not possible with the character sets of the day.

_________

¹

    0027 ' APOSTROPHE
    = apostrophe-quote (1.0)
    = single quote
    = APL quote
    • neutral (vertical) glyph with mixed usage
    • 2019 ’ is preferred for apostrophe
    • preferred characters in English for paired quotation marks are 2018 ‘ & 2019 ’
    • 05F3 ׳ is preferred for geresh when writing Hebrew
    → 02B9 ʹ modifier letter prime
    → 02BC ʼ modifier letter apostrophe
    → 02C8 ˈ modifier letter vertical line
    → 0301 $́ combining acute accent
    → 030D $̍ combining vertical line above
    → 05F3 ׳ hebrew punctuation geresh
    → 2018 ‘ left single quotation mark
    → 2019 ’ right single quotation mark
    → 2032 ′ prime
    → A78C ꞌ latin small letter saltillo«

> That's how quoting works by default in m4 and TeX, both defined in the 70s.

Good point. And it was in m4[1] I saw that backtick+apostrophe syntax. I would have probably not thought of that possibility if I hadn’t seen it there.

[1] Probably on Wikipedia since I have never used it

> Unfortunately Unicode retconned the ASCII apostrophe character ' to be a vertical line, maybe out of a misguided deference to Microsoft Windows, and now we all have to suffer the consequences. (Unless we're using Computer Modern fonts or other fonts that predate this error, such as VGA font ROM dumps.)

I do think the vertical line looks subpar (and I don’t use it in prose). But most programmers don’t seem bothered by it. :|

> In the 70s and 80s, and into the current millennium on Unix, `x' did look like ‘x’, but now instead it looks like dogshit.

Emacs tries to render it like ‘x’ since it uses backtick+apostrophe for quotes. With some mixed results in my experience.

> Even if you are willing to require a custom font for readability, though, that doesn't solve the problem; you need some way to include an apostrophe in your quoted string!

Aha, I honestly didn’t even think that far. Seems a bit restrictive to not be able to use possessives and contractions in strings without escapes.

> As for end delimiters, C itself supports multicharacter literals, which are potentially useful for things like Macintosh type and creator codes, or FTP commands.

I should have made it clear that I was only considering C-likes and not C itself. A language from the C trigraph days can be excused. To a certain extent.

I'd forgotten about `' in Emacs documentation! That may be influenced by TeX.

C multicharacter literals are unrelated to trigraphs. Trigraphs were a mistake added many years later in the ANSI process.

This is an excellent document. I disagree with its normative conclusions, because I think being incompatible with ASCII, Unix, Emacs, and TeX is worse than being incompatible with ISO-8859-1, Microsoft Windows, and MacOS 9, but it is an excellent reference for the factual background.

The comment character is also configurable:

    git config core.commentchar <char>

This is helpful where you want to use use say, markdown to have tidily formatted commit messages make up your pull request body too.

I want to try to set it to `auto` and see what spicy things it comes up with.

There are no problems caused by using unary delimiters for strings, because using paired delimiters for strings doesn't solve the problems unary delimiters create.

By nature, strings contain arbitrary text. Paired delimiters have one virtue over unary: they nest, but this virtue is only evident when a syntax requires that they must nest, and this is not the case for strings. It's but a small victory to reduce the need for some sort of escaping, without eliminating it.

Of the bewildering variety of partial solutions to the dilemma, none fully satisfactory, I consider the `backtick quote' pairing among the worst. Aside from the aesthetic problems, which can be fixed with the right choice of font, the bare apostrophe is much more common in plain text than an unmatched double quote, and the convention does nothing to help.

This comes at the cost of losing a type of string, and backtick strings are well-used in many languages, including by you in your second paragraph. What we would get in return for this loss is, nothing, because `don't' is just as invalid as 'don't' and requires much the same solution. `This is `not worth it', you see', especially as languages like to treat strings as single tokens (many exceptions notwithstanding) and this introduces a push-down to that parse for, again, no appreciable benefit.

I do agree with you about C and character literals, however. The close quote isn't needed and always struck me as somewhat wasteful. 'a is cleaner, and reduces the odds of typing "a" when you mean 'a'.