bugGNU troff - Bugs: bug #59425, [man, ms, mm]: drop compatibility...

 
 

bug #59425: [man, ms, mm]: drop compatibility wrapper feature

Submitted by:  G. Branden Robinson <gbranden>
Submitted on:  Sat 07 Nov 2020 06:08:37 AM UTC  
 
Category:  Macro - others Severity:  3 - Normal
Item Group:  Documentation Status:  Postponed
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 11 Nov 2020 12:27:09 PM UTC, comment #3: 

Re: comment #2

>> nobody in their right mind would want to use non-groff macro packages with groff.


> In principle, they should work find in compatibility mode.


The question is not so much whether they would work but why anybody would want to do that.  Groff has its own man, ms, and mm implementations and they are compatible.  The historical implementations have severe limitations and provide no benefit i can see.

> Maybe we should make an official list of [things to retire soon].


Sure, if you want to.  That can do no harm, even if it turns out to not be complete.

Ingo Schwarze <schwarze>
Project Member
Wed 11 Nov 2020 09:11:59 AM UTC, comment #2: 

comment #1:

> Groff macro packages clearly cannot work with any other roff implementation, and nobody in their right mind would want to use non-groff macro packages with groff.


[raises hand]  I'd be curious to see what happened.  In principle, they should work find in compatibility mode.

>  Alternative implementations of standard macro packages like man(7) and ms(7) basically don't exist, at least not any that are meant to be portable and that are relevant for practical use.


You mean alternatives to both AT&T's and groff's?

Yeah, I don't know of any.

> If you install multiple different implementations of roff, then the way to do that is to have a different directory tree for each of them, including a different macro directory for each one, and make sure every implementation uses its own macro directory.


Yes, that's what I do with Heirloom.

> Touching this before release might cause a gratuitious risk of regressions, but i think this obsolete "compatibility-wrapper" feature should probably be deleted after release.  I doubt that it ever made much sense in the first place.


Agreed; I don't plan to do anything about it right now, apart from fix the man pages, maybe.

> On top of that, DragonFly is the only relevant BSD that still uses groff for formatting manual pages, and it certainly doesn't support installing alternative man(7) and ms(7) packages.  So this is a non-issue for more than just a single reason.


Yes, I think this can go on the list of things to retire after 1.23.0.  Maybe we should make an official list of these, and include it in the release notes so people have as much warning as possible.  ("If you use this stuff, speak up now.")

Kind of on that note, glilypond has been totally broken for 5 years, near as I can tell.  Though I'd rather it be fixed than dropped.  Embedding a chunk of score in a document is something I am actually personally inclined to do.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Sat 07 Nov 2020 10:37:33 AM UTC, comment #1: 

Changing the names of macro packages to avoid conflicts only makes sense as long as you have a concept of portable macro packages and you desire alternative implementations of standard macro packages to work with the same roff implementation.  But none of that makes any sense in 2020.

Groff macro packages clearly cannot work with any other roff implementation, and nobody in their right mind would want to use non-groff macro packages with groff.  Alternative implementations of standard macro packages like man(7) and ms(7) basically don't exist, at least not any that are meant to be portable and that are relevant for practical use.

If you install multiple different implementations of roff, then the way to do that is to have a different directory tree for each of them, including a different macro directory for each one, and make sure every implementation uses its own macro directory.

All this certainly isn't an issue at all for any of the *BSDs and never was because BSD (singular, because only one BSD existed at the time, namely 4.4BSD) decided early on that groff (specifically, groff-1.08) is the system roff, and it has been ever since, for about 27 years.

Touching this before release might cause a gratuitious risk of regressions, but i think this obsolete "compatibility-wrapper" feature should probably be deleted after release.  I doubt that it ever made much sense in the first place.

On top of that, DragonFly is the only relevant BSD that still uses groff for formatting manual pages, and it certainly doesn't support installing alternative man(7) and ms(7) packages.  So this is a non-issue for more than just a single reason.

Ingo Schwarze <schwarze>
Project Member
Sat 07 Nov 2020 06:08:37 AM UTC, original submission:  

Evidently it doesn't confuse many people, or the macro package compatibility-wrapper feature is little-used (or both), but our man pages for man and ms are technically wrong because they don't refer to their implementations with the wrapper prefix.

See Makefile.am:247-277.  Also lines 917-920 for where the actual substitutions take place.

The mm package already does this correctly, so it should be pretty easy to ape.

I'm a bit curious why this hasn't been done for mdoc.  Don't the BSDs still have their own mdoc macro package (upon which ours was originally based but then heavily groffified), or do they rely exclusively on mandoc/mdocml for their mdoc rendering needs these days?

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.

 

(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 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-11 gbranden StatusNeed Info => Postponed
        Assigned toNone => gbranden
        Summary[man, ms]: man pages are not compatibility-wrapper aware => [man, ms, mm]: drop compatibility wrapper feature

    Back to the top


    Powered by Savane 3.7