bugGNU roff - Bugs: bug #64619, [mdoc] allow distros to maintain...

 
 

bug #64619: [mdoc] allow distros to maintain mdoc strings

Submitter:  Dave <barx>
Submitted:  Sun 03 Sep 2023 10:27:14 PM UTC
   
 
Category:  Macro mdoc Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 01 Oct 2023 02:04:44 PM UTC, comment #4: 

Not sure why you interpret

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273903

as being mad.  That's merely a list of things FreeBSD needs to deal with when upgrading to groff-1.23, and it happens to be public.  It's normal that a major version upgrade of software that is actively used requires some work.  For upgrading groff in OpenBSD ports, i know that the list of issues i will have to deal with will be much longer than that, but i'm not planning to make that list public.

Regarding

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273599

that particular (very minor) issue actually goes away if groff follows my recommendation of no longer validating OS release numbers.

Regarding colonization, there is a summary at

https://mandoc.bsd.lv/ports.html

Most BSDs plus illumos use mandoc as the formatting engine, but for apropos(1), man(1), and man.cgi(8), which implementation various BSD systems use varies wildly.  As far as i'm aware, the only systems using mandoc by default in all four capacities are OpenBSD and Void Linux.

One reason why Wolfram Schneider probably cares about this is that he is the maintainer of the old Perl4 man.cgi(8) that FreeBSD is still using, and which, i believe, is running groff under the hood:

https://man.freebsd.org/cgi/man.cgi/source


Ingo Schwarze <schwarze>
Group Member
Wed 27 Sep 2023 06:19:00 PM UTC, comment #3: 

Thanks for the follow-up, Ingo.  You make good points.  I don't think Wolfram Schneider will be happy to hear them, though.  He's already mad enough at groff, but the thought that decamping to mandoc won't make his life any better in this respect might drive him to despair.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273599

On the bright side, this experience taught me that mandoc has not colonized the *BSDs quite as thoroughly as I had assumed.  :P

G. Branden Robinson <gbranden>
Group administrator
Wed 27 Sep 2023 03:02:18 PM UTC, comment #2: 

This is a bad idea.  It would cause manual pages to become non-portable.

FWIW, i agree with Branden that the string system is among the more poorly designed parts of the mdoc(7) language.  Not all of that can be fixed.  In particular, the existing .St strings have to remain.  But defining new strings should generally be discouraged.  In the case of .St, it should be limited to extremely important standards where there can be no doubt that they will be widely needed across almost all projects.

Regarding hard-coded version numbers, that was a non-starter which turned into a nightmarish travesty decades ago.  I believe groff ought to simply stop validating Nx, Fx, Ox, and Dx arguments like mandoc(1) did years ago.

I have no good solution for .Lb.  It's misdesigned from the ground up and utterly non-portable by necessity no matter what you do.  OpenBSD does not use it anyway, but that decision does not help the projects that do use it.

Ingo Schwarze <schwarze>
Group Member
Mon 25 Sep 2023 01:41:00 PM UTC, comment #1: 

One could certainly say there is community interest in this feature.

https://reviews.freebsd.org/D41858

G. Branden Robinson <gbranden>
Group administrator
Sun 03 Sep 2023 10:27:14 PM UTC, original submission:  

Problem description: http://lists.gnu.org/r/groff/2023-04/msg00240.html
Solution sketch: http://lists.gnu.org/r/groff/2023-08/msg00016.html

In a nutshell: instead of requiring the groff project to maintain data for mdoc strings for all distros in tmac/mdoc/doc-syms and tmac/mdoc/doc-common, provide a framework to allow distros to maintain this data locally.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  • -email is unavailable- added by barx (original reporter)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-09-03 barx Carbon-Copy- Added alx

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code