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. ;) > > @@ -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
