On Tue, 2015-03-31 at 09:19 +0200, Matthias Andree wrote: > I am concerned this will cause misformattings and inability to search > for options with leading dashes on some systems - I don't recall > versions, but I do know that some systems used some sort of Unicode > (soft?) hyphen for a simple non-escaped MINUS character (ASCII 0x2B).
cf. https://bugzilla.redhat.com/show_bug.cgi?id=1173619 I'm not sure there *is* a right answer. Groff will interpret a bare '- ' as a hyphen, and may render it in output as U+2010 HYPHEN. It will interpret an escaped '\-' as a minus sign, and may render it in output as U+2212 MINUS SIGN. I'm not aware of any way to actually *tell* groff that we want the output to be a U+002D HYPHEN-MINUS. Either way, we rely on undefined behaviour of the output drivers which may vary from system to system. Basically, I think groff is just broken. There is a thread at http://lists.gnu.org/archive/html/groff/2015-01/threads.html which I've just discovered, but I'm not sure I can see a conclusion there that I understand. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
