[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

2024-05-05 Thread Bjarni Ingi Gislason
Follow-up Comment #5, bug #62826 (group groff):

  I do not have a case example as I use stripping (expanded
'tmac/strip.sed') to avoid the repeated removal of non-essential
characters.

  Example is file 'tmac/doc.tmac'.

  Size

162336 mar 27 12:39 tmac/doc.tmac

  Stripped size

 90253 maĆ­  5 17:52 build/s-tmac/doc.tmac

  I can get rid of my '.hw' (and thus the '.' in tmac/doc.tmac)
line and the comments by changing '.de' to '.de1' for three
macros in 'tmac/mdoc/doc-common'

  The test for such a change is

test-nroff -mandoc -ww -z -t -C tmac/groff_mdoc.7

N.B.

  cd tmac/mdoc

  The files in this directory have to be changed to
non-compatibility mode like some other tmac files.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #65692] tmac/mdoc.tmac: fix minor differences from the "mandoc" software

2024-05-05 Thread Bjarni Ingi Gislason
URL:
  

 Summary: tmac/mdoc.tmac: fix minor differences from the
"mandoc" software
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 05 May 2024 10:59:36 PM UTC
Category: Macro package mdoc
Severity: 3 - Normal
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 05 May 2024 10:59:36 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/mdoc.tmac: fix minor differences from the "mandoc"
software

  Fix minor differences in the output between 'nroff' and
'mandoc' using 'tmac/groff_mdoc.7' as an example.

  Reduce the number of these differences.

  They are best displayed with 'less -R'.

  The output of 'mandoc' should have priority and thus the
tmac/mdoc.tmac should be adjusted for the simplest differences.

  This is to facilitate the comparison of the output of files with
the 'mandoc' requests.








___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #62826] [tmac] clearly comment bug #44714 workaround in andoc.tmac

2024-05-05 Thread Dave
Update of bug #62826 (group groff):

Severity:  3 - Normal => 2 - Minor  
  Status:   Need Info => None   
 Summary: [PATCH] [tmac] options "-mandoc" and '-C' are not
compatible => [tmac] clearly comment bug #44714 workaround in andoc.tmac

___

Follow-up Comment #6:

Thanks for the clarification, Bjarni.

Since the patch is not relevant to anyone running groff tools as distributed,
I'm removing the "[PATCH]" indicator.

The one thing this patch does that IMO is worth keeping is commenting the two
empty lines that implement the bug #44714 workaround, especially as that bug
report predicts it will be challenging to fix, suggesting the workaround will
be in place quite a while.  And as I posted over there, the andoc.tmac comment
near the top should cite bug #44714 rather than vaguely referring to "a bug in
GNU troff."  (Or if the two empty lines themselves are given sufficiently
detailed comments, this leading comment may not be needed anymore.)

So I'm altering this bug's Summary to reflect this reduced scope.

[comment #5 comment #5:]
>   The test for such a change is
> 
> test-nroff -mandoc -ww -z -t -C tmac/groff_mdoc.7

As Branden noted in the email thread linked in comment #1, test-nroff is your
own script, not groff's.  (See bug #55941.)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #44714] compatibility mode: .do request and macro expansion via \* collide

2024-05-05 Thread Dave
Follow-up Comment #4, bug #44714 (group groff):

[comment #3 comment #3:]
> Probably until this is fixed (which may be a while if it proves as
> intractable as Werner predicts), the andoc.tmac comment should cite
> this ticket rather than vaguely referring to "a bug in GNU troff."

This is now covered by bug #62826.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #64155] [troff] specifying -fZD on command line generates warnings

2024-05-05 Thread G. Branden Robinson
Follow-up Comment #36, bug #64155 (group groff):

Sigh.  Wrote a long comment.  Form was stale.  Document Expired.  Text lost.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #64155] [troff] specifying -fZD on command line generates warnings

2024-05-05 Thread Dave
Follow-up Comment #37, bug #64155 (group groff):

[comment #34 comment #34:]
> Maybe it is time for a proper string equality operator in our
> conditional expressions.

While that would be a useful addition to the language, equivalent
functionality can be achieved in user space, in a way back compatible to
almost any older troff.

.de string_compare
.  ft TR
.  ie '\\$1'\\$2' .nr strings_equal 1
.  el .nr strings_equal 0
.  ft P
..
.
.ft ZD
.
.if 'foo'foo' .tm foo = foo, via output comparison operator
.if 'foo'bar' .tm foo = bar, via output comparison operator
.
.string_compare foo foo
.if \n[strings_equal] .tm foo = foo, via string_compare macro
.string_compare foo bar
.if \n[strings_equal] .tm foo = bar, via string_compare macro




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #64155] [troff] specifying -fZD on command line generates warnings

2024-05-05 Thread G. Branden Robinson
Follow-up Comment #38, bug #64155 (group groff):

[https://savannah.nongnu.org/support/?111059 Frustration submitted.]


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

2024-05-05 Thread Dave
Follow-up Comment #11, bug #59442 (group groff):

It sounds like a decision is needed on which is the cart and which the horse. 
Should this bug take priority -- as comment #1 points out, "The whole point of
soelim is to get preprocessors to run on `.so`ed files" -- and then bug #65108
has to figure out how to work within that framework?  Or should filename
handling take priority, and then this bug needs to figure out how to implement
the comment #1 precept within that new framework?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/