Re: [PATCH v2 16/16] config: allow multi-byte core.commentChar
- From
Kristoffer Haugsbakk <code@khaugsbakk.name>
- Date
- Mar 13, 2024, 18:23 UTC
- Message-ID
- <0426f7bf-6032-4fc7-886c-c4278c6e105b@app.fastmail.com>
- In-Reply-To
- <20240312091750.GP95609@coredump.intra.peff.net>
Thanks for your work on this. Now I can use dingbats as my comment char.
On Tue, Mar 12, 2024, at 10:17, Jeff King wrote:
Show 13 quoted lines
> diff --git a/Documentation/config/core.txt > b/Documentation/config/core.txt > index 0e8c2832bf..c86b8c8408 100644 > --- a/Documentation/config/core.txt > +++ b/Documentation/config/core.txt > @@ -523,7 +523,9 @@ core.commentChar:: > Commands such as `commit` and `tag` that let you edit > messages consider a line that begins with this character > commented, and removes them after the editor returns > - (default '#'). > + (default '#'). Note that this option can take values larger than > + a byte (whether a single multi-byte character, or you > + could even go wild with a multi-character sequence).
I don’t know if this expanded description focuses a bit much on the history of the change[1] or if it is intentionally indirect about this char-is-really-a-string behavior as a sort of easter egg.[2]
Maybe it could be more directly stated like:
“ Note that this variable can in fact be a string like `foo`; it
doesn’t have to be a single character.(Hopefully UTF-8 is implied by “foo”. Or else “føø”.)
Terms like “a byte” and “multi-byte characters” seem a bit too technical in this context when you can just say “string”.
† 1: (1) What’s a “char”, is it ASCII? (2) It’s ASCII but could in
principle be made multi-byte (3) And also a multi-byte *string*,
right? (4) …
† 2: In five years: (1) How come this Git tutorial’s commit message
template has `(commit)` as the ignore-these-lines marker? How did he
abuse “comment char” to make a long string? (2) Actually…❦ Please enter the email reply. Lines starting with '❦' will be ignored, ❦ and an empty message aborts the sendout.
-- Kristoffer Haugsbakk