Hi Jan, Jan Stary wrote on Tue, Jul 11, 2017 at 11:50:01AM +0200: > Ingo Schwarze wrote:
>> Maybe mandoc should warn about the portability issue? Possibly, >> but i would have to understand what exactly is broken in groff, so >> what the permissible syntax is. Or even better, we should fix groff? >> That may be hard. > Would you please kindly bring it up on the groff list, > if you think groff should address this too? (I can do it, > but it would get more momentum comming from you.) No, i won't, and please don't. Groff has no maintainer, and all the people working on it are continuously overwhelmed with work. So such a bug report will not result in getting anything fixed, a bug report without a patch is nothing but noise and distraction on the list and even in the bugtracker. Of course, people who don't know how badly groff is pressed for manpower might still do it. But people who know better really shouldn't. Even when i send patches that are fixing simple bugs, unconcontroversial, small, and easy to verify, and that i have already tested according to OpenBSD quality standards, it is very hard to get them them into groff. It often takes months for someone to come round and commit them, even with occasional, non-intrusive reminders. In one case, it took about two years. I have been offered groff commit access, which would mitigate the problem, because with commit access, i would both commit my own patches that are obviously uncontroversial and commit good patches that now rot in the bugtracker. But the FSF required me to sign an FSF Copyright assignment contract according to Massachusetts Law that i deem illegal according to International Law (and also according to German Law) and that contains provisions that in some admittedly unlikely cases of neglect, i may become liable to pay damages to the FSF if i fail to comply with some of their legal rules. So that is two reasons why i feel unable and unwilling to sign that contract. The former groff maintainer, Werner Lemberg, asked the FSF Board of Directors to allow contributions from occasional contributors without a copyright assignment, simply covered by either a ISC-style license - which allows integration into a GPL project with no problems whatsoever - or a public domain dedication - which might also work, whichever of the two the FSF Directors and their lawyers prefer. Werner argued to the Board of Directors that allowing that was required for the viability of the project, to help the already very difficult task of acquiring urgently needed new contributors. He wasn't the first maintainer of a core GNU project to argue that way. The FSF Copyright Clerk wrote to me in January 2014, "We are going to look into allowing contributions with a license. This will take time as it is a policy change. Thank you for your patience." That is the last i heard about that matter so far. >> Note that the .Pq is *outside* the .Lk, so it is logical that the >> parentheses appear *outside* the display. > Ah, so is this being "outside of the display" > (meaning "outside of the kind-of-D1-line" here) > that introduces the line breaks? Yes. >> If you want the parentheses >> inside the display, you might feel tempted to write something like >> >> For more information about using ports, see >> The >> .Ox >> Ports System >> .Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) . >> For information about creating new ports, see >> the >> .Ox >> Porter's Handbook >> .Lk ( https://www.openbsd.org/faq/ports/ ) . >> >> But that also breaks with groff: >> >> For more information about using ports, see The OpenBSD Ports System >> https://www.openbsd.org/faq/faq15.html#Ports: (). For information about >> creating new ports, see the OpenBSD Porter's Handbook >> https://www.openbsd.org/faq/ports/: (). > It would also be semantically wrong, right? > The parentheses surely are not part of the link. Not necessarily semantically wrong, no. The mdoc(7) language uses a convention that leading opening and trailing closing delimiters found on the input line of many macros fall out of the logical scope of those macros, see the subsection "Delimiters" in the mdoc(7) manual for details. In mandoc, the .Lk macro already handles closing delimiters in an even more special way than most other macros: They fall out of the (semantic) link description scope, but remain in the (physical, .D1-like) display scope. Note that the trailing full stop in many of the examples we are discussing here already uses that, and nobody asked how it works because it just feels natural in mdoc(7). In mandoc, even the opening parenthesis falls out of the .Lk scope; i merely didn't implement the additional complication that it should yet remain in the .D1-like display scope. In groff, .Lk is completely missing opening delimiter detection, resulting in the broken output you see above. > I was probably wrong in my original impression that it is a Pq problem > - it's the Lk that' the issue here, right? Exactly. Nothing is wrong with .Pq, but .Lk is a surprisingly complicated macro. Yours, Ingo
