[bug #65101] [mdoc] topics in "Name" section set in roman since 1.23.0

[G. Branden Robinson]

Follow-up Comment #6, bug #65101 (group groff):

Earlier in the discussion, I said:

> To be honest, I'm not sure Ossanna troff was ever ported to the VAX, so I'm
not sure what the CSRG used to set their manuals.

It most certainly was, as part of Unix/32V.  Reiser and London of AT
documented this effort in their paper "A UNIX(TM) Operating System for the DEC
VAX-11/780 Computer".

https://www.bell-labs.com/usr/dmr/www/otherports/32vscan.pdf

They even singled out _troff_ for complaint, though they didn't savage it as
badly as they did the Bourne shell.

"The source code for the document preparation and phototypesetter commands is
not portable; several weeks were required to produce properly running version
[sic] of these commands.  Use of the explicit (or worse, implicit) constant
"2" instead of sizeof(int) was quite common.  The code assumes that variables
which [recte: that] are adjacent in external declarations occupy contiguous
memory at execution time.  Several tables are initialized by assembly-language
programs.  Converting the tables was merely tedious; changing the code which
[recte: that] thought it knew the format of an a.out file required some
effort.  This memorandum was created using the converted nroff/troff programs
on the VAX-11/780."

I had read that paper before but apparently managed to forget much of its
content.  I hope that keying this in will help me to be a better *roff
historian in the future.


___

Reply to this item at:

  

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

[bug #64005] [ms] fix for Savannah #62688 has backwards test

[G. Branden Robinson]

Update of bug #64005 (group groff):

  Status:   Need Info => In Progress
 Summary: [ms] fix for Savannah #62688 suppresses page breaks
between displays => [ms] fix for Savannah #62688 has backwards test

___

Follow-up Comment #8:


> I think there may be a problem with this fix.

Good catch, Deri.

The regression test didn't catch it because the regression test didn't concern
itself with which control character was used to call the `bp` macro, and
moreover was used in a context where a line had just been broken anyway.

A new regression test reveals the same problem you found.

I got my wires crossed.

Here's the fix.


diff --git a/tmac/s.tmac b/tmac/s.tmac
index d3896c791..547eb9ec6 100644
--- a/tmac/s.tmac
+++ b/tmac/s.tmac
@@ -104,8 +104,8 @@ .de di
 .de bp
 .  nr @saved-no-space-mode \\n[.ns]
 .  rs
-.  ie \\n[.br] '@break-page \\$1
-.  el  .@break-page \\$1
+.  ie \\n[.br] .@break-page \\$1
+.  el  '@break-page \\$1
 .  if \\n[@saved-no-space-mode] .ns
 .  rr @saved-no-space-mode
 ..




___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Follow-up Comment #7, bug #65619 (group groff):

As a refresher, I'm wondering what should be done about some of the space
glyphs identified in comment #5.


___

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

[G. Branden Robinson]

Update of bug #65692 (group groff):

  Status:None => Rejected   
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Speaking as the de facto maintainer of _groff mdoc_, exact parity with
_mandoc_ output is not a goal for me.

> The output of 'mandoc' should have priority

I completely disagree.  Among other factors, _groff mdoc_ long predates the
_mdocml_ project.

As another point, a formatter should render _man_ and _mdoc_ documents
similarly.  I'll return to this point below.

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

I do this routinely when preparing patches to the _bash_, _ncurses_, and
_procps_ man pages.  I don't diff _groff_ (_nroff_) output against _mandoc_'s,
though--what I do is check that my _changes_ (to the man page content) behave
as expected.  If they don't, I investigate what.  In principle, I could
uncover a bug in either implementation this way.

This ticket is effectively demanding extremely strict specification of _mdoc_
output, something that I feel was not contemplated by its author, Cynthia
Livingston (though I'm open to correction on this point by Ingo Schwarze, who
has been in contact with her about _mdoc_ history).

Extremely strict specifications take a lot of effort to prepare validation
mechanisms for; worse, they limit the flexibility of implementers to solve
problems, particularly when facing conjunctions of language features that the
designers did not contemplate.  _mdoc_ is a large, complex language and I do
not believe its author or maintainers have the superhuman insight necessary to
foresee all possible valid inputs.

Further, because _man_ and _mdoc_ documents should render similarly, any
unspecified point of _mdoc_ rendering will get decided and possibly applied to
_man_ output as well.  So what you are proposing is that _groff_ slavishly
follow _mandoc_'s choices not only for _mdoc_ but for _man_ as well.

While I'm sure that prospect would excite _mandoc_'s more obnoxious partisans
to the point of ecstasy, I find it totally unacceptable.

The suggestions in your bug reports would greatly improve in quality if you
considered anything but their most immediate and obvious consequences.

Closing as rejected.


___

Reply to this item at:

  

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

[bug #65701] tmac/doc.tmac: extra '.ec'

[G. Branden Robinson]

Update of bug #65701 (group groff):

  Status:None => In Progress
 Assigned to:None => gbranden   


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[G. Branden Robinson]

Update of bug #65702 (group groff):

 Assigned to:gbranden => None   


___

Reply to this item at:

  

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

[bug #65710] [preconv] require disambiguation of U+00A0 on input

[G. Branden Robinson]

Update of bug #65710 (group groff):

  Status:   Need Info => None   

___

Follow-up Comment #3:


[comment #2 comment #2:]
> [comment #0 original submission:]
> > In my opinion preconv should either:
> > 
> > 1.  Fail and force the user to edit the input to make a real
> > choice, eliminating U+00A0 in the input.
> 
> This option seems materially the same as the rejected bug #65654, except
with that bug's proposed warning upgraded to a fatal error.  (Granted, #65654
was rejected a few days before bug #65693 (the current ticket's inciting
report) was opened.)

Yes.

Bjarni's prescription was much too strong.


Subject: preconv.cpp: Issue a warning if code '0xA0' is used in
the input and thus changed to '\~'

File: "src/preproc/preconv/preconv.cpp"
Subroutine: unicode_entity(int u)

  The code '0xA0' is displayed as a normal space, and is thus
visually the same as it.

  So authors better use '\~' directly in their files.


No, authors has better not, necessarily, use `\~` directly in their files. 
_Maybe_ they mean `\ ` (an unadjustable space).  It's impossible to know,
which is why they should disambiguate it.

And if there are multiple U+00A0 characters in sequence, the author might be
better off supplying a `\h` sequence to express what it is they want,
precisely.

A ticket grounded on sound principles often meets a better fate than one
grounded on poor ones.

One could of course accuse me of authorial ("submittorial"?) bias...

At this point I'm leaning toward solution 1 from comment #0.


___

Reply to this item at:

  

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

[bug #65761] [man] macro TP with '\c' and a single-font macro in the tag fails to format correctly

[G. Branden Robinson]

Update of bug #65761 (group groff):

  Status:None => Rejected   
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 
 Summary: macro TP with '\c' and a single-font macro in the
tag fails to format correctly => [man] macro TP with '\c' and a single-font
macro in the tag fails to format correctly

___

Follow-up Comment #1:

This ticket is essentially a request to revert the fix for bug #51468...which
was also filed by you.

Please consider making up your mind on this issue; you've been dithering over
it for fully ten years.

https://savannah.gnu.org/bugs/?42907

But regardless of your personal opinions, the status quo is one that keeps
historical man pages formatting correctly, and that fact weighs more heavily
to me.  For AT man compatibility, the single-font macros' input traps do not
respect output line continuation with `\c`.

In practice you seldom need to follow a single-font macro with a font
alternation macro.

Rewrite


.TP
.B \-\-\~\c
.RI [ args ]


as


.TP
.BR \-\-\~ \c
.RI [ args ]


or


.TP
.BR \-\- \~\c
.RI [ args ]


...for instance.

There are many other possibilities.

Rejecting.


___

Reply to this item at:

  

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

[bug #65762] configure check has erroneous code

[G. Branden Robinson]

Update of bug #65762 (group groff):

  Status:None => In Progress
 Assigned to:None => gbranden   


___

Reply to this item at:

  

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

[bug #65763] strictly compare strings in macro packages

[G. Branden Robinson]

Update of bug #65763 (group groff):

 Summary: Do actual string comparisons in macro packages =>
strictly compare strings in macro packages

___

Follow-up Comment #1:

I suspect this may be low priority, perhaps so low that it's not worth doing,
because _as deployed_, all of _groff_'s full-service macro packages are
prepared to format documents using the basic Latin character set.

I'm also still a bit undecided whether we should have a syntactically sweeter
way of doing string comparisons.

Here's a proof of concept I did back when discussing this issue with Deri.

It's pretty simple.  It grabs the symbol '~' for use as an operator in a
conditional expression and then uses the same infrastructure that's already in
place to handle `\?`.


$ git stash show -p 1
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 8d828a01e..7288f31c5 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -6002,6 +6002,25 @@ static bool do_if_request()
 }
 result = is_abstract_style(nm);
   }
+  else if (c == '~') {
+tok.next();
+symbol nm1 = get_name(true /* required */);
+symbol nm2 = get_name(true /* required */);
+if ((nm1.is_null() || nm2.is_null())) {
+  skip_branch();
+  return false;
+}
+macro *rm1 = static_cast(request_dictionary.lookup(nm1));
+macro *rm2 = static_cast(request_dictionary.lookup(nm2));
+macro *m1 = rm1->to_macro();
+macro *m2 = rm2->to_macro();
+if ((0 /* nullptr */ == m1) || (0 /* nullptr */ == m2)) {
+  error("cannot perform equality comparison on a request");
+  skip_branch();
+  return false;
+}
+result = (*m1 == *m2);
+  }
   else if (tok.is_space())
 result = false;
   else if (tok.is_usable_as_delimiter()) {


Not sure what the best way forward is.  I suggest that nothing about it is a
priority for 1.24.


___

Reply to this item at:

  

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

[bug #65800] bootstrap oddity: .gitignore discrepancy

[G. Branden Robinson]

Update of bug #65800 (group groff):

  Status:None => Need Info  

___

Follow-up Comment #2:

I'm going to need some advice from a GNU build system maven.  I don't know if
this is a bug or if we're doing something wrong.


___

Reply to this item at:

  

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

[bug #65809] [soelim] extend to deal with compressed files like 'zsoelim' does

[G. Branden Robinson]

Update of bug #65809 (group groff):

  Status:None => Postponed  
 Summary: extend 'soelim' to deal with compressed files like
'zsoelim' does => [soelim] extend to deal with compressed files like 'zsoelim'
does

___

Follow-up Comment #1:

In my opinion, this suggestion is not a good direction to go.  Recall the
advantages of the Unix filter model.

https://cscie2x.dce.harvard.edu/hw/ch01s06.html

And zsoelim already exists.  Why reinvent the wheel?

I don't intend to work on this, but I'm not quite prepared to reject it
outright; setting to "Postponed".


___

Reply to this item at:

  

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

[bug #65829] [troff] want way to translate a character to \~

[G. Branden Robinson]

Update of bug #65829 (group groff):

 Summary: Want way to translate a character to \~ => [troff]
want way to translate a character to \~


___

Reply to this item at:

  

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