4 ms·

Meanwhile NeoVim doesn’t syntax highlight my commit message properly if I have messed with "commit cleanup" enough. The comment character in Git commit message

Meanwhile NeoVim doesn’t syntax highlight my commit message properly if I have messed with "commit cleanup" enough. 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 `#`. One suggestion was to allow backslash escapes in commit messages since that makes sense to a computer scientist.[1] But looking at all of this lexical stuff I wonder if makes-sense-to-computer-scientist is a good goal. They invented the problem of using a uniform delimiter for strings and then had to solve their own problem. 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. What do C-like programming languages use single quotes for? To quote characters. Why do you need to quote characters? I’ve never seen a literal character which needed an "end character" marker. Raw strings would still be useful but you wouldn’t need raw strings just to do a very basic thing like make a string which has typewriter quotes in it. Of course this was for C-like languages. Don’t even get me started on shell and related languages where basically everything is a string and you have to make a single-quote/double-quote battle plan before doing anything slightly nested. [1] https://lore.kernel.org/git/vpq3808p40o.fsf@anie.imag.fr/ https://lore.kernel.org/git/vpq3808p40o.fsf@anie.imag.fr/ [2] Notwithstanding us Europeans that use a dead-key keyboard layout where you have to type twice to get one measly backtick (not that I use those)

deleted 2y ago
[deleted]
pwdisswordfishz 2y ago
> 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.txt---cleanupltmodegt https://git-scm.com/docs/git-commit#Documentation/git-commit...
- keybored 2y ago
  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.
kragen 2y ago
> 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.
- ygra 2y ago
  > 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«
shawa_a_a 2y ago
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.
- keybored 2y ago
  I want to try to set it to `auto` and see what spicy things it comes up with.
samatman 2y ago
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'.

deleted 2y ago

[deleted]

pwdisswordfishz 2y ago

> 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.txt---cleanupltmodegt https://git-scm.com/docs/git-commit#Documentation/git-commit...

keybored 2y ago
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.

kragen 2y ago

> 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.

ygra 2y ago
> 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«

shawa_a_a 2y ago

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.

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

samatman 2y ago

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'.