On Wed, Mar 13, 2024 at 07:23:25PM +0100, Kristoffer Haugsbakk wrote:

Thanks for your work on this. Now I can use dingbats as my comment char.

Truly we have entered a golden age of technology. ;)

quoted

@@ -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]

Mostly I was worried that people would take "char" in the name to assume
it could only be a single byte (I had originally even started the new
sentence with "Despite the word 'char' in the name, this option
can..."). And that is not just history, but a name we are stuck with
forever[1].

Certainly "char" is an ambiguous term, though. I didn't mean to leave
char-is-a-string as an easter egg; that's what I meant by
"multi-character sequence". Certainly "string" is a shorter way of
saying that. ;) But I wasn't sure its meaning would be obvious without
the word "multi-character". Giving an example as you suggested does
help that.

That said...

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.

I actually do think the "string" nature is mostly uninteresting, and I'd
be OK leaving it as an easter egg. What your suggestion doesn't say is
that multi-byte characters are OK. But if we think people will just
assume that in a modern UTF-8 world, then maybe we don't need to say
anything at all?

(Hopefully UTF-8 is implied by “foo”. Or else “føø”.)

It actually does not have to be UTF-8. If you use an alternate encoding
in your editor (and probably set i18n.commitEncoding to match), I think
everything might just work. (Though to be clear, I think anybody using
non-UTF8 in 2024 deserves our pity either for being crazy or for being
stuck working on an antiquated system).

-Peff