Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character

[Steffen Nurpmeso]

Chet Ramey wrote in
 <2fd2ed52-3272-3433-6179-164bc5122...@case.edu>:
  ...
 |> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote:
 |>> In the bash manual page (`man bash`), the ASCII tilde character '~'
 |>> (0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE):
 |>>
 |>>  $ man bash | grep 'additional binary operator'
 |>>An additional binary operator, =˜, is available,
 |>>
 |>> The same happens for the use of ~ as a shorthand for the home
 |>> directory. This makes the manual page incorrect, and difficult to
 |>> search.
 ...
 |>> I don't know the first thing about groff, but `man groff_char`
 |>> suggests that ~ is indeed rendered as "modifier tilde", and that one
 |>> should write \(ti to obtain an actual tilde character.

Because i always have to give some remarks, this design decision
of James Clark of groff (~ is for accent) i personally always
found terrible.  In the past i suggested to at least change the
mdoc(7) manual macros so that during arguments for .Pa (path) (and
similar, like code blocks etc) a tilde is indeed ASCII tilde, and
nothing else.  Unfortunately that was not followed.

If i grep the manuals in the BSD git repo then they would benefit
from that decision; whereas ~ in paths is not often used, (ti is
never, unless i have overseen it.  \(ti / \[ti] for ASCII tilde in
UNIX manuals, code blocks, formulas etc is just sick.  And then
the world moved to UTF-8 long ago; i personally have never made
use of such crux in neither TeX nor roff, if all else fails you
can map something for a specific document.

Quite honestly, in NetBSD, only mdocml and groff use \(ti/\[ti],
In FreeBSD, only (external, new thing) bc(1) / dc(1), as well as
nvi and mandoc (mdocml), and less for its command line option.
On OpenBSD, mandoc plus

  origin/master:lib/libc/gen/ispunct.3:.Dl 
!\(dq#$%&\(aq()*+,\-./:;<=>?@[\e]\(ha_\(ga{|}\(ti
  origin/master:lib/libcrypto/man/ASN1_BIT_STRING_set.3:.D1 Po Fa bitstr No & 
Pf \(ti Fa goodbits Pc == 0

Plain tilde is the dead king, long live the king.
Thank you,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20230729002703.lasps%stef...@sdaoden.eu>:
 |Chet Ramey wrote in
 | <2fd2ed52-3272-3433-6179-164bc5122...@case.edu>:
 |  ...
 ||> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote:
 ||>> In the bash manual page (`man bash`), the ASCII tilde character '~'
 ||>> (0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE):
 ||>>
 ||>>  $ man bash | grep 'additional binary operator'
 ||>>An additional binary operator, =˜, is available,
 ||>>
 ||>> The same happens for the use of ~ as a shorthand for the home
 ||>> directory. This makes the manual page incorrect, and difficult to
 ||>> search.
 | ...
 ||>> I don't know the first thing about groff, but `man groff_char`
 ||>> suggests that ~ is indeed rendered as "modifier tilde", and that one
 ||>> should write \(ti to obtain an actual tilde character.
 ...
 |If i grep the manuals in the BSD git repo then they would benefit
 |from that decision; whereas ~ in paths is not often used, (ti is
 |never, unless i have overseen it.  \(ti / \[ti] for ASCII tilde in
 |UNIX manuals, code blocks, formulas etc is just sick.  And then

Having said that it seems that Linux man-pages and man-pages-posix
actively switched towards \[ti] in 2020 according to its
Changes.old, saying

  Various pages
  Michael Kerrisk  [Geoff Clare]
  Use "\(ti" instead of "~"
  A naked tilde ("~") renders poorly in PDF. Instead use "\(ti",
  which renders better in a PDF, and produces the same glyph
  when rendering on a terminal.

resulting in 53, and the latter uses \(ti, but lots of that is awk
operator stuff etc.  One thread member is credited for that
release btw.

Well i personally continue to find this sad given that UNIX
manuals started being written in the 70s differently, making it
over 45 years, something around that.  And i find the reasoning
mysterious even given that you can always create a different
mapping in case you really want it, no?, so why not simply do that
for PDF instead (.ie 'pdf'\*[.T]')?  No.

Thank you all for your patience, and a nice weekend i wish.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Viewing PDFs. (Was: Happy new Sun)

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221227232513.6zeaunnqaywtrxvw@illithid>:
 ...
 |I haven't looked at it

Buddy, it is where you got your _idea_ from.
So do not mind i unsubscribe to stop you spamming my inbox with
your shit, Mr. infinitely scaling intellectual.

When s-roff will ever spring into existence i'll shortly
resubscribe to post that, if possible.

Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Viewing PDFs. (Was: Happy new Sun)

[Steffen Nurpmeso]

Ralph Corderoy wrote in
 <2022122714.845141f...@orac.inputplus.co.uk>:
 |Hi Steffen,
 ...
 |Deri means you.

Dunno, Ralph.

Thanks,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Viewing PDFs. (Was: Happy new Sun)

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221227095728.c7oo2iolmg6hl4nw@illithid>:
 |At 2022-12-24T23:39:07+, Deri wrote:
 |>> "o" for the former.
 |>> 'That said, https://ftp.sdaoden.eu/code-mailx-1.pdf (beware:
 |>> 1MB!), realized with newest minor of mdocmx on groff
 |>> 1.23.0.rc1.2915-c6d7,
 |
 |That is 730 commits behind master, FWIW.

Well sorry, i cannot rebase mdocmx whenever you rename a mdoc
variable and do other notational beautification, like changing
doc-arg-limit to doc-arg-count, which happens quite frequently,
especially since the mdocmx contrib issue has been opened, i would
think.  So i have to rename 259 occurrances of this to stay in
sync just for you to have fun.

Or that .Sx quotes the arguments, which breaks mdocmx, because
until now doc-enclose-string was not necessary for all the
possible references .Sh, .Ss, (.Sx), .Ar, .Cd, .Cm, .Dv, .Er, .Ev,
.Fl, .Fn, .Fo, .Ic, .In, .Pa, .Va and .Vt.
Enclosing section references in quotes has never been done in UNIX
manuals, may it be man(7) or mdoc(7).

And...  But ok you are the maintainer and can do whatever you
want, and break downstream people any way you like, even for first
class cititzens like references, without offering the possibility
to somehow easily hook the real thing (the actual plain textual
content) for them, like i did with mx-xr-url for example (to be
able to finally provide external references also in PDF and HTML,
not only in less(1)).

And then it is always the mess with gnulib, and fiddling with the
Makefile because i do not have texinfo installed, nor will i.
So this is always a lot of distress, and for no value to me, since
references extension will never be upstreamed with the current set
of maintainers, fwiw.

 |> Since this was produced by gropdf you don't need -mpdfmark since it
 |> contains its own versions, however, I thought there was a test to stop
 |> both being loaded, so may not be the cause.

Thanks for this info, however i want that mdocmx works with my
groff clone that will spring into living existance when i live
long enough, and there you will only find pdfmark.
I did not even know about pdf.tmac before this conversation!!
But .. nice!  However: GPLv3 .. the root of all hm evil for groff
on *BSD.

 |There is, but it's recent.
 |
 |d941e8ad2e (G. Branden Robinson 2022-09-29 06:49:30 -0500  34) .if \
 |d pdfmark .nx
 |
 |I didn't count how many commits back that is.

Well about 30 like the above for mdoc alone, .. and i stopped
reading the diffs and commit messages.
The PDF created shows the same outline problem with mupdf as before.
And mdocmx is still broken due to the Sx change, it is a mess with
that doc thing, and further changes to be expected, unfortunately.
With the September variant it just works fine.
Just do not mind, i will somehow deal with it, maybe once when
1.23 is out.

Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Viewing PDFs. (Was: Happy new Sun)

[Steffen Nurpmeso]

Ralph Corderoy wrote in
 <20221224090607.7dbb222...@orac.inputplus.co.uk>:
 |Hi Deri,
 |
 |> You may need to open the outline pane on the left, which acts like a
 |> table of contents.
 |
 |Is it mandatory that a PDF viewer must supply this mechanism to be
 |worthy of the name?  Off-hand, I don't recall mupdf(1) or llpp(1) having

"o" for the former.
'That said, https://ftp.sdaoden.eu/code-mailx-1.pdf (beware:
1MB!), realized with newest minor of mdocmx on groff
1.23.0.rc1.2915-c6d7, via pdfmark.tmac, causes the outline pane to
show things twice; i cannot recall whether that was true on 1.22.3
already, it is very ugly and so i would surely have seen this in
the past hmm.  It is like

  v NAME
Synopsis
  v SYNOPSIS
Table of contents
  v TABLE OF CONTENTS
Description

etc etc.  This is wrong, of course, since these are all .Sh on the
top level.  But i had no time to wrap my head to see what is
going on.

 |an option or keystroke to show it.
 |
 |-- 
 |Merry Christmas to the list, Ralph.

Ah, new testament.  Propagandistic times indeed.
(Read the bible since June to understand the Christians better.
Passed Epistle to the Romans today.  No Joke, heh, U.S.A.
(Would rhyme better with Rome crosses my mind.)

 --End of <20221224090607.7dbb222...@orac.inputplus.co.uk>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Nils-Peter Nelson, sqtroff, and groff history

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221214002919.gy56muresenofizt@illithid>:
 |Some people might find the following messages, first from Nils-Peter
 |Nelson and then Liam R. E. Quin, of interest.  They're posts from 1996
 |to the comp.text USENET group.  (Je me souviens, DejaNews!)

Thanks for posting this!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [RFC] input.cpp: Remove use of strncat(3)

[Steffen Nurpmeso]

Alejandro Colomar wrote in
 <20221205223936.8290-1-...@kernel.org>:
 ...
 |--- a/src/roff/troff/input.cpp
 |+++ b/src/roff/troff/input.cpp
 |@@ -7892,7 +7892,7 @@ void do_macro_source(bool quietly)
 |MACRO_POSTFIX, sizeof(MACRO_POSTFIX) - 1) == 0) {
 |char *s = new char[fnlen + sizeof(MACRO_PREFIX)];
 |strcpy(s, MACRO_PREFIX);
 |-   strncat(s, fn, fnlen - sizeof(MACRO_POSTFIX) + 1);
 |+  strlcat(s, fn, sizeof(MACRO_PREFIX));
 |fp = mac_path->open_file(s, );
 |delete[] s;


To me this looks like a perfect usage of simple memcpy() since
both lengths are known.
Maybe even better would be a C++ string type so you could do
mac_path->open_file(resize().append().append().cp()), but this
seems off topic.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Doubts about a typo fix

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221126035253.pli53qzgfx6tbax5@illithid>:
 |At 2022-11-25T18:18:46-0800, Paul Eggert wrote:
 ...
 |> If we did that, Groff would set a source string like "\*-\*-help" as
 |> "−−help", with two instances of U+2212 MINUS SIGN instead of U+002D
 |> HYPHEN-MINUS. Therefore people couldn't cut and paste code examples
 |> out of HTML or PDF, and into the shell.
 |
 |This hasn't been true for PDFs produced by groff for about 10
 |years.[1][2]  You can copy a U+2212 minus sign and it will paste as a
 |U+002D.

It would be great if groff would release adjustments to grotty so
that one could again use copy+paste also in manuals.  And now
please do not beat me onto that hyphen-minus for options, and that
one should do this or that, but it is for many other characters,
too.  If i look at bash manual for example, hyphen-minus is ok,
but caret is not ^ but U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT,
and i see U+2018 LEFT SINGLE QUOTATION MARK instead of
single-quotes.  That is cool and maybe milks the shit out of the
typographic capabilities of modern UTF-8 terminal emulators (i
think i quote you here, more or less), but i always have to use
"LC_ALL=C man XY" to enable copy+paste for myself.  But hey, it is
only me, i am not a prof at an University who is prowd of dozens
of Noble price winners and other such prices, many of them still
worth something aka based upon scientific grounds.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

DJ Chase wrote in
 :
 |On Sat Sep 17, 2022 at 3:30 PM EDT, Steffen Nurpmeso wrote:
 |> P.S.: with the help from people of IRC i have now tested LuxiMono,
 |> IBMPlexMono, and NotoMono, and only LuxiMono gets it somehow right
 |> (but looks terrible as a monospace font imho).
 ...
 |JetBrains Mono / JetBrains Mono NL has great Unicode support and is very
 |readable. DejaVu Sans Mono, Source Code Pro, and Fira Code are also

Source Code Pro i had forgotten, this i had around, too.

 |popular. If you want more of an ASCII look, try Nimbus Mono or
 |Courier/Consolas.

Thanks.

 --End of 

Ralph Corderoy wrote in
 <20220918074144.d127e1f...@orac.inputplus.co.uk>:
 |These may give some ideas.  The first link allows your choice of
 |preview text.
 |
 |- https://fonts.google.com/?category=Monospace=troff%20%E2%\
 |80%98%E2%80%99%20%60%C2%B4%20%27=14_type=custom
 |
 |- https://en.wikipedia.org/wiki/List_of_monospaced_typefaces

Thanks Ralph.  The latter i indeed had stumbled upon during
a Google search.

(I stay with Liberation here.)

 --End of <20220918074144.d127e1f...@orac.inputplus.co.uk>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220917165637.pmpud%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20220917162423.trkch%stef...@sdaoden.eu>:
 ||Steffen Nurpmeso wrote in
 || <20220917152906.uhdto%stef...@sdaoden.eu>:
 |||Ralph Corderoy wrote in
 ||| <20220917105400.a3f1121...@orac.inputplus.co.uk>:
 >   ` U+0060, GRAVE ACCENT, "backtick"
 >
 > is displayed as
 >
 >   ‘ U+2018, LEFT SINGLE QUOTATION MARK
 >
 > which in Liberation Mono (at least!) this reverses the direction of
 > the tick.
 
 This shows the problem.
 
 pango-view --backend ft2 --header --font 'Liberation Mono' \
 --dpi 96 --hinting none \
 -t "$(troff -Tutf8 <<<'`'\'' \`\'\'' \(aq' | grotty)"
 || ...
 The font's designers have chosen to make the 6 and 9 quotes both lean to
 the right and, as is common today, to have very slight bulges so they
 are similar in appearance.
 ||
 ||..just to add that Liberation seems to be a free font used as
 ||a default in LibreOffice, which i did not know until just now,
 ||searching for a different monospace font.
 |
 |Oh merde, after 45 MB download IBMPlexMono has the same problem!!!

P.S.: with the help from people of IRC i have now tested LuxiMono,
IBMPlexMono, and NotoMono, and only LuxiMono gets it somehow right
(but looks terrible as a monospace font imho).

(P.P.S.: IBMPlexMono is really a great typewriter font, but must be
relatively large to look ok, only 51 lines on the screen here,
whereas Liberation and Noto are ok with 59.  Noto i find a bit
"too crouched", but the guy speaks quite some languages, including
several Asian ones, and says it offers good support for those.
I unfortunately cannot testify, too dumb a western.  Anyhow,
i have to stay with Liberation it seems, i will make an alias to
go for -Tascii, and prepare to somehow direct people to go for
-Tascii or LC_ALL=C man.  If at least literal code blocks and such
would remain unmapped.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220917162423.trkch%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20220917152906.uhdto%stef...@sdaoden.eu>:
 ||Ralph Corderoy wrote in
 || <20220917105400.a3f1121...@orac.inputplus.co.uk>:
 |||>   ` U+0060, GRAVE ACCENT, "backtick"
 |||>
 |||> is displayed as
 |||>
 |||>   ‘ U+2018, LEFT SINGLE QUOTATION MARK
 |||>
 |||> which in Liberation Mono (at least!) this reverses the direction of
 |||> the tick.
 |||
 |||This shows the problem.
 |||
 |||pango-view --backend ft2 --header --font 'Liberation Mono' \
 |||--dpi 96 --hinting none \
 |||-t "$(troff -Tutf8 <<<'`'\'' \`\'\'' \(aq' | grotty)"
 | ...
 |||The font's designers have chosen to make the 6 and 9 quotes both lean to
 |||the right and, as is common today, to have very slight bulges so they
 |||are similar in appearance.
 |
 |..just to add that Liberation seems to be a free font used as
 |a default in LibreOffice, which i did not know until just now,
 |searching for a different monospace font.

Oh merde, after 45 MB download IBMPlexMono has the same problem!!!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220917152906.uhdto%stef...@sdaoden.eu>:
 |Ralph Corderoy wrote in
 | <20220917105400.a3f1121...@orac.inputplus.co.uk>:
 ||>   ` U+0060, GRAVE ACCENT, "backtick"
 ||>
 ||> is displayed as
 ||>
 ||>   ‘ U+2018, LEFT SINGLE QUOTATION MARK
 ||>
 ||> which in Liberation Mono (at least!) this reverses the direction of
 ||> the tick.
 ||
 ||This shows the problem.
 ||
 ||pango-view --backend ft2 --header --font 'Liberation Mono' \
 ||--dpi 96 --hinting none \
 ||-t "$(troff -Tutf8 <<<'`'\'' \`\'\'' \(aq' | grotty)"
 ...
 ||The font's designers have chosen to make the 6 and 9 quotes both lean to
 ||the right and, as is common today, to have very slight bulges so they
 ||are similar in appearance.

..just to add that Liberation seems to be a free font used as
a default in LibreOffice, which i did not know until just now,
searching for a different monospace font.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220917155426.f4zgu%stef...@sdaoden.eu>:
 ...
 |I am out.

Well a bit harsh.  But other than that, not.

I see people using copy+paste with code examples and, even worse,
configuration examples, and getting lots of trouble because of
character mappings which result in invalid code / configurations.
I see a lot of "use -Tascii" or "use LC_ALL=C xy" to get over
that.  Well, not for me, given how few people use my stuff.
But nonetheless.

Cheerio.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20220917005135.3sy2ri22dhvlnvq5@illithid>:
 |At 2022-09-17T01:00:26+0200, Steffen Nurpmeso wrote:
 |> G. Branden Robinson wrote in
 |>  <20220916223236.lmkf3brdwotdn2fd@illithid>:
 |>|At 2022-09-16T23:56:58+0200, Steffen Nurpmeso wrote:
 |>|> How is anyone supposed to document a sh(1)ell-style manual with
 |>|> mdoc(7) (i do not know about man(7)) with these settings?
 ...

I am shortening that.  I have no time for getting distorted for
fun.

 |> and the locale has not changed!  The manual has not changed either.
 ...
 |Are you referring to some other manual?

Really.

 |> Just to remind you that the hyphen-minus -> hyphen change was commited
 |> in March _this_ year.
 |
 |Yes.  After I spent 2+ years advocating it on this mailing list and, as
 |a small portion of my work, reviewing groff's own ~60 man pages for
 |correct glyph usage.
 |
 |> So it you -- you are changing things backward incompatibly!
 |
 |No, I am aligning things more closely between typesetters and terminal

No.  You are changing the outcome of _all_ mdoc manuals ever
written since mdoc sprang into existence.

Copy and paste will be impossible to do henceforth, unless you do
"LC_ALL=C man X" (hopefully!), and one needs to somehow
communicate to users.

 |devices, to reflect the increasing capabilities of terminal devices on
 |Unix systems since about the year 2000.

No, no.

 |You can restore man pages to the appearance you desire by using the same

No.

  ..
 |> Please note again i am doing mdoc(7) here, not mom or ms or my own
 |> macros.
 |
 |Using mdoc(7) is no reason not to read groff_char(7).  mdoc(7) is a
 |groff macro package.  It does not alter the syntax or repertoire of
 |groff special characters.

Branden.  _All_ mdoc manuals _ever_written_ were written in the
environmental circumstances at the time when they were written.

Then Branden Robinson comes along and changes the meaning in 2022.

That is the thing, Branden, that, and solely that.

Ingo has at least run at least dozens of tests over _all manual
pages he got his hands on_ when iterating over the mandoc
development, in order and in hindight to being compatible with
groff output.

Have you just run ONE (!) test in equal spirit when you changed
the entire world.

Let me make a bet.

I bet...

NO!

_NOT_ONE_TEST_AGAINST_THE_EXISTING_POOL_OF_MDOC_MANUALS_!

I bet my fucking as!

I am out.

I wish you a nice weekend.

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Hello Ralph.

Ralph Corderoy wrote in
 <20220917105400.a3f1121...@orac.inputplus.co.uk>:
 |>   ` U+0060, GRAVE ACCENT, "backtick"
 |>
 |> is displayed as
 |>
 |>   ‘ U+2018, LEFT SINGLE QUOTATION MARK
 |>
 |> which in Liberation Mono (at least!) this reverses the direction of
 |> the tick.
 |
 |This shows the problem.
 |
 |pango-view --backend ft2 --header --font 'Liberation Mono' \
 |--dpi 96 --hinting none \
 |-t "$(troff -Tutf8 <<<'`'\'' \`\'\'' \(aq' | grotty)"

You again.  ft2 not here (ImageMagick .. gm not installed), but
cairo etc, thanks!

 |The font's designers have chosen to make the 6 and 9 quotes both lean to
 |the right and, as is common today, to have very slight bulges so they
 |are similar in appearance.

Indeed.

 |Fortunately, the command also provides a way to preview a better choice
 |of font.  :-)

Unfortunately not, this is the only monospace font i have, and
i was so happy to have found one that fits for me!  Sigh.
(In general i only have Liberation{Serif,Sans,Mono},
Free{Sans,Serif} and CrimsonXY, but de facto i only use
Liberation.

Do you have a suggestion?

Thanks Ralph.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20220916223236.lmkf3brdwotdn2fd@illithid>:
 |At 2022-09-16T23:56:58+0200, Steffen Nurpmeso wrote:
 ..
 |>   i=`echo '~/home^run'`
 |> 
 |> becomes
 |> 
 |>   i=‘‘echo ’˜/homeˆrun’‘’
 |> 
 |> How is anyone supposed to document a sh(1)ell-style manual with
 |> mdoc(7) (i do not know about man(7)) with these settings?
 |
 |By reading the manual, Steffen.

Ok, and you put a lot of effort in it in the last years.

But the point is: last week it looked _entirely_ different, and
the locale has not changed!  The manual has not changed either.
Just to remind you that the hyphen-minus -> hyphen change was
commited in March _this_ year.
So it you -- you are changing things backward incompatibly!

 |UTF-8 content follows.
 |
 |groff_char(7):
 ...

Please note again i am doing mdoc(7) here, not mom or ms or my own
macros.

 |There is also the "Portability" section of groff_man(7) [groff 1.22.4]
 |or groff_man_style(7) [groff 1.23].
 |
 |   Several special characters are also widely portable.  AT troff
 ...

But there is nothing special.  Input characters are mapped away
differently than before.

  ...
 |   \(ha   Basic Latin circumflex accent (“hat”).  Some output
 |  devices replace “^” with U+02C6 (modifier letter
 |  circumflex accent) or similar.
 ...
 |   \(ti   Basic Latin tilde.  Some output devices replace “~” with
 |  U+02DC (small tilde) or similar.

But why?  And furthermore: why -Tutf8 that lives on and with
fixed-width monospace fonts in practically all cases.  And why
differently than before?

 |Or you can just do the brute force thing.  From groff 1.23's "PROBLEMS"
 |file:

But this changes manuals written over the last decades to
something completely different, Branden.

I am coming from 1.22.3.  It looked entirely different last week.

You cannot expect all those people to rewrite all their manuals
because you feel like mapping monospace -Tutf8 to be en par with
-Tpdf with all its font powers (used or not)?
I really do not understand these decisions.

Please note also mandoc (at least the version i have here) renders
it the way i _expect_.

Maybe there is a reason why now also Apple i think switches away
from groff to mandoc?

 ...
 |* When viewing man pages, some characters on my UTF-8 terminal emulator
 |  look funny or copy-and-paste wrong.  Why?
 |
 |Some Unicode Basic Latin ("ASCII") input characters are mapped to
 |non-Basic Latin code points in output for consistency with other output
 |devices, like PDF.  See groff_man_style(7) and groff_char(7) for correct
 ...

Uh!

  ...
 |However, many man pages are written in ignorance of the correct special
 |characters to obtain the desired glyphs.  You can conceal these errors

Heh!  _Exactly_!

  ...
 |by adding the following to your site-local man(7) configuration.  The
 |file is called "man.local"; its installation directory depends on how
 |groff was configured when it was built.
 |
 |--- start ---
 |.if '\*[.T]'utf8' \{\
 |.  char ' \[aq]
 |.  char - \-
 |.  char ^ \[ha]
 |.  char ` \[ga]
 |.  char ~ \[ti]
 |.\}

You know, if you would provide a commented-out setting to change
the decade old default behaviour to what you feel is more modern,
or "better", _then_ i could understand it.
I mean i produce backward incompatible changes myself all the
time, but i give plenty of hints.  For example

  $ 

Re: 1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220916213112.5dabw%stef...@sdaoden.eu>:
 |Hello.
 |
 |Letting aside the hyphen-minus -> hyphen thing that i fixed for me
 |locally, there is also the problem that
 |
 |  ` U+0060, GRAVE ACCENT, "backtick"
 |
 |is displayed as
 |
 |  ‘ U+2018, LEFT SINGLE QUOTATION MARK

Also

  ~ U+007E, TILDE

is displayed as

  ˜ 02DC, SMALL TILDE

which here sits at the height of an accent here, for example the

  ^ 005E, CIRCUMFLEX ACCENT

Putting it all together it really looks totally odd here:

  i=`echo '~/home^run'`

becomes

  i=‘‘echo ’˜/homeˆrun’‘’

How is anyone supposed to document a sh(1)ell-style manual with
mdoc(7) (i do not know about man(7)) with these settings?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

1.23: UTF-8 device: more display oddities

[Steffen Nurpmeso]

Hello.

Letting aside the hyphen-minus -> hyphen thing that i fixed for me
locally, there is also the problem that

  ` U+0060, GRAVE ACCENT, "backtick"

is displayed as

  ‘ U+2018, LEFT SINGLE QUOTATION MARK

which in Liberation Mono (at least!) this reverses the direction
of the tick.

I was looking at a manual which uses backtick syntax notation for
sh(1)ell commands (aka i=`echo one`, not new-style i=$(echo one)),
and it _really_ looks strange.

Could be done something about this, please?
Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Ralph Corderoy wrote in
 <20220914071616.2e89021...@orac.inputplus.co.uk>:
 |Hi Steffen,
 |
 |>>> En dash would look nice, i could imagine.
 |>> 
 |>> Those ASCII ‘-’ above should be rendered as a hyphen in nicely
 |>> typeset output.  An en-dash is far too big.  Oh, there's another
 |>> one!
 |...
 |> But i was talking -Tutf8, and these are fixed width font
 |
 |Given we use terminal emulators on pixel-based devices and our choice
 |of font, I still see a significant difference with

Indeed here you make a point dear Ralph, terminals with stretchy
fonts can be a visual sensation.  The guys (of the Linux distro)
here on IRC "go viral" for alacritty, an OpenGL accelerated
terminal written in Rust (many on Wayland / sway), i think
"it can".  I once used such a thing, Microsoft Word 2.0 on
Windows 95B, it was funny how the text flowed, maybe i could
have parked my car in the inter-word spaces even.  Now i use st
with X resource support patch (5504 12892 0 Sep12 tty1 00:00:41
st -n stgrey -t accu, i find 41 seconds a bit heavy for that
little work).

 |$ troff -Tutf8 <<<'Re-sort with \-u.' | grotty | grep .
 |Re‐sort with −u.
 |$
 |
 |The hyphen is narrower so doesn't crash into the following rune.  It also
 |sits at a different height.  Whereas the option's dash is heavier and

Here too.  (Font is Liberation Mono.)
Yeah, look at that hyphen, it got it stickin' in the camera man.
We could have some.

 |more noticeable, as it should be given its significance.

Goodbye Piccadilly!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Dave Kemper wrote in
 :

How about [12066c659ea454a663483a12181a0c33cf416b22].
This looks promising.

Thank you.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Ralph Corderoy wrote in
 <20220913084152.0211621...@orac.inputplus.co.uk>:
 |Hi Steffen,
 |
 |> Hyphen is good at the end of line when a word is hyphenated, otherwise
 |> it is misplaced.
 |
 |Not in English.  A hyphen may be used to join compound adjectives, as a
 |two-minute Google would show.  :-)  An ‘American-football player’ isn't
 |necessarily American whereas an ‘American football player’ is, but he
 |may be playing what the Yanks call soccer.  It's also used when adding a
 |prefix to a word, as in ‘re-sort’ to re-run sort(1) as ‘resort’ is where
 |one holidays.
 |
 |> En dash would look nice, i could imagine.
 |
 |Those ASCII ‘-’ above should be rendered as a hyphen in nicely typeset
 |output.  An en-dash is far too big.  Oh, there's another one!

Ah, kerning and all that, a science!
But i was talking -Tutf8, and these are fixed width font and there
are three character cells, and the left "has two", the middle "is
empty", and the right is ok to go.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20220913053400.7lmdp2qpxb6zweei@illithid>:
 |At 2022-09-12T23:41:34+0200, Steffen Nurpmeso wrote:
 |> This is not a hyphenated word.
 |[rearranging this a bit]
 |> En dash would look nice, i could imagine.
 |
 |Then use en dashes in your input.
 |
 |  on\[en]loop\[en]main\[en] tick

Please do not put my words out of context.
I was responsding to a term of yours, because i do _not_ want to
use \-BLA.  If i would like that, i would look what to do, your
suggestion looks good; mdoc has .Fl for flags.

  ..
 |>|2.  This is not a "1.23"-specific issue as your subject line[]
 |>|suggests.
 |>|
 |>|$ groff --version | head -n 1
 |>|GNU groff version 1.22.4
 |> 
 |> Ok.. this i did not know.  Until last week i was solely using
 |> 1.22.3, even if the system has 1.22.4 (just not for me).
 |
 |I don't _think_ this was a change in groff 1.22.4, either, but it's not
 |easy for me to run groff 1.22.3 or earlier to experiment on them.

Well i ran it, and i never saw anything but hyphen-minus in
manuals.

  ...
 |> Really.  The above is just wrong, Branden.  Who said such?
 |
 |The consensus of this list was that it is better typography overall.

Then maybe you should ask typographic experts what to do, on
a list where such people can be asked?

Anyhow, and that is plain, whereas in German Bindestrich and
Ergänzungstrich may indeed look better in a typographical perfect
book, instead of hyphen-minus, and of course en dash that i used
in a different context, that is solely founded in the determining
factor that kerning and stretching etc is used to bring the
leading and the subsequent character(-cell) together.
In -Tutf8 this can never be true?

  | A-|   | B |

looks just terrible on a console, so the effect is the absolute
opposite to what was desired, which will not happen with
hyphen-minus

  | A | - | B |

But .. i see where this leads to..

  ...
 |However, many man pages are written in ignorance of the correct special
 |characters to obtain the desired glyphs.  You can conceal these errors

What are you talking about Branden?

  ...
 |by adding the following to your site-local man(7) configuration.  The
  ...

Who do you think will do this?  Do you support per-user
configuration files at least?  How many people do _know_ that they
can configure groff _there_?

  ...

No!

  ...
 |However, it turns out the above might not be squarely relevant to your
 |situation after all; if what you need are en dashes, then no version of

Yes.

  ...
 |> You cannot use HYPHEN for the above.
 ...

No.

Well i see that makes no sense.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Dave Kemper wrote in
 :
 |On 9/12/22, Steffen Nurpmeso  wrote:
 ...
 |Groff has converted an input U+002D to a proper hyphen in typeset
 |output for decades.  It has done so in UTF-8 output since at least
 |groff 1.19.2.
 ...

This is not true.  I never have seen anything but hyphen-minus on
my boxes, and i was running 1.22.3 until last week.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Hello Branden.

G. Branden Robinson wrote in
 <20220912144641.q2r65kkfpiej4u2u@illithid>:
 |At 2022-09-12T15:43:00+0200, Steffen Nurpmeso wrote:
 |> I have problems with the UTF-8 device, it shows
 |> 
 |>   on‐main‐loop‐tick
 |> instead of
 |>   on-main-loop-tock
 |> 
 |> ie U+2010 instead of hyphen-minus U+002D.
 |> 
 |> The above does not feel right, and searching is impossible!
 |> I would expect U+2010 HYPHEN in hyphenation, but not as a regular
 |> combiner aka delimiter joined words as are used very often in
 |> German, for example.
 |
 |There are a few points to raise about this.  The first is a question.
 |
 |1.  You don't expect a hyphenated word to use a hyphen?

This is not a hyphenated word.  In Germany, not only due to
feminist aka suffragette movement, we have lots of names like
that even.  For example Annette von Droste-Hülshoff, 12. Januar
1797 until 24. Mai 1848.  You could hyphenate that, but then, at
some point, feminism comes to an end!  (For her it has different
roots, though.)

 |2.  This is not a "1.23"-specific issue as your subject lines suggests.
 |
 |$ groff --version | head -n 1
 |GNU groff version 1.22.4

Ok.. this i did not know.  Until last week i was solely using
1.22.3, even if the system has 1.22.4 (just not for me).

  ...
 |3.  If you're secretly in a man page context but didn't disclose that,
 |then, yes, this is a change from groff 1.22.4.  The hyphen-minus,
 |neutral apostrophe, and grave accent no longer map differently for
 |man(7) and mdoc(7) than for any other macro package.  (\- still does

Oh.  While cycling dimly recalled there was a discussion here, but
did not truly follow it(?).

 |and there is no prospect of that changing, since there is no *roff
 |special character defined for the "ASCII hyphen-minus", and it is
 |essential to express this precise character in man pages.  These
 |issues have been discussed at some length on this mailing list over
 |the past three years.)

Really.  The above is just wrong, Branden.  Who said such?
You cannot use HYPHEN for the above.  Hyphen-minus itself,
less-than, greater-than, no-break space, LEFT-POINTING DOUBLE
ANGLE QUOTATION MARK, only to go until 0xAB.  Or standard names
like IEEE Std 1003.1™-2017, IEEE Std 1003.1-2008, C-language,
code-level, POSIX.1-2017, built-in, this is only the first page of
that standard.  Or the ISO C17 standard, you search for "-" in the
official PDF, and you find it for Storage-class, absolute-value,
floating-point, type-generic, thread-specific, and more, and we
are still in the TOC.  No no -- no HYPHEN here!

These are _not_ hyphenated words.

If roff can make a difference in true hyphenation points (i had to
take a lng look), then it could change a hyphen-minus on the
input side with a hyphen on the output side when it really breaks
a line at that point.  Otherwise hyphen-minus is the only viable
alternative.

Or look at the Unicode standard, where real great minds with
incredible multi-national professional life careers are involved,
get the official PDF (hr-hrm, i have not updated since Unicode
13..), combined words are separated with hyphen-minus, _not_
hyphen.

This is really wrong.

 |4. "on-main-loop-tick" doesn't look a natural language word to me--it
 |   looks like an identifier in a programming language (maybe some
 |   dialect of Lisp).  If that is the case, those hyphens need to be
 |   spelled "\-" in the source code.  This has always been true in man

Well, yes and no.  Hyphen is just everywhere in 1.23.

 |   pages, going back to 1979.
 |
 |   Take
 | $ grep '\\-[A-Za-z]' ~/src/unix/v7/usr/man/man1/bc.1
 |.B \-c

Yeees, well, i really had to look you know.  This is a language
and there was development and it was a lot of woolding.

  -.th MAIL I 10/25/72
  -.sh NAME
  -mail  \*-  send mail to another user

Who says it is not an evolution of the above?
Doug McIlroy is on this list, maybe he reads and knows.
Though he said something about the NATO today, and that lying
aggressive Endsieg beast is definetely on the other side of the
road.

And by the way, you mention flags in the above.  Flags are
different, because often you want this to be a U+2013 EN DASH.
Ie, you want to make it _longer_ than a hyphen-minus.  Not super
short like a hyphen.  Imho.

  ...
 |5.  Searching is not impossible.
 |5a. Searching for a word that is broken and hyphenated across lines
 |is no more impossible than it always was.  On occasions when I
 |have to do this, I break out sed(1) or perl(1).

It is not hyphenated, Branden.

 |5b. Literals that might be of interest in man pages should be
 |entered with hyphenation suppressed in the input.  The groff man

Hey!  This is not rocket science or something.
I am happy if people at least do _write_ manuals _at_all_.

 |pages in 1.23 do this much more conscientiously than in past

1.23: UTF-8 device produces mysterious characters

[Steffen Nurpmeso]

Hello!

I have problems with the UTF-8 device, it shows

  on‐main‐loop‐tick
instead of
  on-main-loop-tock

ie U+2010 instead of hyphen-minus U+002D.
The above does not feel right, and searching is impossible!
I would expect U+2010 HYPHEN in hyphenation, but not as a regular
combiner aka delimiter joined words as are used very often in
German, for example.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[bug #63042] Enhancement: mdocmx(7) extension to mdoc(7)

[Steffen Nurpmeso]

Follow-up Comment #1, bug #63042 (project groff):

630 42.  Why not.


___

Reply to this item at:

  

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

[bug #63042] Enhancement: mdocmx(7) extension to mdoc(7)

[Steffen Nurpmeso]

URL:
  <https://savannah.gnu.org/bugs/?63042>

 Summary: Enhancement: mdocmx(7) extension to mdoc(7)
 Project: GNU troff
   Submitter: sdaoden
   Submitted: Fri 09 Sep 2022 10:14:30 PM UTC
Category: Macro mdoc
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 09 Sep 2022 10:14:30 PM UTC By: Steffen Nurpmeso 
Hello.

Another try to establish the mdocmx(7) reference+ extension at groff(1)'s
mdoc(7), after the failed attempt in 2015, which, granted, was based on a
pretty crude grotty(1) extension.

But in 1.23 with the OSC 8 extension to grotty(1) groff delivers out of the
box, and less(1) also at least ignores OSC 8 for a while.  With the now
fully-featured less(1) enhancement request

  https://github.com/gwsw/less/pull/251

the combination of groff(1)/mdoc(7)/mdocmx(7)/grotty(1) plus less(1) delivers
a fully referenced manual experience, with optional table of contents and
more. 

The attached file contains a git(1) mail-patch MBOX to be used with git(1)
am.

The first changeset hooks mdocmx(7) into mdoc(7).  The largest change needs to
happen in doc-print-recursive, which will henceforth know who its caller was.
These changes do not change functionality of plain mdoc(7).
A mdoc(7) file must make explicit use of the extension in order to load the
actual mdocmx contribution.

The second adds contrib/mdocmx.

In general mdocmx requires a new sh(1)/awk(1) based preprocessor in order to
provide its functionality, as troff(1) is single-pass, and therefore forward
references cannot be created.
However, the mdocmx preprocessor will put a cookie so that the actual mdocmx
macros know what to do (to be upward compatible with a two-pass troff(1) that
may spring into existence in a future time).  Therefore preprocessed manuals
can be distributed.
(I release them like that for the programs i maintain since i think 2015, and
they become interactive in the second where there is a capable roff.)

mdocmx(7) has one problem left, described in the BUGS section of the contained
mdocmx.7 manual.  Only a rewrite of mdoc(7) as such can fix this.  (A survey
in 2015 has shown that some BSD manuals indeed _do_ use referenceable and
formatting macros in header lines, these would have to adapted to be
compatible with mdocmx.  But since you must write _for_ mdocmx anyway, this is
a hypothetical issue.)

Conclusion: with the MBOX applied to 1.23, and with a less(1) including the
pull request, one should be able to go up up and away like

  groff -Tutf8 -mdoc mdocmx.7 | less -R

Note the manuals mdocmx.7 and mdocmx.1 are installed in a preprocessed way for
groff, so "man 7 mdocmx" should also rock.
And "MDOCMX_FLAGS=64 man 7 mdocmx" should also produce a table of contents.

Ciao!

P.S.: hihihi, now that i explicitly added an account, Savannah allows
notification Cc: specification!






___
File Attachments:


---
Date: Fri 09 Sep 2022 10:14:30 PM UTC  Name: groff-1_22_3-mdocmx.mbox  Size:
89KiB   By: sdaoden

<http://savannah.gnu.org/bugs/download.php?file_id=53672>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63042>

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

Re: 1.23: troff register names broken?

[Steffen Nurpmeso]

Eh sorry folks.

Steffen Nurpmeso wrote in
 <20220909164816.rzev-%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20220909163015.7zdu0%stef...@sdaoden.eu>:
 | ...
 ||so it seems to me .nr registers can no longer contain a "#" in
 ||their name!  That would totally boom my macro package(s)!  Is not
 ...
 |  .   .if \B'\*[mx#s1]' \{\

note the doubled period.  solely my fault.
ridiculous, hm.

Ciao.  And a nice weekend everybody!!!
Sorry for the noise.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23: troff register names broken?

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220909163015.7zdu0%stef...@sdaoden.eu>:
 ...
 |so it seems to me .nr registers can no longer contain a "#" in
 |their name!  That would totally boom my macro package(s)!  Is not

However, i also have

  . nr mx#t-d#n1 0
  . while (\n[mx#t-d#n1] < \n[mx:Sh-no]) \{\
  .   nr mx#t-d#n1 +1
  .   ds mx#t-d#s \*[mx:Sh-\n[mx#t-d#n1]-arg]
  .   ie d mx-toc-numbered \
  . It \n[mx#t-d#n1]. Sx "\*[mx#t-d#s]"
  .   el \
  . It Sx "\*[mx#t-d#s]"

etc among many others, and if i enforce the according setting, the
TOC is produced as normal.  In fact anything is as usual all week
long, it is just

  .   ds mx#s1 \V[MDOCMX_FLAGS]
  .   .if \B'\*[mx#s1]' \{\
  . nr mx#n1 64 \"\*[mx#s1]
  .nr auau 33
  .mx:perr S1=\*[mx#s1] #N1=\n[mx#n1] AUAU=\n[auau]
  .ab x

where that mx#n1 register is not set, whatever i do, it says

  mdocmx(7) error: S1=64 #N1=0 AUAU=33 (#14)
  x

Any idea on this?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

1.23: troff register names broken?

[Steffen Nurpmeso]

Hello.

During testing (still not done because i massively improved the
less pull request, not yet pushed, but now even ^O^N and ^O^P work
totally graceful regarding repaints and _every_ move around)
i stumbled over certain number registers i use do not work no more
like they should, so if i instrument like

  .   ds mx:#s1 \V[MDOCMX_FLAGS]
  .   .if \B'\*[mx:#s1]' \{\
  . nr mx:#n1 64 \"\*[mx:#s1]
  .nr auau 33
  . nr mx:n1 64 \"\*[mx:#s1]
  .mx:perr S1=\*[mx:#s1]  #N1=\n[mx:#n1] N1=\n[mx:n1] AUAU=\n[auau]
  .ab x

i get

  mdocmx(7) error: S1=64 #N1=0 N1=64 AUAU=33 (#14)
  x

so it seems to me .nr registers can no longer contain a "#" in
their name!  That would totally boom my macro package(s)!  Is not
the desired behaviour, no?  (I am sorry not to have time to look
into the 4000 commits are what that separate the two versions..)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

Hello Branden,

..again, and sorry, for the noise..

Steffen Nurpmeso wrote in
 <20220907210913.drf4v%stef...@sdaoden.eu>:
 |P.S.:
 ...
 |||(Actually my less(1) pull request will not find the IDs my mdocmx
 ...
 |I updated the pull request with an additional fix commit that
 ...
 |I would still hope for a possibility to create anchor-only OSC 8.

Actually i will update it again with

osc8_inspect(): ignore "#[no ID]" local anchor URIs..

Like in HTML #ID are in-document local anchor references.
An URI # without ID does not lead anywhere usually.

Ignore them in the sole case that there also was an id= parameter,
meaning this OSC 8 construct is meant to *create* a local anchor.

Like this less(1) will be capable to deal with local anchors
generated by grotty(1)'s 1.23[.0] \X'tty: link' command.
(Which, perspectively, will be used for interactive Unix manual
pages.)

Whether it will make it i cannot tell.  But i can tell you
i _love_ to use the interactive manual pages since 2014.
Of course, only for the programs i created myself, but that is
a pity!

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

P.S.:

Steffen Nurpmeso wrote in
 <20220906232237.izz2i%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20220906231824.-4way%stef...@sdaoden.eu>:
 ...
 ||(Actually my less(1) pull request will not find the IDs my mdocmx
 ...

I updated the pull request with an additional fix commit that
makes the code smaller and much more robust, enabling it to deal
with empty parameters, only ignore bogus ones etc.  So we deal
with grotty as-is.

I would still hope for a possibility to create anchor-only OSC 8.

Ciao, Branden.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20220906231824.-4way%stef...@sdaoden.eu>:
 ...
 |(Actually my less(1) pull request will not find the IDs my mdocmx
 |produces via your grotty thing because of it.  Hm.  Well, we break
 |out if we cannot find the = in the K=V, and ;: is an empty
 |parameter.  Sigh.  I have to make this more robust in that non-K=V
 |parameter is _not_ bogus if it is initially empty.  Bugs anywhere!)

The "standard" says

  `params` is an optional list of `key=value` assignments,
  separated by the `:` character. Example:
  `id=xyz123:foo=bar:baz=quux`. Currently only the `id` key is
  defined, see below. These parameters allow future ext endability
  of this feature. In the typical case no parameters are defined,
  in that case obviously the two semicolons have to be present
  next to each other.

So i mean i am not _that_ wrong in claiming that a parameter
without an = in the expected K=V is bogus.  However, it seems more
robust to allow empty parameters in the block of parameters.

Good night!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

Oh!

Steffen Nurpmeso wrote in
 <20220906224118.jh2ju%stef...@sdaoden.eu>:
 |G. Branden Robinson wrote in
 | <20220906205844.xbo54jzk2v7jscvf@illithid>:
 ||At 2022-09-06T16:22:42+0200, Steffen Nurpmeso wrote:
 ...
 |It would be _tremendous_ if \X'tty: link' would get the

Actually i think it even has a bug, Branden.  It is

  `OSC` `8` `;` `params` `;` `URI` `ST`

where params are colon-separated.  But if i say
\X'tty: link # id=a' then it generates

  ^[]8;:id=a;#^[\3

aka already the first parameter "is separated" with a colon.
Maybe not a real bug, but surely the colon is redundant.
(Actually my less(1) pull request will not find the IDs my mdocmx
produces via your grotty thing because of it.  Hm.  Well, we break
out if we cannot find the = in the K=V, and ;: is an empty
parameter.  Sigh.  I have to make this more robust in that non-K=V
parameter is _not_ bogus if it is initially empty.  Bugs anywhere!)

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

Hello Branden.

G. Branden Robinson wrote in
 <20220906205844.xbo54jzk2v7jscvf@illithid>:
 |At 2022-09-06T16:22:42+0200, Steffen Nurpmeso wrote:
 ...
 |Thanks, Steffen.  I have applied this to my working copy.

It would be _tremendous_ if \X'tty: link' would get the
possibility to create ID-only anchors, Branden.  Otherwise i have
to use a dummy link target (currently the number-sign), and then
there is indeed a link target.
Now, _if_ that less(1) pull request gets through, with

  ^O^I Search for an OSC 8  in the file.
  ^O^P Go to previous OSC 8 link.
  ^O^N Go to next OSC 8 link.
  ^O^O Open current OSC 8 link with LESSOSC8OPEN.

then moving forward and backward via ^O^P and ^O^N will find those
dummy links, but they are only document-local anchors.

I mean, that is at least my idea for this, simply taking the HTML
way of doing things over, so that \X'tty: link #ID' searches for
and finds a document local \X'tty: link id=ID'.

I do like your idea of simply using one "link", and have any
number of user-defined colon-separated KEY=VALUE pairs.  With just
two issues, for one i would use colons for separators also on the
grotty side, so that whitespace in the input becomes possible, and
then i would really, really long for the mentioned only-ID aka
anchor thing.  That would truly be tremendous!

Ciao, and good night!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

[Steffen Nurpmeso]

P.S.: i overtook this name change to my roff clone, shall that
ever spring into real existance.  You have a credit, please
complain if you do not want to be named in THANKS.

diff --git a/tmac/mdoc/doc-common b/tmac/mdoc/doc-common
index 6c9093a876..29ee7f8c7b 100644
--- a/tmac/mdoc/doc-common
+++ b/tmac/mdoc/doc-common
@@ -345,7 +345,6 @@
 .  ds doc-topic-name \" empty
 .  ds doc-volume LOCAL
 .  ds doc-section \" empty
-.  ds doc-command-name
 .
 .  if !"\$1"" \
 .ds doc-document-title "\$1



--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: .man file extension

[Steffen Nurpmeso]

Alejandro Colomar wrote in
 :
 |Hi Branden,
 |
 |I see that you use .7.man or .1.man internally in the groff(1) source 
 |repository.  But then those extensions are presumably removed during the 
 |installation, since man(1) doesn't like them.  What are they for?

Surely automake sausage.
As like for make(1) and its inference rules.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: 1.23.0.rc1.2875-9c30-dirty: does not prefer its own same-version subprograms?

[Steffen Nurpmeso]

Dave Kemper wrote in
 :
 |On 9/3/22, Steffen Nurpmeso  wrote:
 |> Letting aside that --with[out]-doc was blindly removed
 |
 |This was not done blindly: Ingo posted a lengthy rationale to this
 |list (http://lists.gnu.org/r/groff/2022-04/msg9.html), and invited
 |comment from anyone who wanted to retain the option.  No one spoke up
 |in its favor.

Yes i have read that.  You missed to quote

  Letting aside that --with[out]-doc was blindly removed even though
  i do not really think that so much changes to the involved
  documents happened,

But lenghty is the right word.

 |>   #?0|kent:src$ s-roff -v
 ...
 |>   called subprograms:
 |>
 |>   GNU grops (groff) version 1.22.4
 |>   GNU troff (groff) version 1.22.4
 |>
 |> ^ Finds the programs of the Linux distro's groff variant.
 |
 |You seem to have stumbled across an instance of Savannah #62860:
 |http://savannah.gnu.org/bugs/index.php?62860

Ah yes.  Thanks.  Yes, that seems to be the problem.

I can confirm it is still broken!

 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

1.23.0.rc1.2875-9c30-dirty: does not prefer its own same-version subprograms?

[Steffen Nurpmeso]

Hello.

Gratulations for maintainership, Branden Robinson!

I am in the process of porting mdocmx to groff 1.23.

(That is to say: automake issues, after gnulib issues, git gc
--aggressive is killed by that ChangeLog which is nothing but
a duplicate of git log but prepends at the top instead of
appending to the file, 13.7 GB RAM and > 30 minutes for GCing that
file alone, i think describes my problem.)

Letting aside that --with[out]-doc was blindly removed even though
i do not really think that so much changes to the involved
documents happened, which is a pity, since i have to fiddle around
until autoreconf / make succeed, sigh, ...  But i do not think
that is the cause for the problem below.

I see this:

  #?0|kent:src$ ll -l `command -v groff`
  -rwxr-xr-x 1 root root 108288 Mar 24  2019 /usr/bin/groff*

Groff of my Linux distro.

  #?0|kent:src$ ll -l `command -v s-roff.old`
  lrwxrwxrwx 1 steffen steffen 23 May 16  2019 
/home/steffen/usr-kent-crux-linux-x86_64/bin/s-roff.old -> 
../opt/.groff/bin/groff*

A version of 1.22.3 with my 2015 mdocmx patch.

  #?0|kent:src$ ll -l `command -v s-roff`
  lrwxrwxrwx 1 steffen steffen 27 Sep  3 23:20 
/home/steffen/usr-kent-crux-linux-x86_64/bin/s-roff -> 
../opt/groff-1.23/bin/groff*

1.23 RC1 with mdocmx "regulary" implemented (under contrib/ etc;
of course tmac/ mdoc(7) had to be patched in-line, but that
surprisingly took not even an hour and is "3 files changed, 153
insertions(+), 51 deletions(-)"), no more.

So this:

  #?0|kent:src$ groff -v
  GNU groff version 1.22.4
  Copyright (C) 2018 Free Software Foundation, Inc.
  GNU groff comes with ABSOLUTELY NO WARRANTY.
  You may redistribute copies of groff and its subprograms
  under the terms of the GNU General Public License.
  For more information about these matters, see the file
  named COPYING.

  called subprograms:

  GNU grops (groff) version 1.22.4
  GNU troff (groff) version 1.22.4

^ Finds its same-version programs.

  #?0|kent:src$ s-roff.old -v
  GNU groff version 1.22.3
  Copyright (C) 2014 Free Software Foundation, Inc.
  GNU groff comes with ABSOLUTELY NO WARRANTY.
  You may redistribute copies of groff and its subprograms
  under the terms of the GNU General Public License.
  For more information about these matters, see the file
  named COPYING.

  called subprograms:

  GNU grops (groff) version 1.22.3
  GNU troff (groff) version 1.22.3

^ Ditto.

  #?0|kent:src$ s-roff -v
  GNU groff version 1.23.0.rc1.2875-9c30-dirty
  Copyright (C) 2022 Free Software Foundation, Inc.
  GNU groff comes with ABSOLUTELY NO WARRANTY.
  You may redistribute copies of groff and its subprograms
  under the terms of the GNU General Public License.
  For more information about these matters, see the file
  named COPYING.

  called subprograms:

  GNU grops (groff) version 1.22.4
  GNU troff (groff) version 1.22.4

^ Finds the programs of the Linux distro's groff variant.
Ditto for tmac, somehow.  I just discovered it freshly.

Other than that i like your OSC 8 implementation, Branden!

With one problem, i wonder what could be done to give an empty
URL, ie only an id=ID.  for now i use the char #.  Somehow i have
not working it like so yet, but in the works!

Thanks for implementing OSC 8 in grotty!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: man(7) .TH font change, was: groff man(7) `B` macro...

[Steffen Nurpmeso]

Ingo Schwarze wrote in
 :
 |Steffen Nurpmeso wrote on Mon, Jun 20, 2022 at 02:23:58PM +0200:
 |
 |> Just to mention that since 2014 my .Mx mdoc(7) extension is
 |> distributed for the things i use, and i never have heard about an
 |
 |Just in case people aren't aware, even though this was repeatedly
 |discussed in the past:  mdocmx is a textbook example of overengineering:
 |horrendous complexity for almost no gain.  Most of what it aims for can be
 |done without it and does not require any new syntax; the few aspects it
 |implements that cannot be done without new syntax are next to irrelevant
 |for practical purposes.  It is good that nobody except Steffen uses it.

Your contiguous beating upon this does not make things any better.
Horrendous complexity!  Man, you suck.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: man(7) .TH font change, was: groff man(7) `B` macro...

[Steffen Nurpmeso]

Ingo Schwarze wrote in
 :
 |Alejandro Colomar wrote on Sun, Jun 19, 2022 at 04:11:49PM +0200:
 |> On 6/19/22 16:00, Ralph Corderoy wrote:
 ...
 |That makes compatibility in man(7) significantly more of a concern
 |than in mdoc(7).  All the same, i would certainly not consider
 |adding anything as disruptive as .MR to mdoc(7).

Just to mention that since 2014 my .Mx mdoc(7) extension is
distributed for the things i use, and i never have heard about an
incompatibility.  (Except some Debian manual checker is
complaining on an unknown command.)

It offers table of contents, index, additional free-form anchors,
local and inter-manual page references.  It is only restricted due
to the way mdoc(7) is implemented in groff(7), which could be
overcome.  Unfortunately the new groff maintainer made the mdoc
macros incompatible with how they were before, so that i did not
port it to >1.22.3 (especially to avoid being trapped in a spiral
of changes needed to follow upstream).

Shall OSC-8 search be accepted in less(1) upstream [1] then
looking at a .Mx enabled manual page in less(1) will be an
interactive experience as if viewing a HTML page in a text-mode
web browser like lynx(1):

  . ^O^I text - will search for the OSC 8 id= "text".
  . ^O^N - searches for the next OSC 8 link aka URI.
  . ^O^P - searches for the previous OSC 8 link aka URI.
  . ^O^O - opens the currently selected OSC 8 link aka URI with
  the shell command given in the environment variable
  LESSOSC8OPEN; it will be passed as a properly quoted single
  argument.  If LESSOSC8OPEN is not set, "man:NAME((.*))?" style
  links are still understood and opened via man(1).

  [1] https://github.com/gwsw/less/pull/251

Different to 2014 when i used an incompatible approach to
implement this in less(1), basic OSC-8 support (understand and
ignore) has already been accepted upstream without my assistance.

The manual of mdocmx is at [2], a very (too) large manual using
its powers is [3].  Table of content and all anchors and
references solely come via mdocmx.

  [2] https://www.sdaoden.eu/code-mdocmx.html
  [3] https://www.sdaoden.eu/code-nail.html

Shall you have my S-nail as your mailx(1), you could do this even
immediately with the local manual page if grotty and less could.
.Mx could be renamed to .Mr it seems.  .Mr sounds a bit weird tho.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: lots of fatal build system bugs on OpenBSD

[Steffen Nurpmeso]

Ingo Schwarze wrote in
 :
 |Douglas McIlroy wrote on Tue, Mar 22, 2022 at 08:58:19AM -0400:
 |> Tangential comment:
 |> I have always recoiled from git.
 |
 |I agree to some extent.  Git does get a number of things right, but
 |there are also many aspects of its user interface and design that make
 |it harder to use than necessary.  It's hard to call those issues fatal

I do not agree with that.
Mr. McIlroy was used to Plan9, and they had a SHA-1/block based
backing store behind a short lived cache aka venti/fossil etc.
So it can be said he/they even invented the actual concept.
But it is not daily snapshoted etc., but explicitly on request.

It is just a database of hashed objects.  The database consists of
several types of objects (commits, directory/content snapshots,
and binary blobs), which refer to each other and (can) form
several paths through the database.  Like a (several) commit
history line(s) of a branch(es).

That said, i learned it now over a decade ago, and basically did
not move.  I use commands like "git update-ref refs/heads/BRANCH
SHA-1/BRANCH" to reset history line "heads".  I use "git tag TAG
SHA-1/BRANCH" to introduce a tag in the tag in the line.  I use
"git fetch [-v] [UPSTREAM NAME]" to synchronise, "git push
[UPSTREAM NAME] [:BRANCH NAME:]" in the other direction.
I use "git commit" to create a commit object.
"git rebase [--onto BRANCH] SHA-1^/BRANCH^ (first) SHA-1/BRANCH
(last) to rebase (parts of) history lines.
I use "git merge [--ff-only] SHA-1/BRANCH" to merge other lines
onto the current one.
We are basically there.  "git reset [--hard] BRANCH".
Ah yes, "git diff [--cached]", because there is the working tree
and the things yet "git add [:FILE:]"ed to the staging area that
will be used by the next "git commit".

Today much much more is possible, partial checkouts etc etc.
That however is beyond my capabilities.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: memccpy(3) and stpcpy(3) status in C2x (was: stpecpy(): A better string copy function)

[Steffen Nurpmeso]

Martin Sebor wrote in
 :
 |On 2/13/22 13:32, Alejandro Colomar (man-pages) wrote:
 |> On 2/13/22 19:29, Alejandro Colomar (man-pages) wrote:
 ..
 |>>> I expect/hope stpcpy to become the new norm for string copying, though
 |>>> it will require overcoming much inertia and many dusty old books.
 |>>>
 |>>> It was introduced to POSIX in Issue 7 (2018).
 |>>>
 |>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/strcpy.html
 |>>>
 |>>> Martin Sebor is sponsoring its inclusion in C2x.
 |>>>
 |>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2352.htm
 |>>>
 |>>> (It may have been accepted, or not--I haven't checked the status.)
 |>>
 |>> No, stpcpy(3) was not accepted.  memccpy(3) was instead.  The problem
 |>> wasn't stpcpy(3) as it seems, but stpncpy(3) about which I'll rant a bit
 |>> below :).
 |> 
 |> I forgot to link to the C2x document, which contains very interesting
 |> information:
 |> 
 |> 
 |> 
 |> TL;DR: That document considers strlcpy(3) to be "optimal", but not
 |> widely supported enough, and then selects memccpy(3) as "good enough"
 |> and way more widespread.
 |
 |I think that was also the sentiment in WG14 when the proposal was
 |discussed.  N2352 proposed stpcpy and stpncpy by themselves but it
 |didn't gain enough support.  More detail of the committee discussion
 |of both proposals (and others) is in the meeting minutes:
 |   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2376.pdf

I personally like my

  /*! Copy \a{src} to \a{dst}, return pointer to NUL in \a{dst}.
   * Returns \NIL if \a{dst} is not large enough; \a{dst} will always be
   * terminated unless \a{n} was 0 on entry. */
  EXPORT char *su_cs_pcopy_n(char *dst, char const *src, uz n);

But mostly i either use memcpy if possible, or

  /*! Copy at most \a{n} bytes of \a{src} to \a{dst}, and return \a{dst} again.
   * Returns \NIL if \a{dst} is not large enough; \a{dst} will always be
   * terminated unless \a{n} was 0 on entry.
   * Also see \r{su_cs_pcopy_n()}. */
  EXPORT char *su_cs_copy_n(char *dst, char const *src, uz n);

They are C-only implementations yet.

--Steffen Schönbein

Re: PROPOSED: Kill \X'tty: sgr'

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20211125171302.ubixfedm3xtssc5m@localhost.localdomain>:
 |I'm proposing a feature deletion.
 |
 |https://savannah.gnu.org/bugs/index.php?61561
 |
 |Have I overlooked something?

It is the counterpart to the environment variable *_NO_SGR, and
controls the same variable old_drawing_scheme.
Why do you say that does not work?  Have i missed something?
I personally .. would not remove it.  What if anyone uses it to
turn off those ANSI sequences for her macro package?

In fact _i_ would not have simply turned the new scheme on, but
made it depend on some termcap or terminfo capability!  This is
what my MUA does, and if so allowed.  Ie if "Co" is given we _do_
use ISO 6429 sequences and do not care for the rest (aka do not
use the other termcap/terminfo sequences to generate the according
strings, we simply use ISO 6429 -- i found that sufficient for all
my thinkable options over twenty years ago i think, and have never
been dashed).  Iirc it is one of the "improvements" of GNU roff
that i never got right.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Find a char in string

[Steffen Nurpmeso]

Wim Stockman wrote in
 :
 |Is there a function in groff to find the position of a char in a string.
 |So I can split a string into more than one.
 |I found the substring function that can cut based on length. If I could my
 |marker in the string I could cut it there.

Loop over the string and use substring to shorten it by one in
each iteration?  Then use normal comparison for the spliced thing.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: WAYTO: indexed man pages

[Steffen Nurpmeso]

Ingo Schwarze wrote in
 <20210602223746.ga92...@athene.usta.de>:
 ...
 |Then again, i feel that's a problem of relatively little urgency.

That is because you use that mutilated less.  The original can.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: getting more out of man pages with less(1)

[Steffen Nurpmeso]

Hey.

Steffen Nurpmeso wrote in
 <20210523212903.58vrh%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20210523004836.gta8l%stef...@sdaoden.eu>:
 | ...
 |||> Good idea.  I've further changed the Subject: to reflect the flow \
 |||> of the
 |||> discussion.
 || ...
 |||> I also wonder if the pager wars are basically over and less(1) \
 |||> won them.
 |||
 |||That's certainly what I thought...
 || ..
 ||
 ||Ever since less(1) started supporting OSC 8 "Hyperlinks in
 ||Terminal Emulators" as of version 566 i wanted to rewrite my
 ||mdocmx(7) extension to be based upon the OSC 8 sequences that now
 ||become more and more common.
 ...
 |  \X'tty osc8 [id ID] [uri URI]'

Much much better approach indeed.

Mind you, since mdocmx is sitting around since 2014/5 for my
personal fun, but OSC 8 is a nice standard that is available in
a growing number of software...
Please let me attach patches for less (v586 aka git repo, also at
[1]) which implements searching for OSC 8 sequences, grotty (git
repo from a few days ago, also at [2]) that implements the above
\X'', and a readily prepared manual page (from mdocmx, for fun).

You can look at the manual page in a less>=566 via -R, and all
will appear as desired (for mdocmx).  If you would patch less, you
could type ^A (control-A) and enter the anchor to jump to.  This
works even for external manual pages.  (For less, when going over
git: autoreconf;make -f Makefile.aut;make.)

I think i will ask Mr. Nudelman again whether he is interested in
the patch of implementing OSC 8 id= searches.
You know, i really like being able to stay in less :)

Anyhow, with the above OSC 8 things like docbook and other XY-
to-manual page converters could easily pimp the manual pages they
produce.

  [1] https://ftp.sdaoden.eu/less-osc8-search.patch
  [2] https://ftp.sdaoden.eu/grotty-osc8.patch

Ciao,

P.S.: I have not tested the grotty patch with any other groff but
the 1.22.3 i have here.  Just made it fit nicely in 1.22.4 aka git
head.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
From d374e9180166c7a655c7ee0a542df6c3643b2c74 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Steffen Nurpmeso 
Date: Sun, 23 May 2021 01:27:41 +0200
Subject: [PATCH] Support OSC 8 anchors

---
 cmd.h   |   1 +
 command.c   | 174 
 configure.ac|   7 ++
 decode.c|   3 +-
 defines.ds  |   7 ++
 defines.o2  |   7 ++
 defines.o9  |   7 ++
 defines.wn  |   7 ++
 less.h  |   3 +
 less.hlp|   1 +
 less.nro.VER|   6 ++
 lesskey_parse.c |   3 +
 search.c|  21 ++
 13 files changed, 246 insertions(+), 1 deletion(-)

diff --git a/cmd.h b/cmd.h
index 7141817bae..b4942d44ed 100644
--- a/cmd.h
+++ b/cmd.h
@@ -69,6 +69,7 @@
 /* Note "X116" refers to extended (1006) X11 mouse reporting. */
 #define A_X116MOUSE_IN 68
 #define A_CLR_SEARCH   70
+#define A_OSC8_SEARCH  84
 
 /* These values must not conflict with any A_* or EC_* value. */
 #define A_INVALID  100
diff --git a/command.c b/command.c
index d4e271324d..4948cc9a7d 100644
--- a/command.c
+++ b/command.c
@@ -57,6 +57,14 @@ extern int incr_search;
 extern int utf_mode;
 #endif
 
+#if HILITE_SEARCH
+extern int hilite_search;
+#endif
+
+#if OSC8_SEARCH
+public char *osc8_search_line /* = NULL */;
+#endif
+
 #if SHELL_ESCAPE
 static char *shellcmd = NULL;   /* For holding last shell command for "!!" */
 #endif
@@ -84,6 +92,11 @@ static struct ungot* ungot = NULL;
 
 static void multi_search LESSPARAMS((char *pattern, int n, int silent));
 
+#if OSC8_SEARCH
+static void osc8_search();
+static void a_osc8_found();
+#endif
+
 /*
  * Move the cursor to start of prompt line before executing a command.
  * This looks nicer if the command takes a long time before
@@ -302,6 +315,11 @@ exec_mca(VOID_PARAM)
 		(void) pipe_mark(pipec, cbuf);
 		error("|done", NULL_PARG);
 		break;
+#endif
+#if OSC8_SEARCH
+	case A_OSC8_SEARCH:
+		osc8_search(cbuf);
+		break;
 #endif
 	}
 }
@@ -1122,6 +1140,151 @@ multi_search(pattern, n, silent)
 	}
 }
 
+/*
+ * OSC 8 search.  Search for an according OSC 8 id= parameter, and scroll the
+ * respective position into view.
+ * If a matching anchor is found it may also be a reference to an external
+ * manual page, if the OSC 8 URI starts with man://: in this case prepare the
+ * necessary man(1) command and give the user the option to confirm the action.
+ * Anyway: set lastmark() so that it is possible to jump back; let the empty
+ * anchor be an alias for the desire to do so
+ */
+#if OSC8_SEARCH
+	static void
+osc8_search(cbuf)
+	char const *cbuf;
+{
+	int const srch_flags = SRCH_NO_REGEX | SRCH_OSC8;
+
+	PARG parg;
+	char *q, *qc;
+	long l;
+# if HILITE_SEARCH
+	int save_hilite_sea

Re: getting more out of man pages with less(1)

[Steffen Nurpmeso]

Good evening and Hello.

Steffen Nurpmeso wrote in
 <20210523004836.gta8l%stef...@sdaoden.eu>:
 ...
 ||> Good idea.  I've further changed the Subject: to reflect the flow of the
 ||> discussion.
 | ...
 ||> I also wonder if the pager wars are basically over and less(1) won them.
 ||
 ||That's certainly what I thought...
 | ..
 |
 |Ever since less(1) started supporting OSC 8 "Hyperlinks in
 |Terminal Emulators" as of version 566 i wanted to rewrite my
 |mdocmx(7) extension to be based upon the OSC 8 sequences that now
 |become more and more common.
 |
 |So the last two days i finally made the great and implemented
 |OSC 8 for my mdoxmx macro package extension, as well as for grotty
 |v1.22.3 and less v586.  Yay.
 |grotty was a bit hard because i wanted to implement all sorts of
 |OSC 8 things, even those they did not invent there in that github
 |repo, like document-local anchors and document-local "URI"s (i
 |used the usual "#REF" syntax used by eg HTML).

Ok, so i slept over that and have to say the grotty part was
silly.  I was coming from mdocmx thinking.  I will rewrite it like

  \X'tty osc8 [id ID] [uri URI]'

aka leave the user in charge of just about anything, without any
testing, and without keywords we actually see an end-marker.
This means that macros or converters are in charge of creating
#ANCHORs and links as well as man://NAME.SECTION URLs, but then
again that is the usual thing of doing things, and one cannot
enforce a thing with a too-complicated i-do-it-all-for-you.
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: getting more out of man pages with less(1)

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20210523212903.58vrh%stef...@sdaoden.eu>:
 |Good evening and Hello.

And thanks to Mario Blättermann, replying to the mail unrevealed
a bug that is present in the MUA i maintain since at least 2003
(nail 10.05)!

A nice Monday i wish.  (And happy 80th birthday, Bob Dylan.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: getting more out of man pages with less(1)

[Steffen Nurpmeso]

Hello.

 |> Good idea.  I've further changed the Subject: to reflect the flow of the
 |> discussion.
 ...
 |> I also wonder if the pager wars are basically over and less(1) won them.
 |
 |That's certainly what I thought...
 ..

Ever since less(1) started supporting OSC 8 "Hyperlinks in
Terminal Emulators" as of version 566 i wanted to rewrite my
mdocmx(7) extension to be based upon the OSC 8 sequences that now
become more and more common.

So the last two days i finally made the great and implemented
OSC 8 for my mdoxmx macro package extension, as well as for grotty
v1.22.3 and less v586.  Yay.
grotty was a bit hard because i wanted to implement all sorts of
OSC 8 things, even those they did not invent there in that github
repo, like document-local anchors and document-local "URI"s (i
used the usual "#REF" syntax used by eg HTML).

  +// Place a document-local anchor; arg(s): 1=ID
  +// (An OSC8 sequence without URI and INNER-TEXT.)
  +{"anchor", sizeof("anchor") -1, a_ANCHOR, 1},
  +// Link with inner text; arg(s): 1=URI, 2=INNER-TEXT
  +{"link", sizeof("link") -1, a_LINK, 2},
  +// Reference a document-local anchor; arg(s): 1=ID [2=INNER-TEXT]
  +// If INNER-TEXT is missing ID is reused for that.
  +{"link-anchor", sizeof("link-anchor") -1, a_LINK_ANCHOR, 2},
  +// Reference a manual page; arg(s): 1=NAME 2=SECTION-NR [3=ID]
  +// ID is optional, SECTION is manual section (eg "idle 2 55", "vi 1p").
  +// This ends up as "man://NAME.SECTION", the inner text will be ID if ID
  +// was given, otherwise "NAME(ID)".
  +{"link-manual\0", sizeof("link-manual") -1, a_LINK_MANUAL, 3},
  +// Link with externally controlled inner text; arg(s): 1=URI
  +{"link-start", sizeof("link-start") -1, a_LINK_START, 1},
  +// No arguments
  +{"link-end", sizeof("link-end") -1, a_LINK_END, 0}

Eg \X'tty osc8 link-anchor 50' or \X'tty osc8 link-manual awk 79'.
The latter ends up like (here in blue as my mdocmx does it):

  awk(1)^[[34m[^[]8;id=79;man://awk.1^[\79^[]8;;^[\]^[[0m

So for example (here formatted by my mdocmx macro extension):

  SEE ALSO
   awk(1)[79], ...

then in less(1) with the OSC 8 anchor-search patch, typing ^A:

  [OSC 8 anchor]:

then typing 79 and return and one sees

  Read external manual: !man 1 awk

and if you return return again that comes up.
One could think about dropping link-manual and simply offering
a $LESS_BROWSER or so hook, but like this some security checks can
be applied more easily.  (Only fewest yet.)

I pushed the git mail-patch boxes to the git repo of my roff clone
that is still awaiting any actions.  On Monday i will apply some
more content checking on the link-manual content in less(1) (in
grotty we already check cisprint before we create the OSC
8 sequence).

The nice thing with OSC 8 is that generators like docbook or so
could simply enwrap things like

  .BR cat (1)

with \X'tty: osc8 link-start cat 1' and \X'tty: osc8 link-end'.
For my search patch for less(1) however this would not work out.
For now the less(1) OSC 8 search patch requires an id= though.

A nice sunday i wish from Germany.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: man-intro

[Steffen Nurpmeso]

Ulrich Lauther wrote in
 <20210522214249.GA20730@starlite>:
 |On Sat, May 22, 2021 at 08:18:41PM +0200, Oliver Corff wrote:
 |> 
 |> "man cd", on the other hand, opens the bash built-in command *man page*,
 |> which, at least on my system is a plethora of text to read (and digest).
 |> 
 |on my sytem (ubunto mate) "man cd" results in "No manual entry for cd".

Dunno Ubuntu but POSIX manuals (aka 1p, 3p ..) could be a separate
package.  They are definitely separate balls here:

  #?0|kent:$ ll /x/balls/man-pages/
  total 2636K
  -rw-r--r--  1 ports ports 1758092 Mar 28 00:57 man-pages-5.11.tar.xz
  -rw-r--r--  1 ports ports  935196 Mar 28 00:57 man-pages-posix-2017-a.tar.xz
  drwsrwx--T  1 ports ports 100 Mar 28 01:55 ./
  drwsrws--T+ 1 ports ports5616 May 22 17:51 ../

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Question about Unicode Greek

[Steffen Nurpmeso]

Hello.

Robert Goulding wrote in
 :
 |I've been away from groff for a long time; I think the last time I used it,
 |there was no Unicode support at all. Now I'm interested in using it as a
 |filter from markdown, through pandoc to groff to pdf.
 |
 |This is working well for me, except for a handful of files in which I use
 |Greek with accents. I understand that groff doesn't have characters for
 |accented Greek characters, and I'm willing to do the work to add them, I'm
 |just trying to understand what's involved.
 |
 |So, here is a tiny document with some Greek in it:
 |
 |.LP
 |ἐν ἀρχῇ ἦν ὁ λόγος, καὶ ὁ λόγος ἦν πρὸς τὸν θεόν, καὶ θεὸς ἦν ὁ λόγος
 |
 |When I run this through preconv, I get the following:
 |
 |.lf 1 rubbish.ms
 |.LP
 |\[u1F10][...]
 |
 |with all of the Unicode characters turned into the correct code numbers.
 |When I run this through groff -ms -Tps I get the following errors:
 ...
 |This is what is puzzling me. The very first letter, ἐ, is correctly given
 |its unicode description \[u1F10] by preconv; but then troff seems to
 |decompose it into \[u03B5] which is ε and \[u0313] which is ̓ . So, if I
 |wanted to tell groff how to print ἐ, how do I go about it, when there seem
 |to be two internal representations?

It seems the groff source repository contains the necessary update
in the afmtodit tables to include this character for non per-se
Unicode aware output devices.  A new release will ship it thus.
You could try to update the %AGL_to_unicode hash in
/usr/bin/afmtodit of your installed groff accordingly, too.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: How to make groff use local timezone?

[Steffen Nurpmeso]

Colin Watson wrote in
 <20201214154336.ga32...@riva.ucam.org>:
 |On Mon, Dec 14, 2020 at 02:12:28PM +1100, G. Branden Robinson wrote:
 |> At 2020-12-12T21:19:38-0800, Jim Avera wrote:
 |>> I suspect groff is always in UTC (but haven't confirmed).  
 |> 
 |> No, that is not true, at least not in groff as provided by GNU.  A
 |> downstream distributor, like a GNU/Linux distribution, could alter this.
 |
 |Debian currently does
 |(https://salsa.debian.org/debian/groff/blob/master/debian/patches/displa\
 |y-utc-times.patch).
 |But I'm unsure about the correctness of this, which is why I hadn't
 |pushed it upstream; it was something of a desperation measure to get
 |reproducible builds working in more places, but changing the semantics
 |of things like \n[hours] is not ideal.
 |
 |Perhaps playing whack-a-mole with TZ=UTC in more places would be better
 |in this case, although it seems unlikely to be much fun - I'm not sure.

My brute simple Web42 website "manager" offers UTC and LOCAL,
because it seemed good to offer both versions.  (The latter is
optional and equals the former unless some perl module is
installed that is so by default for a long time.)

When i mean is, isn't this a nice feature request, new number
registers named xy_utc or so?
I have not even tried all this, but it could be as simple as

  diff --git a/src/troff/input.cpp b/src/troff/input.cpp
  index f1714c51..559efe40 100644
  --- a/src/troff/input.cpp
  +++ b/src/troff/input.cpp
  @@ -7665,8 +7665,23 @@ static void init_registers()
 time_t
   #endif /* not LONG_FOR_TIME_T */
   t = time(0);
  +
 // Use struct here to work around misfeature in old versions of g++.
  -  struct tm *tt = localtime();
  +  struct tm *tt;
  +
  +  while((tt = gmtime()) == NULL)
  +t = 0;
  +  set_number_reg("seconds_utc", int(tt->tm_sec));
  +  set_number_reg("minutes_utc", int(tt->tm_min));
  +  set_number_reg("hours_utc", int(tt->tm_hour));
  +  set_number_reg("dw_utc", int(tt->tm_wday + 1));
  +  set_number_reg("dy_utc", int(tt->tm_mday));
  +  set_number_reg("mo_utc", int(tt->tm_mon + 1));
  +  set_number_reg("year_utc", int(1900 + tt->tm_year));
  +  set_number_reg("yr_utc", int(tt->tm_year));
  +
  +  while((tt = localtime()) == NULL)
  +t = 0;
 set_number_reg("seconds", int(tt->tm_sec));
 set_number_reg("minutes", int(tt->tm_min));
 set_number_reg("hours", int(tt->tm_hour));

A bit ugly, but .. hmm.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: pdfmark not working

[Steffen Nurpmeso]

Timothy Groves wrote in
 :
 |Any attempt to use the pdfmark macro package causes exactly nothing to 
 |happen - no error messages, but also no metadata being added to my PDF.  
 |I've followed the instructions that come with pdfmark slavishly, 
 |including testing in the most minimal document humanly possible, and 
 |still gotten nothing.  I am running groff 1.22.4 under Ubuntu 20.04, and 
 |have installed the full groff (as opposed to groff-base) package.  Is 
 |there some library requirement not described under the documentation?

Well i would say "show this document".
I use 1.22.3 (aliased to s-roff because here there is 1.22.4 too,
and that does not support the necessary extensions) via

  mdocpdf() ( MDOCMX_ENABLE=1
\export MDOCMX_ENABLE
\: ${MDOCMXFLAGS:=-dmx-toc-force=tree}
\mdocmx.sh "${1}" | \s-roff -Tpdf -mdoc ${MDOCMXFLAGS} )

and that mdocmx extension only does (^ actually pdfmark related)

  .\" PDF
  .
  .de mx:dump-init-pdf
  . mso pdfmark.tmac
^
  . \" Try to fill in some stuff from mdoc(7) macros
  . ds mx#s1 \*[document-title]
  . if !"\*[section]"Null" \
  .   as mx#s1 (\*[section])
  . if !'\*[mx#s1]'' \
  .   pdfinfo /Title "\*[mx#s1]"
[^]
  . rm mx#s1
  . als mx:pdf:Nd-orig Nd
  . als Nd mx:pdf:Nd
  . \" TODO more .pdfinfo stuff
  . nr PDFOUTLINE.FOLDLEVEL 2
^
  . als mx:dump-xr  mx:dump-xr-pdf
  . als mx:dump-anchor  mx:dump-anchor-pdf
  . als mx:dump-ref mx:dump-ref-pdf
  ..
  .
  .de mx:pdf:Nd
  . pdfinfo /Subject "\$*"
^
  . als Nd mx:pdf:Nd-orig
  . Nd \$@
  ..
  .
  .de mx:dump-xr-pdf
  . \" Cannot help it
  ..
  .
  .de mx:dump-anchor-pdf
  . \" Outline support
  . ie '\$1'Sh' .pdfbookmark 1 "\$3"
  . el .if '\$1'Ss' .pdfbookmark 2 "\$3"
[^]
  .
  . ie d mx-debug \
  .   pdfhref M -N "\$2" -E "#\$2#"
  . el \
  .   pdfhref M -N "\$2"
^
  ..
  .
  .de mx:dump-ref-pdf
  . pdfhref L -D "\$1" -P "\%" -A "\c" "[\$1]"
^
  ..

And i get active links and a nice table of content outline that
i can toggle via "o" in mupdf.  Only paragraph layout sucks due to
bad breaking of .Ql literal strings.

 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #59461] smoke-test_html_device.sh: make the test more independent of locale

[Steffen Nurpmeso]

Bjarni Ingi Gislason wrote in
 <20201113-180249.sv93188.62...@savannah.gnu.org>:
 |URL:
 |  
 ...
 |locale -a | grep -F -q UTF-8 || exit 77 # skip

That will not do, at least not portably and if you care for older
systems.  At minimum you must test utf8 and utf-8 here.  Better to
conditionalize on "command -v locale" first, it may be missing as
such (but forgot the details, i however do it like that).
Maybe something like "grep -i -q 'utf-\{0,1\}8$'" or so.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [DRAFT] Revised groff ms manual for review

[Steffen Nurpmeso]

Tadziu Hoffmann wrote in
 <20201108120208.gd2...@usm.uni-muenchen.de>:
 |
 |> When you say points are '(about 1/72")', it probably
 |> doesn't hurt to go the extra mile (!) in precision and
 |> say '(1/72.27")'. It's shorter (no need for 'about')
 |> and more correct.
 |
 |Historically, the size of the point varied from region
 |to region.  TeX uses 1/72.27 inches for its point, but
 |as far as I know, groff uses the Postscript point,
 |which is 1/72 inches exactly.

As documented in groff.7.
Floating-point is evil.  I dream of a roff codebase which does not
use it.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Unable to get GROFF_ENCODING to seep through to sourced subfiles

[Steffen Nurpmeso]

Dorai Sitaram wrote in
 <1129728531.3387046.1604937518...@mail.yahoo.com>:
 |I have GROFF_ENCODING set to utf8, but this only works for the main \
 |file processed by groff, not to any subfiles that are sourced via .so .
 |Giving the -s option to groff to force a soelim doesn't work either.  
 |Adding the -k option to force a preconv, whether before or after the \
 |-s option, doesn't work either. (I think regardless of the placement \
 |of -k and -s, -k happens before -s, hence the problem? Perhaps -k should \
 |be forced to happen last?)
 |What does work is
 |soelim mainDoc.ms | preconv | groff ...
 |but it would be nice to avoid the pipelines with either options and/or \
 |environment variable.

This is a groff pipeline fault (or preconv should vanish and any
file opened should internally be handled by the right encoding,
which i think would be even better), also see

  https://lists.gnu.org/archive/html/groff/2017-07/msg00027.html

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20201101042024.gfw4dqth3qlfxxw2@localhost.localdomain>:
 |At 2020-10-21T15:18:29+0200, Steffen Nurpmeso wrote:
 |>> Steffen has withdrawn most/all of his other patches and even after
 |>> reading
 |>
 |> I do not know what this has to do with this bug.
 |
 |As I recall (dimly), you said something at some point that I perhaps
 |misinterpreted--that you were going to work on a project called s-roff
 |and were not going to participate in any further "pull requests", if you
 |will, involving groff.
 |
 |If I misunderstood you, I apologize.

Hm, no, it was just frustrating half a decade ago, and yes,
i still have s-roff in the queue and i really, really want to that
roff package (it will not happen before 2022, that is for sure,
i lost almost the entire year, and will not leave the mailer
i maintain before i reached a state where i can).
I tried to switch to it several times, but one thing or the other
interfered, and then i said i w... ah, whatever.
Anyhow, i synchronized it several times, but stopped with the
current groff release, because the effort was too large.

I keep a list of things i want to cherry pick (or re-create around
the topic due to license issues), that is all.  The rest of the
way i will have to go alone.

 |>> this report a few times I'm not clear on what exactly the problem
 |>> is supposed to be.
 |>>
 |>> The "solution", "drop gnulib", is not likely, especially not during
 |>> an RC cycle.
 |>
 |> Sorry, what??
 |
 |I refer to this statement in the original bug report:
 |
 |"The neat side effect of that is that the entire GNULib can be
 |unhooked and removed from groff(1)."
 |
 |However, you're right that this side effect was not proposed as
 |_necessary_, only possible.

Yes, i think by then groff had nothing to do with GNUlib, and
i posted a binary search table of a few kilobytes which could have
been used as a correct implementation (other possibilities would
exist, i think Xorg and mksh, for example, and Plan9Port and such,
they all implement such binary lookup arrays to satisfy the very
problem in question).
Now that ship has sailed, and GNUlib functions could be used,
i presume.  (I only looked into GNUlib once, at that time, and
there were functions which could have been used ... if i recall
correctly.)

 |>> This could be reopened if we had a simple, reproducible case of
 |>> groff actually misbehaving.
 |>>
 |>>> I think currently groff makes false use of wcwidth(3): if it finds
 |>>> the `unicode' property in a `DESC' file it uses wcwidth(3) to
 |>>> determine the visual width, not taking into account the current
 |>>> locale, but which wcwidth(3) depends upon.
 |>>
 |>> I don't understand[.]
 |>
 |> I am too old for this shit, really.  I therefore agree.
 |
 |I am struggling with the non-idiomatic expression "makes false use".  I
 |can interpret it, but only vaguely.  Also, I may lack domain knowledge
 |here.
 |
 |It's my understanding that Unicode defines a property called "East Asian
 |width"--at least that's what my local unicode(1) command calls it.

No, no, Unicode defines a character width (0, 1 and 2, at the time
i last looked into it, which has been a couple of years indeed).
The problem is anyhow that with preconv Unicode is fed into the
machine, the DESC supports a Unicode property, but then the code
does not care at all and uses the wcwidth(3) function, which works
in correspondance with the currently active locale, which is
false.

I have never ("not yet") looked deep enough to know whether it
matters -- but: having the correct function in place there
(preconv==Unicode, DESC==Unicode, .. character handling==Unicode?)
seems to be the right approach.

 |>> [.] why the width of a Unicode character would be locale-dependent.
 |>> As I understand it, the width property (half-width, full-width,

And zero-width.

 |>> undefined) is determined on a per-codepoint basis and while it might
 |>> vary, there's no reason to expect it to vary based on the _locale_.
 |>> More likely, I think, it would vary due to choices taken by a font
 |>> vendor, and people using the font would be forced to adapt.
 |
 |Thinking about this some more, the possibility of an "ambiguous" or
 |"undefined" character width at the UCS level could mean that the locale
 |is permitted to determine this parameter.

Unicode does not do that.  Again, long time, but if i recall
correctly anything which is not defined otherwise is normal width.

 |>> Closing.
 |>
 |> I think there was a ML thread by the time i opened the bug report,
 |> where the according GNUlib function that could simply be used to
 |> correctly implement the given was named.
 |
 |Hmm. It would be good to find this.  I wonder if Dave Ke

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

[Steffen Nurpmeso]

Hello,

and sorry for the late reply.

G. Branden Robinson wrote in
 <20201101035740.2azpyoxgyrd6ozdl@localhost.localdomain>:
 |Hi, Steffen.  Coming back to an old item of business.
 |
 |At 2020-09-29T19:12:00+1000, G. Branden Robinson wrote:
 |> At 2020-09-28T22:57:37+0200, Steffen Nurpmeso wrote:
 |>> Rereading the first messages of the thread ... i reiterated one of
 |>> Ingo's statements in fact.
 |> 
 |> Yes, I think the earlier discussions were pretty comprehensive.
 |> 
 |> I haven't brought CS and CT support to groff_mdoc yet but I haven't
 |> forgotten.  Savannah #59106 is nagging me like a toothache.
 |
 |I fixed #59106 but more bugs lurk with various combinations of cR and
 |the C register.  However, they don't seem to be regressions but rather
 |to be of rather long tooth, and given a paucity of evidence of other
 |users finding and complain about them, I think they can wait for the
 |post-groff-1.23.0 era.
 |
 |CS and CT are now supported in mdoc, as of
 |9fa2aed4facae1c94cc339b891aca25c57074551, which I've just pushed.

Thank you.

No offense meant (!), but you possibly should adjust

  if (mode == STRING_DOWNCASE)
nc = tolower(c);
  else
nc = toupper(c);

to 

  if ((unsigned char)c & 0x80) {
del mac;
error("cannot apply string case transformation to non-ASCII ('%1')",
 s.contents());
skip_line();
return;
  } else if (mode == STRING_DOWNCASE)
nc = tolower(c);
  else
nc = toupper(c);

before the release is out and people start creating manual pages
with "normal" casing and these requests become used.
Yes, i wanted to look for (non-standard?!) isascii(3), but like so
is stumbled upon problems (just try "git grep -i isascii master"),
there are quite some

  #ifdef isascii
  #define ISASCII(c) isascii(c)
  #else
  #define ISASCII(c) (1)
  #endif

and that is of course plain wrong, it should be

  #ifdef isascii
  #define ISASCII(c) isascii(c)
  #else
  #define ISASCII(c) (((unsigned char)c & 0x80) == 0)
  #endif

 |I've also tightened the synchrony between groff man(7) and mdoc(7)
 |regarding registers and strings used for rendering parameters.  They
 |haven't diverged to date, and with this work it's less likely that they
 |will in the future.
 |
 |Regards,
 |Branden

 --End of <20201101035740.2azpyoxgyrd6ozdl@localhost.localdomain>

Good night!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #57218] [PATCH] Reproducible builds support is broken and embeds timezone

[Steffen Nurpmeso]

Hu-hu!

Ingo Schwarze wrote in
 <20201022-173721.sv97361.91...@savannah.gnu.org>:
 |Follow-up Comment #4, bug #57218 (project groff):
 |
 |I think groff should not write %%CreationDate into PostScript files it
 |creates.  Not because of reproducible builds, which i consider a useless \
 |and
 |even detrimental feature, but because of privacy concerns.  That would also
 |solve this so-called "problem" as a side effect.
 |
 |Basically, it amounts to something like deleting these lines from
 |src/devices/grops/ps.cpp:
 |
 |  {
 |fputs("%%CreationDate: ", out.get_file());
 |  #ifdef LONG_FOR_TIME_T
 |long
 |  #else
 |time_t
 |  #endif
 |t = current_time();
 |fputs(ctime(), out.get_file());
 |}

I think better it would be to check for
getenv("SOURCE_DATE_EPOCH"), and use a fixed constant if that is
true.  (For the MUA i maintain i use SOURCE_DATE_EPOCH=844221007
in mx-test.sh, i have forgotten why, hmm.)
It is a pity that reproducible-builds.org only goes for that
single constant, and does not offer finer control for tests etc.

Ciao and good night,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #55449] [PATCH] Use FILENAME_MAX in maxfilename.cpp

[Steffen Nurpmeso]

Ingo Schwarze wrote in
 <20201021231159.ge12...@athene.usta.de>:
 ...
 |Now, arguably, if pathconf(3) fails, which can easily happen if the
 |input argument is garbage, the function should not return (size_t)-1,
 |which is a large value.
 ...
 |Anyone willing to fix this particular bug?

I have this (preliminary) in s-roff:

  /* POSIX 2008/Cor 1-2013 defines a minimum of 14 for _POSIX_NAME_MAX */
  #ifndef NAME_MAX
  # ifdef _POSIX_NAME_MAX
  #  define NAME_MAX _POSIX_NAME_MAX
  # else
  #  define NAME_MAX 14
  # endif
  #endif
  #if NAME_MAX + 0 < 8
  # error NAME_MAX is too small
  #endif
  
  /* POSIX 2008/Cor 1-2013 defines for
   * - _POSIX_PATH_MAX a minimum of 256
   * - _XOPEN_PATH_MAX a minimum of 1024
   * NFS RFC 1094 from March 1989 defines a MAXPATHLEN of 1024, so we really
   * should avoid anything smaller than that! */
  #ifndef PATH_MAX
  # ifdef MAXPATHLEN
  #  define PATH_MAX MAXPATHLEN
  # else
  #  define PATH_MAX 1024
  # endif
  #endif
  #if PATH_MAX + 0 < 1024
  # undef PATH_MAX
  # define PATH_MAX 1024
  #endif
  
  uz
  su_file_name_max(char const *dname){
 uz rv;
  #ifdef HAVE_PATHCONF
 long sr;
  #endif
 NYD_IN;
 UNUSED(dname);
 ASSERT_NYD(dname != NIL, rv = NAME_MAX);
  
  #ifdef HAVE_PATHCONF
 if((sr = pathconf(dname, _PC_NAME_MAX)) != -1)
rv = S(uz,sr);
 else
  #endif
rv = NAME_MAX;

 NYD_OU;
 return rv;
  }
  
  uz
  su_path_name_max(char const *dname_or_nil){
 uz rv;
  #ifdef HAVE_PATHCONF
 long rv;
  #endif
 NYD_IN;
 UNUSED(dname_or_nil);
  
  #ifdef HAVE_PATHCONF
 if(dname_or_nil == NIL)
dname_or_nil = "/"; /* TODO dirsep configurable */
  
 if((sr = pathconf(dname_or_nil, _PC_PATH_MAX)) != -1)
rv = S(uz,sr);
 else
  #endif
rv = PATH_MAX;

 NYD_OU;
 return rv;
  }

Note also -1 not < 1.  Hmm.
I have in FIXME

  ->su/io.h: Windows: FILENAME_MAX in 
stdio.h;stdlib.h:_MAX_DIR,_MAX_DRIVE,_MAX_FNAME,_MAX_PATH

So for going Cygwin (isn't it going to die now that Windows seems
to ship an entire Linux subsystem all the time?  I have no idea!!)
i was thinking about the latter things in the #ifndef paths.

Good night,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

 |Steffen has withdrawn most/all of his other patches and even after reading

I do not know what this has to do with this bug.

 |this report a few times I'm not clear on what exactly the problem is supposed
 |to be.
 |
 |The "solution", "drop gnulib", is not likely, especially not during an RC
 |cycle.

Sorry, what??

 |This could be reopened if we had a simple, reproducible case of groff actually
 |misbehaving.
 |
 |> I think currently groff makes false use of wcwidth(3): if it finds the
 |`unicode' property in a `DESC' file it uses wcwidth(3) to determine the visual
 |width, not taking into account the current locale, but which wcwidth(3)
 |depends upon.
 |
 |I don't understand[.]

I am too old for this shit, really.  I therefore agree.

 |[.] why the width of a Unicode character would be
 |locale-dependent.  As I understand it, the width property (half-width,
 |full-width, undefined) is determined on a per-codepoint basis and while it
 |might vary, there's no reason to expect it to vary based on the _locale_.
 |More likely, I think, it would vary due to choices taken by a font vendor, and
 |people using the font would be forced to adapt.
 |
 |Closing.

I think there was a ML thread by the time i opened the bug report,
where the according GNUlib function that could simply be used to
correctly implement the given was named.
Then that piece of cake would be correct, despite possibly
non-capable surroundings.
Just my one cent.

Out for cycling, ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

 |Steffen has withdrawn most/all of his other patches and even after reading

I do not know what this has to do with this bug.

 |this report a few times I'm not clear on what exactly the problem is supposed
 |to be.
 |
 |The "solution", "drop gnulib", is not likely, especially not during an RC
 |cycle.

Sorry, what??

 |This could be reopened if we had a simple, reproducible case of groff actually
 |misbehaving.
 |
 |> I think currently groff makes false use of wcwidth(3): if it finds the
 |`unicode' property in a `DESC' file it uses wcwidth(3) to determine the visual
 |width, not taking into account the current locale, but which wcwidth(3)
 |depends upon.
 |
 |I don't understand[.]

I am too old for this shit, really.  I therefore agree.

 |[.] why the width of a Unicode character would be
 |locale-dependent.  As I understand it, the width property (half-width,
 |full-width, undefined) is determined on a per-codepoint basis and while it
 |might vary, there's no reason to expect it to vary based on the _locale_.
 |More likely, I think, it would vary due to choices taken by a font vendor, and
 |people using the font would be forced to adapt.
 |
 |Closing.

I think there was a ML thread by the time i opened the bug report,
where the according GNUlib function that could simply be used to
correctly implement the given was named.
Then that piece of cake would be correct, despite possibly
non-capable surroundings.
Just my one cent.

Out for cycling, ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Learning troff - where to start?

[Steffen Nurpmeso]

Morten Bo Johansen wrote in
 :
 |On 2020-10-14 Peter Schaffter wrote:
 |
 |> What difficulties do you have entering UTF8 directly into the
 |> source?  I've produced groff documents in most of the Western
 |> European and Scandinavian languages
 |
 |I thought we Scandinavians were also considered part of Western
 |Europe, including our languages?
 |
 |;-)

Finnish is definetely not as far as i know, and some people count
Finland to Scandinavia.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Learning troff - where to start?

[Steffen Nurpmeso]

Greg 'groggy' Lehey wrote in
 <20201013232627.gb24...@eureka.lemis.com>:
 |On Tuesday, 13 October 2020 at 22:49:03 +0200, J.-J. wrote:
 |> Le mardi 13 octobre 2020 à 14:41 +0200, Johann Höchtl a écrit :
 |>> * What would be a good starting point (tutorial) into troff and its
 |>> core principles?
 |>>
 |>> * What is the canonical documentation of troff all the existing
 |>> implementations seem to derive from and describe their deltas in
 |>> their respective documentation?
 |>
 |> Here is in my opinion the best book on the subject
 |> (and it's now  FREE!) :
 |>
 |> https://www.oreilly.com/openbook/utp/
 |
 |An excellent book, and one that I have used a lot.  But nobody can
 |claim that it's up-to-date (it predates groff), and there are many
 |features in groff that weren't in the troff version described.  Isn't
 |it sad that nothing more modern is available?

Ha!  Twenty years ago when my wonderful TeX package got lost and
i had to rapidly implement something and decided due to
frustration to do something entirely different i went to the local
book store (and i still do not do such things over the net), and
they could not offer just about anything.  Solschenizyn, also.
Later.  All that before the advent of on-demand printing, however.

I would point to the groff info manual, and the groff manual
pages.  It is a bit tough to get you going, but if you understand
there are traps and page dimensions then this surely is a starter.
Other than that you need to know what you want, anyway.

Fonts are hard, device files are hard, the process separation is
hard (and a show stopper), but then there is lout and the lua-
implemented thing which appears to be really great and cool,
unfortunately i have forgotten the name of it.  Ralph surely knows
that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #45034] [PATCH] mdoc(7): add support for the mdocmx(7) reference extension

[Steffen Nurpmeso]

Dave wrote in
 <20201013-025534.sv93119.11...@savannah.gnu.org>:
 |Update of bug #45034 (project groff):
 |
 | Summary: mdoc(7): add support for the mdocmx(7) reference
 |extension => [PATCH] mdoc(7): add support for the mdocmx(7) reference
 |extension

Likewise, i am not going to rebase this onto the myriads of style
changes that have been introduced in later groff versions.
This works wonderful in practice by the way, free anchors and
references in manual pages, even in $PAGER, i like it!
Shall i ever come to my s-roff, it is included there.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #45034] [PATCH] mdoc(7): add support for the mdocmx(7) reference extension

[Steffen Nurpmeso]

Dave wrote in
 <20201013-025534.sv93119.11...@savannah.gnu.org>:
 |Update of bug #45034 (project groff):
 |
 | Summary: mdoc(7): add support for the mdocmx(7) reference
 |extension => [PATCH] mdoc(7): add support for the mdocmx(7) reference
 |extension

Likewise, i am not going to rebase this onto the myriads of style
changes that have been introduced in later groff versions.
This works wonderful in practice by the way, free anchors and
references in manual pages, even in $PAGER, i like it!
Shall i ever come to my s-roff, it is included there.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #43541] [PATCH] FILE* encapsulation via class; compression support for input files

[Steffen Nurpmeso]

Dave wrote in
 <20201013-025522.sv93119.18...@savannah.gnu.org>:
 |Update of bug #43541 (project groff):
 |
 | Summary: FILE* encapsulation via class; compression \
 | support
 |for input files => [PATCH] FILE* encapsulation via class; compression \
 |support
 |for input files

You you have to close this ticket, i am not going to rebase this
onto new groff.  Shall i ever come to my s-roff, which i hope, it
is included there (with the one, two or three bugs of the original
submission fixed).

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

Dave wrote in
 <20201013-025509.sv93119.83...@savannah.gnu.org>:
 |Update of bug #42233 (project groff):
 |
 | Summary: wcwidth(3) used on UCS4/UTF-32 codepoints \
 | => [PATCH]
 |wcwidth(3) used on UCS4/UTF-32 codepoints

My patch is based on old groff and even more very outdated
Unicode.  Since you know use that GNU lib thing you could easily
adopt this to call its according function, of course.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

[Steffen Nurpmeso]

Dave wrote in
 <20201013-025509.sv93119.83...@savannah.gnu.org>:
 |Update of bug #42233 (project groff):
 |
 | Summary: wcwidth(3) used on UCS4/UTF-32 codepoints \
 | => [PATCH]
 |wcwidth(3) used on UCS4/UTF-32 codepoints

My patch is based on old groff and even more very outdated
Unicode.  Since you know use that GNU lib thing you could easily
adopt this to call its according function, of course.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20200927063701.vj6bg474km3ofpfh@localhost.localdomain>:
 |At 2020-09-16T01:21:14+0200, Steffen Nurpmeso wrote:
 |> C64 had no login.  And DMR would not have used it.
 |> I am all with Tadziu Hoffmann in this thread.
 |
 |Did Tadziu comment on this thread?  I don't see any such message in the
 |list archive in my mail folder... :-?

  https://lists.gnu.org/archive/html/groff/2018-12/msg00150.html
  https://lists.gnu.org/archive/html/groff/2018-12/msg00155.html

The former contains

  This tells us that the capitalization was intended as
  a presentational effect.

It is interesting that Doug McIlroy as one of the main (or even
sole) editors / reviewers of early manuals did not take part in
this thread.
Rereading the first messages of the thread ... i reiterated one of
Ingo's statements in fact.

Good night, Branden.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20200915183356.3xt3ywitpzifixm2@localhost.localdomain>:
 |At 2020-09-15T13:59:04+0200, Steffen Nurpmeso wrote:
 |> Just out of interest: why do you change an omnipresent idiom that
 |> is in use for standard section headers in Unix manual pages since
 |> at least fourty years?
 ...
 |But to answer your question in this historical spirit whence it was
 |posed: for the same reason that Unix was case-sensitive internally while
 |still being operable with uppercase-only terminals.  Remember this?
 |
 |  login: DMR
 |  PASSWORD:

C64 had no login.  And DMR would not have used it.
I am all with Tadziu Hoffmann in this thread.

  ...
 |> This commit changes the world and will affect the generations of
 |> programmers to come, shall they experience it.
 |
 |It is a change with some impact, yes, but my intention is that people be
 |able to see fully-capitalized page titles and section headings without
 |much effort on their part if that is their desire.  That is why I
 |implemented "CT" and "CS" registers in groff_man(7).  Please see the
 |following commits.
 |
 |  https://lists.gnu.org/archive/html/groff-commit/2019-09/msg9.html
 |  https://lists.gnu.org/archive/html/groff-commit/2019-09/msg00018.html

I had totally forgotten about that.

 |I intend to do the same for groff_mdoc(7); it already happily has
 |compatible configuration semantics, and I've recently been increasing
 |the parallels between our mdoc and man implementations in this respect.
 |Here's an example.
 |
 |  https://lists.gnu.org/archive/html/groff-commit/2020-08/msg00075.html
 |
 |The only reason you don't already see CT and CS support in groff_mdoc(7)
 |is simply that I haven't done it yet and it wasn't logically necessary
 |for the change set I've already made.  I'll move this work higher on the
 |priority list since others may be as distressed as you were.

I see.  For Ingo's mandoc it will be an either/or thing i think.
Well.  I have no other opinion than what i expressed already.
More and more software packages only generate manual pages, in
fact more and more do not even ship with generated manual pages
but leave that up to the packager, as a build time dependency.  So
it is.

  ...
 |> Well, now that you say it have fuzzy memories .. and refreshed
 |> them.  Used to and living in text consoles only (though in
 |> graphical environment, again) i .. have mixed feelings, because
 |> now i am used to this notation for over twenty years.  I think it
 |> does make sense for several output devices, notably PDF, maybe
 |> even HTML, or markdown even, but for manual page output i feel
 |> differently.  Anyhow, if i make it, maybe i even follow but place
 |> a switch in site- and user-local configurations, for noone to find
 |> it ^_^.
 |
 |Except for the "no one being able to find it" part, that is precisely
 |what is intended.  From groff_man_style(7) on the master branch we have:
 |
 | /usr/local/share/groff/site-tmac/man.local
 |Put local changes and customizations into this file.
 |
 |   .\" Use narrower indentation on terminals and similar.
 |   .if n .nr IN 4n
 |   .\" Put only one space after the end of a sentence.
 |   .ss 12 0 \" See groff(7).
 |   .\" Keep pages narrow even on wide terminals.
 |   .if n .if \n[LL]>78 .nr LL 78n
 |
 |On multi-user systems, it is more considerate to users whose
 |preferences may differ from the administrator's to be less ag‐
 |gressive with such settings, or to permit their override with a
 |user-specific man.local file.  One way to achieve the latter is
 |by placing the following at the end of /usr/local/share/groff/
 |site-tmac/.man.local.
 |   .so \V[HOME]/.man.local

More and more projects support $XDG_DATA_HOME aka _CONFIG_.

 |Note that the above request will produce a warning if $HOME/
 |man.local does not exist; you may wish to include one in /etc/
 |skel or an equivalent account configuration system.  Further‐
 |more, a security-sandboxed man(1) program may lack permission to
 |open the file.
 |
 |I reckon I could add
 |   .\" Put page titles and section headings in full caps.
 |   .if n .nr CT 1
 |   .if n .nr CS 1
 |to the above.  Do you think that would be helpful?

Well i personally .. would do it like this.  Or better, i would
switch for .T == pdf or html and keep the default.  But that is
really just me.  Shall anyone use scripts they need to be
adjusted, for example.  A quickly thought hack would be a script
called synopsis which does

 man "$1" | sed -e '/^SYNO/,/^[A-Z]/p;d'

which goes two to far, but .. what i mean.

Ciao and good night,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

[Steffen Nurpmeso]

Hallo Ingo.

Ingo Schwarze wrote in
 <20200915133505.gi1...@athene.usta.de>:
 |Hi Steffen,
 |
 |Steffen Nurpmeso wrote on Tue, Sep 15, 2020 at 01:59:04PM +0200:
 |
 |> Just out of interest: why do you change an omnipresent idiom that
 |> is in use for standard section headers in Unix manual pages since
 |> at least fourty years?  This commit changes the world and will
 |> affect the generations of programmers to come, shall they
 |> experience it.  I mean, it is ok, why not, it only strives me as
 |> mysterious.  And i think i will unsubscribe now, shall i ever find
 |> time for my groff clone, .. i do not know.  Not that it matters
 |> anyway.
 |
 |The advantages of "Name" compared to "NAME" for separation of content
 |and presentation, for typographic quality, and in particular for
 |accessibility were discussed at length on this list, please consult
 |the archives.

Well, now that you say it have fuzzy memories .. and refreshed
them.  Used to and living in text consoles only (though in
graphical environment, again) i .. have mixed feelings, because
now i am used to this notation for over twenty years.  I think it
does make sense for several output devices, notably PDF, maybe
even HTML, or markdown even, but for manual page output i feel
differently.  Anyhow, if i make it, maybe i even follow but place
a switch in site- and user-local configurations, for noone to find
it ^_^.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20200915110201.e2d1820...@vcs0.savannah.gnu.org>:
  ...
 |commit 0438b1b905ebe9ac5fc678af06db911d25c3a030
 |Author: G. Branden Robinson 
 |AuthorDate: Mon Sep 14 21:18:02 2020 +1000
 |
 |mdoc: Accept mixed-case section headings.
 |
 |* tmac/mdoc/doc-common-u (doc-prepare-section-heading): New macro
 |  defines new string doc-sec-head to anable recognition of mixed-case
 |  section headings in mdoc man pages.  For example, "Name" and
 |  "Description" are now recognized in addition to "NAME" and
 |  "DESCRIPTION".

Just out of interest: why do you change an omnipresent idiom that
is in use for standard section headers in Unix manual pages since
at least fourty years?  This commit changes the world and will
affect the generations of programmers to come, shall they
experience it.  I mean, it is ok, why not, it only strives me as
mysterious.  And i think i will unsubscribe now, shall i ever find
time for my groff clone, .. i do not know.  Not that it matters
anyway.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

Re: manlint?

[Steffen Nurpmeso]

Sergiusz Pawlowicz wrote in
 :
 |Hi,
 |is there anything like "manlint"?
 |A tool which verifies the syntax of a man file and eventually points \
 |to errors?

Use "mandoc -Tlint".  It has flaws but is the best i know.
You can also use FreeBSD's igor, it is meant for mdoc macros but
nonetheless can be a helpful tool.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Plan 9 man added a new macro for man page references

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20200815112655.xow4f3d4dcdaiaui@localhost.localdomain>:
 |[CCing Russ Cox out of the blue; Russ, I work on GNU roff]
 |
 |Plan 9 went and did an interesting thing[1].  They implemented a macro
 |just for man page cross-references.
  ...
 |[1] https://github.com/9fans/plan9port/commit/977b25a76ae8263e53fb4eb1ab\
 |fc395769f23e3d

Oh hey, really great that someone pushes forward roff macros.
HTML only for now, but still!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Groff macro to make .UR and .UE links clickable in PDF?

[Steffen Nurpmeso]

Michael Pirkola wrote in
<20200717123254.3aff0148@walrus>:
 |On Sat, 11 Jul 2020 09:28:45 +0100
 |Colin Watson  wrote:
 |
 |> On Fri, Jul 10, 2020 at 11:26:46AM -0400, Steve Izma wrote:
 |>> I think it's an abomination that a man page extends it's line
 |>> length to fit the width of the terminal; built into the macros
 |>> should be a 65- or 70 character maximum width.  
 |> 
 |> I'd be willing to take a bug report about the way that man-db does
 |> this by default; it's a change I adopted from Andries Brouwer's man
 |> way back in 2001, and I'm certainly prepared to entertain the idea
 |> that a change I made nearly half my life ago might have been wrong.
 |> (However, I would like it as a bug report on e.g.
 |> https://savannah.nongnu.org/bugs/?group=man-db rather than buried in a
 |> mailing list thread, because my ability to keep track of random
 |> threads isn't quite what it used to be.)
 |> 
 |
 |While I agree that a shorter line length is more readable, I frequently
 |exit a manpage, maximise the terminal window, then reopen it when my
 |goal is to quickly scan the page for a relevant option.  I find argument
 |lists in particular much easier to look through when they take up fewer
 |lines.  Manpages in particular are less likely to have large paragraphs
 |of text, and a long line length commonly reduces an entire topic to a
 |single line which I also find more convenient.
 |
 |Just my 2¢.

I also have $MANWIDTH set for long.

  $ man man|grep -A 8 MANWIDTH
   MANWIDTH
  If $MANWIDTH is set, its value is used as the  line  length  for
  which  manual pages should be formatted.  If it is not set, man‐
  ual pages will be formatted with a line  length  appropriate  to
  the  current terminal (using the value of $COLUMNS, and ioctl(2)
  if available, or falling back to 80  characters  if  neither  is
  available).   Cat pages will only be saved when the default for‐
  matting can be used, that is when the terminal  line  length  is
  between 66 and 80 characters.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: .Xr mdoc(7) from groff_mdoc(7)?

[Steffen Nurpmeso]

I am off-topic.

Ingo Schwarze wrote in
<20200625214812.gf90...@athene.usta.de>:
 |given that two authoritative manual pages for the mdoc language
 |exist that describe exactly the same language, but in a somewhat
 ...
 |  The manual page groff_mdoc(7): https://man.voidlinux.org/groff_mdoc
 |  contained in the "groff" package documents exactly the same language
 |  in a somehwat different style.

Oh my god.

  ...
 |+.Pp
 |+The manual page
 |+.Lk https://man.openbsd.org/mdoc.7 "mdoc(7)"
 |+contained in the
 |+.Dq mandoc
 |+package documents exactly the same language in a somehwat different style.

Oh my god, II.
somewhat is a typo here, Ingo.

My humble opinion, luckily out-of-project.
The day the existence of the additional mandoc page starts
documenting a different language is the day that would have become
a problem.
Why only voidlinux?  What about all other humans of all sex and
colour who are main and everywhere not master and slave and
upstream / downstream?  That is sheer anarchy!
I think mdoc(7) is a roff macro package, with the potential to use
all roff commands, and therefore it belongs into roff software.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Fwd: Re: Groff macro to make .UR and .UE links clickable in PDF?

[Steffen Nurpmeso]

--- Forwarded from B 9  ---
Date: Fri, 19 Jun 2020 13:55:30 -0700
From: B 9 
To: Steffen Nurpmeso 
Subject: Re: Groff macro to make .UR and .UE links clickable in PDF?
Message-ID: <20200619205530.n0y90%hacke...@member.fsf.org>

Steffen Nurpmeso  wrote:

> Yes i am reading this list and yes this has been implemented in
> the past (in 2014).  Unfortunately it has not been merged.

Can you please send me more information about this so I can find it?


> And your mailer i available in a newer version which fixes
> hundreds of bugs, and adds some nice features.

My mailer? Why do you mention my mailer? Do you use s-nail?


>  |But, as I said, I have no idea how hard it would be to add footnote
>  |output to mdoc. It might not even be feasible.
> 
> Pretty easy i presume, at least in the mdoc macros.

Ah, easy for some. Not for me. I'm new to troff/groff. Do you think
you could quickly write an example for me?


>  |Also, I'm more concerned at the moment that I can't find any way to
>  |attach hyperlinks to text in the middle of sentences using mdoc. Lk's
>  |addition of a newline and colon and insistence on always printing the
>  |URL makes me think it is the wrong tool. Is there another option I'm
>  |missing? Perhaps implementing a new macro similar to Lk?
>  |
>  |Thank you,
> 
> Please.  Here you are.

I am very confused. "Here I am" what? Why "Please"? Did you mean to
attach the macros to your e-mail? If so, I didn't see them.


Thanks!

--b9
 -- End forward <20200619205530.n0y90%hacke...@member.fsf.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Groff macro to make .UR and .UE links clickable in PDF?

[Steffen Nurpmeso]

B 9 wrote in
<20200619061008.okwcr%hacke...@member.fsf.org>:
 |Since mdoc is a "semantic markup language", I presumed it would have
 |some way to specify a hyperlink in running text that won't (to the
 |best of mdoc's abilities) interfere with the flow of the text. The
 |exact implementation would be chosen by mdoc based on what output
 |device is selected. It could be something like this:

Yes i am reading this list and yes this has been implemented in
the past (in 2014).  Unfortunately it has not been merged.
And your mailer i available in a newer version which fixes
hundreds of bugs, and adds some nice features.

 |   HTML, use a link;
 |   nroff, drop the URL;¹
 |   PDF, use both a link and a footnote in case it gets printed.
 |
 |For printed output, the tried and true method for the last
 |few centuries has been footnotes, so it makes sense for mdoc to
 |support that, if possible.
 |
 |But, as I said, I have no idea how hard it would be to add footnote
 |output to mdoc. It might not even be feasible.

Pretty easy i presume, at least in the mdoc macros.

 |Also, I'm more concerned at the moment that I can't find any way to
 |attach hyperlinks to text in the middle of sentences using mdoc. Lk's
 |addition of a newline and colon and insistence on always printing the
 |URL makes me think it is the wrong tool. Is there another option I'm
 |missing? Perhaps implementing a new macro similar to Lk?
 |
 |Thank you,

Please.  Here you are.

 |--b9
 |
 |_
 |¹ Or, is it possible to have footnotes in screen form? Maybe using
 |  bracketed numbers [42]. 
 --End of <20200619061008.okwcr%hacke...@member.fsf.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: man Macro Package and pdfmark

[Steffen Nurpmeso]

Ingo Schwarze wrote in
<20200214184532.gj92...@athene.usta.de>:
 |Hi Jeff,
 |
 |Jeff Conrad wrote on Thu, Feb 13, 2020 at 03:45:10PM -0800:
 |
 |> A major drawback to manual pages formatted using the man macros is the
 |> lack of bookmarks in a PDF file.  A quick and dirty way to get bookmarks
 |> appears to be adding
 |> 
 |> .am SH
 |> .pdfbookmark 1 "\&\\$*"
 |> ..
 |> .am SS
 |> .pdfbookmark 2 "\&\\$*"
 |> ..
 |> 
 |> to the beginning of the man page source
 |
 |Just don't do that.  Never use low-level roff stuff in manual pages,
 |don't even think about it.  This makes your manual pages non-portable.
 |
 |If you want bookmark support for PDF output from man(7) files,
 |that needs to be done in the file an-old.tmac, but in a careful
 |way that does not cause incompatibilities and that does not
 |require including any other macro files.  It may be tricky,
 |but it may well be possible.

Yes, i have already mailed him in private.  It actually takes four
lines of code and produces good results, i could not reproduce his
problems.  I asked him whether he wants to open an issue, i for
myself will add (at least) the four lines when i finally, finally
come to my own roff port.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: man Macro Package and pdfmark

[Steffen Nurpmeso]

Jeff Conrad wrote in
:
 |A major drawback to manual pages formatted using the man macros is the
 |lack of bookmarks in a PDF file.  A quick and dirty way to get bookmarks
 |appears to be adding
 |
 |.am SH
 |.pdfbookmark 1 "\&\\$*"
 |..
 |.am SS
 |.pdfbookmark 2 "\&\\$*"
 |..

Why quick and dirty?  I am using this regulary for my mdocmx(7)
macros on top of normal mdoc(7) with groff 1.22.3 (since i have
not ported the enhance request to 1.22.4):

  .de mx:dump-anchor-pdf
  . \" Outline support
  . ie '\$1'Sh' .pdfbookmark 1 "\$3"
  . el .if '\$1'Ss' .pdfbookmark 2 "\$3"
  .
  . ie d mx-debug \
  .   pdfhref M -N "\$2" -E "#\$2#"
  . el \
  .   pdfhref M -N "\$2"
  ..

 |to the beginning of the man page source (the PDFHREF.VIEW.LEADING
 |register needs a slight increase to make the heading texts visible when
 |clicking a bookmark).
 |
 |But this results in the message
 |
 |"... can't transparently output node at top level";
 |
 |if there are many sections and subsections, there are a lot of messages.

I see exactly five such messages with a huge manual page with 666
anchors and thousands (!) of links.

 |It doesn't seem to cause much harm--the PDF bookmarks are duly created--
 |but the messages are distracting, and may make it easier to miss a real
 |error.  I don't get the messages if I call pdfbookmark directly from the
 |man page source rather than adding them to the macros; this certainly is
 |a solution, but it does require a fair bit of extra coding that adds
 |clutter to the document source.

For mdoc macros there are a lot of other messages which are
distracting, however.

 |I've looked at pdfmark.tmac and a couple of the groff source files, but
 |haven't been able to figure out what's happening.
 |
 |I get the same message using spdf (e.g., formatting the pdfmark
 |reference manual); is this just something one does not worry about?

That is an interesting question.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #57592] [PATCH] tmac/: Add a warning

[Steffen Nurpmeso]

Bjarni Ingi Gislason wrote in <20200113-183655.sv93188.51...@savannah.gn\
u.org>:
 |URL:
 |  
 ..
 |From: Bjarni Ingi Gislason 
 |Date: Mon, 13 Jan 2020 18:10:39 +
 |To: bug-groff@gnu.org
 |Subject: [PATCH] tmac/: Add a warning
 |
 |  Some macro files have an '.nx' request
 |to avoid to have all of it read a second time.
 |
 |  Add a warning to point out this unwanted situation.

I do not think this is a good idea in general, since this means
you cannot blindly include some file to ensure it is present or
not.  Say you want to include some picture in a report and include
the macro set which allows that, but it was already sourced (maybe
due to some condition) in another macro set.  Now you have
a pointless warning.

The way it is done right now is how most languages ensure that
files get included once only, may it be C headers or even TeX:

  \csname xy_IS_LOADED\endcsname
  \global\let\xy_IS_LOADED\endinput

 |  Two files, "pdfpic.tmac" and "pspic.tmac",
 |are automatically read,
 |as they are used in the file "tmac/troffrc".

And that users can adjust the way they want, no?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: pic anomalies

[Steffen Nurpmeso]

Ingo Schwarze wrote in <20191227212705.gi66...@athene.usta.de>:
 |Hi Doug,
 |
 |Steffen Nurpmeso wrote on Fri, Dec 27, 2019 at 06:45:23PM +0100:
 |
 |> Should be handled by [...]
 |
 |I believe the first patch that got sent to the list is incorrect.
 |
 |The parser in src/pre-pic/pic.y already parses '%%' correctly, so

The parser is total crap and uses two string searches.  It will
not stay that way here.

 |there is no need to change the parsing.  Only the assignment to
 |one_format needs to be corrected.  Besides, the "continue;" that
 |was inserted feels premature; i think appending to "result" at the
 |end of the while loop is still needed.

The patch was correct i would say, and especially avoids going
over a snprintf() call when there is only an escaped format
trigger to handle.  But, despite that, you are absolutely right
about the wording issue.

 |The existing text in doc/pic.ms uses the term "format string"
 |incorrectly.  That's the complete first argument to sprintf(3).
 |Saying that the format string must be "%e" would mean that the
 |argument cannot contain any additional characters.  The correct
 |term for something like "%e" according to the C standard is
 |"conversion specification".  Note that according to the C standard,
 |"%%" is also a conversion specification, so there is no need to
 |describe it using more words.
 |
 |With respect to src/preproc/pic/pic.1.man, "0123456789." are not
 |flags, so let's use a better wording.
 |
 |Doug, thank you for your report.  Could you please test and confirm
 |that this patch fixes all the issues you found?

Thanks.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: pic anomalies

[Steffen Nurpmeso]

Doug McIlroy wrote in <201912271608.xbrg84jr128...@tahoe.cs.dartmouth.edu>:
 |The description of sprintf in the man page pic(1) does not
 |reveal that only a few format codes are permitted.
 |
 |Eric Raymond's "Making Pictures With GNU PIC" says only
 |%,%e,%f,%g are  permitted. But what does a bare % mean?
 |
 |In fact pic rejects a bare %. However it does accept
 |%%, which is supposed to print a single %. Pic,
 |however prints %%.
 |
 |So I believe we have
 |1. An incompleteness in pic(1)
 |2. An error in "Making Pictures With GNU PIC"
 |3. An error in pic itself

Should be handled by

  diff --git a/doc/pic.ms b/doc/pic.ms
  index da95de80..89ba9f37 100644
  --- a/doc/pic.ms
  +++ b/doc/pic.ms
  @@ -1652,7 +1652,8 @@ GNU \fBgpic\fP also documents a one-argument form or 
rand,
   version.
   .PP
   The function \fBsprintf()\fP behaves like a C \fIsprintf\/\fP(3)
  -function that only takes %, %e, %f, and %g format strings.
  +function that only takes the format strings %e, %E, %f, %g and %G,
  +as well as %% for printing a raw percent character.
   .
   .
   .NH 1
  diff --git a/man/pre-pic.1.in b/man/pre-pic.1.in
  index aae228a4..4edfe548 100644
  --- a/man/pre-pic.1.in
  +++ b/man/pre-pic.1.in
  @@ -795,6 +795,11 @@ this will produce the arguments formatted according to
   which should be a string as described in
   .BR printf (3)
   appropriate for the number of arguments supplied.
  +Only the flags
  +.B #-+ 0123456789.,
  +and the formats
  +.B eEfgG%
  +are supported.
   .
   .LP
   The thickness of the lines used to draw objects is controlled by the
  diff --git a/src/pre-pic/pic.y b/src/pre-pic/pic.y
  index c6e4c0f5..e107b7c9 100644
  --- a/src/pre-pic/pic.y
  +++ b/src/pre-pic/pic.y
  @@ -1889,6 +1889,11 @@ char *do_sprintf(const char *form, const double *v, 
int nv)
 string one_format;
 while (*form) {
   if (*form == '%') {
  +  if(form[1] == '%'){
  +result += '%';
  +form += 2;
  +continue;
  +  }
 one_format += *form++;
 for (; *form != '\0' && su_cs_find_c("#-+ 0123456789.", *form) != NIL;
 form++)

in my GPLv2 tree, or as attached for groff v1.22.4.
(I have only compile-tested v1.22.4, and my tree is not at all
ready yet.)

 |Doug
 --End of <201912271608.xbrg84jr128...@tahoe.cs.dartmouth.edu>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
diff --git a/doc/pic.ms b/doc/pic.ms
index 6d581ba..a0a77c7 100644
--- a/doc/pic.ms
+++ b/doc/pic.ms
@@ -1722,7 +1722,8 @@ GNU \fBgpic\fP also documents a one-argument form or rand,
 version.
 .PP
 The function \fBsprintf()\fP behaves like a C \fIsprintf\/\fP(3)
-function that only takes %, %e, %f, and %g format strings.
+function that only takes the format strings %e, %E, %f, %g and %G,
+as well as %% for printing a raw percent character.
 .
 .
 .NH 1
diff --git a/src/preproc/pic/pic.1.man b/src/preproc/pic/pic.1.man
index 847bbe3..85af1e7 100644
--- a/src/preproc/pic/pic.1.man
+++ b/src/preproc/pic/pic.1.man
@@ -906,6 +906,11 @@ this will produce the arguments formatted according to
 which should be a string as described in
 .BR printf (3)
 appropriate for the number of arguments supplied.
+Only the flags
+.B #-+ 0123456789.,
+and the formats
+.B eEfgG%
+are supported.
 .
 .
 .LP
diff --git a/src/preproc/pic/pic.ypp b/src/preproc/pic/pic.ypp
index 6afa2ab..2e5562e 100644
--- a/src/preproc/pic/pic.ypp
+++ b/src/preproc/pic/pic.ypp
@@ -1895,6 +1895,11 @@ char *do_sprintf(const char *form, const double *v, int nv)
   string one_format;
   while (*form) {
 if (*form == '%') {
+  if(form[1] == '%'){
+result += '%';
+form += 2;
+continue;
+  }
   one_format += *form++;
   for (; *form != '\0' && strchr("#-+ 0123456789.", *form) != 0; form++)
 	one_format += *form;

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

[Steffen Nurpmeso]

Ingo Schwarze wrote in <20191226222825.ga23...@athene.usta.de>:
 |I'm not posting these answers into the bugtracker because these
 |points are not relevant for evaluating the patch; i'm merely sending
 |this mail to avoid that people get confused by the misleading
 |statements.
 |
 |Steffen Nurpmeso wrote on Thu, Dec 26, 2019 at 09:06:00PM +0100:
 |
 |> And i have to go back to
 |>   .\" @(#)tmac.doc.old5.2 (Berkeley) 3/13/91
 |
 |That is totally irrelevant.  That file doesn't even implement the
 |same language we are talking about (mdoc v3).  It implements the
 |substantially different mdoc v2 language.  Manual pages written in
 |one cannot be formatted with a formatter for the other at all, nor
 |vice versa.
 |
 |> I mean, FreeBSD imported groff very early
 |
 |FreeBSD was forked off 386BSD 0.1 which in turn was forked off
 |4.3BSD-Net/2, which already contained groff several years before
 |FreeBSD even existed, so the statement that FreeBSD imported groff
 |is quite misleading.

Ok then, true.  But it was imported into the BSD tree very early,
that much is plain.  A couple of years ago i was spending quite
some time on the CSRG repo, and was surprised.

So when i look into that tree again and grep for Dd is see that
they used a Dd without arguments, but already documented

  075600a7df:share/man/man7/mdoc.samples.7:.Dd
  075600a7df:share/man/man7/mdoc.samples.7:.Tp Li \&.Dd month day, year

in 1990:

  .Dl Li \&.Os BSD 4.4
  .Tp Li \&.Dd month day, year
  The date should be written formally:
  .Pp
  .Dl January 25, 1989
  .\"  is not a standard SCCS id-key. ??

In Unix tradition i find it even amusing that for that very manual
mandoc says

  BSD 4.4 December 26, 2019 BSD 4.4

whereas groff says

  mdoc error: .Ds defunct (#895)
  mdoc error: .Ds defunct (#936)
  mdoc error: .Ds defunct (#984)
  mdoc warning: Using a macro as first argument cancels effect of .Li (#1014)
  mdoc error: .Ds defunct (#1014)
  Usage: .Li argument ... (#1021)
  mdoc error: .Ds defunct (#1031)
  mdoc warning: Using a macro as first argument cancels effect of .Li (#1098)
  mdoc error: .Ds defunct (#1098)
  Usage: .Ss not callable by other macros (#1100)
  mdoc error: .Ds defunct (#1229)
  mdoc error: .Ds defunct (#1297)

  ...

  4.4BSD Epoch 4.4BSD

Given that the mdoc syntax as such is old style, and not truly
supported by the new mdoc macros, a reference to Epoch is cool.
That is a little bit as if a C compiler would echo "i cannot
compile B" or what for a B file.

 |> Names like dbus-update-activation-environment could
 |> become a problem in conjunction with a date and something else
 |> a little longer.
 |
 |No, *names* cannot cause line breaks.  The footer line only contains
 |the .Os identifier and the date, no name whatsoever.

So then.  Ok.  But i like being explicit.  Even if it does not
matter.  I guess the inventor of it did something future proof.
How often have i myself patched something wildly, braking some
stuff because i had forgotten context.  Whatever.

 |> Well, i personally would rather do something like
 |
 |[... ineffective patches snipped ...]
 |
 |Your patches fail to fix the bug.
 |The original 4.4BSD manuals i listed are still misformatted with
 |your patches, and so are modern FreeBSD xo_attr(3) and ld(7)
 |and modern NetBSD dns-sd(1).

These require patches to be sent upstream for sure, they belong to
external software, and are simply broken mdoc syntax, right.
Especially bad for libxo which is so tightly coupled to FreeBSD,
and i wonder whether why FreeBSD "igor" tool does not check that?

I mean, i for one would _not_ do your patch.  I would instead
readd a warning, and scream out loud that the command is misused
according to rules invented thirty years ago.

 --End of <20191226222825.ga23...@athene.usta.de>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

[Steffen Nurpmeso]

Hi Ingo.

Ingo Schwarze wrote in <20191226-172201.sv97361.20...@savannah.gnu.org>:
 |Follow-up Comment #1, bug #57485 (project groff):
 |
 |I'd like to stress that this patch indeed fixes a bug.  In 4.4BSD, 
 |it was *not* documented that .Dd requires exactly three arguments
 |and prints the current date otherwise, but several manual pages
 |existed that gave a single quoted argument of the form "Month day, 
 |year".  Documenting the weird behaviour of the groff_mdoc(7) macros
 |was done much later.  The mandoc(1) utility has been providing the

But that "later" was 20 years ago!  How many programmers even know
about things before that??  I for example have never seen anything
else, and it is in use in entire BSD land like that.

 |more useful behaviour proposed here for years, in a way that is in
 |particular compatible with the original 4.4BSD manual pages, and
 |it has been documenting the more useful behaviour for years, too.

No, not true.  I look at v14.4.4 from 2018-08-08 and there you
still say

 Dd   document date: $Mdocdate$ | month day, year

and you also do that in v14.4.5 which seems current?

 |So calling the current groff_mdoc(7) behaviour "documented behaviour"
 |is misleading.  At some point, a bug was documented instead of fixed 
 |in groff, a bug that broke the formatting of even the original 4.4BSD
 |manuals, i.e. those of the system where these macros came from.

And i have to go back to

  .\" @(#)tmac.doc.old5.2 (Berkeley) 3/13/91
  .\" Slightly modified by j...@jclark.com to work with groff as well.

where Dd exists as

  .de Dd
  .nr aa 0
  .ie \\n(.$>0 \{\
  .   ie \\n(.$<4 \{\
  .   ds dD \\$1 \\$2 \\$3
  .   \}
  .   el .tm Usage: .Dd Month Day, Year (e.g July 4, 1977).
  .\}
  .el \{\
  .   ds dD Epoch
  .\}

And that behaviour i think is sensible, though ==3 would be
better, and even better would likely be to ".ds dD Epoch" and only
overwrite it on request, since .Dd should be present in every mdoc
document me thinks.
I mean, FreeBSD imported groff very early, for example, so we are
talking about multiple generations of programmers here!

 |To clarify two minor details:
 |
 |Losing unbreakable spaces is totally irrelevant.  For any sane 
 |input, the footer line is always a single line only; no linebreaks
 |occur.

Maybe.  But with the constraint that one reason for this is that
many tools especially on Linux are not properly, or not at all
documented.  Names like dbus-update-activation-environment could
become a problem in conjunction with a date and something else
a little longer.  Not that anyone cares the manual for the
mentioned does not care for 80 columns anyway, so wtf.

 |Of course this ticket only applies to the non-Mdocdate case,
 |nothing changes for Mdocdate.

Yep.
Well, i personally would rather do something like

  diff --git a/tmac/mdoc-common b/tmac/mdoc-common
  index a2d0cc63..00589e0d 100644
  --- a/tmac/mdoc-common
  +++ b/tmac/mdoc-common
  @@ -808,6 +808,7 @@
   .el .ie (\n[.$] == 3) \
   .  ds doc-date-string \$1\~\$2 \$3
   .el \{\
  +.  tm mdoc warning: .Dd directive falsely used
   .  ds doc-date-string "\*[doc-date-\n[mo]]
   .  as doc-date-string \~\n[dy], \n[year]
   .\}

but forgive the wording etc.  Maybe even

  diff --git a/tmac/mdoc-common b/tmac/mdoc-common
  index a2d0cc63..f7eb574f 100644
  --- a/tmac/mdoc-common
  +++ b/tmac/mdoc-common
  @@ -798,6 +798,7 @@
   .ds doc-date-10 October
   .ds doc-date-11 November
   .ds doc-date-12 December
  +.ds doc-date-string Epoch
   .
   .de Dd
   .  ds doc-command-name
  @@ -807,13 +808,8 @@
   .  ds doc-date-string \$2\~\$3, \$4
   .el .ie (\n[.$] == 3) \
   .  ds doc-date-string \$1\~\$2 \$3
  -.el \{\
  -.  ds doc-date-string "\*[doc-date-\n[mo]]
  -.  as doc-date-string \~\n[dy], \n[year]
  -.\}
  +.el .tm mdoc warning: .Dd directive falsely used
   .  \}
  -.  el \
  -.ds doc-date-string Epoch
   ..
   .
   .

and not taking into account that the el..ie is falsely grouped and
provokes -w warnings like a lot of other stuff that ships with
groff.  (Like a NetBSD thread has revealed just a few days ago.)

 |Reply to this item at:
 |
 |  

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

[Steffen Nurpmeso]

Ingo Schwarze wrote in <20191226-144637.sv97361.2...@savannah.gnu.org>:
 |URL:
 |  
 |
 | Summary: [PATCH] accept any number of arguments for .Dd in
 |the groff_mdoc(7) macros
 | Project: GNU troff
 |Submitted by: schwarze
 |Submitted on: Thu 26 Dec 2019 02:46:37 PM UTC
 |Category: Macro - mdoc
 |Severity: 2 - Minor
 |  Item Group: Incorrect behaviour
 |  Status: None
 | Privacy: Public
 | Assigned to: schwarze
 | Open/Closed: Open
 | Discussion Lock: Any
 | Planned Release: None
 |
 |___
 |
 |Details:
 |
 |The .Dd macro behaved in a weird way:
 | - Without arguments, it printed the string "Epoch".
 | - With one, two, four, or more arguments, it ignored all arguments \
 | and used
 |the current date instead.
 | - Only for exactly three arguments, it printed the arguments.

Not true.  You have already added the Mdocdate thing, that has
been you, no?

 |None of this made sense.  Giving the date as "Epoch" is absurd, and \

It is as good as anything else while constructing a manual page
draft.  Once you are done with it, you can give it a real value.

 |printing
 |the current date is just misleading: why should a document be considered
 |up-to-date when the author did not even bother to state the date of \
 |the last
 |change?

I for one disagree with you.  If the most likely automatized
release script does not tag the manual, then for a user looking at
the manual page it likely is the "current" version as of today.
Of course it is as good as anything else, or no, not really.
I like that much better than those crap release scripts which do
only partial tagging.  For example here on my box cc(1) gives
"BSD June 20, 2014 BSD", whereas the thing really belongs to
gcc(1), and that is "gcc-8.3.0 2019-02-22 GCC(1)".  See how great
that is.

 |Admittedly, the behaviour for 0 and 4 or more arguments already appeared
 |4.3BSD-Reno, and the behaviour for 2 or 3 arguments in 4.4BSD.  But it was
 |already wrong even in those days: several manual pages in 4.4BSD gave .Dd a
 |single, quoted argument, e.g. .Dd "June 9, 1993": cap_mkdb(1), id(1), \
 |sed(1),
 |err(3), getcap(3), sysctl(3), amd(8), disklabel(8), and others.
 |
 |Consequently, simply print all the arguments, no matter how many there are.

I would not do that, you also loose an explicit unbreakable space.

 |This bug was found by Jonathan Gray  while he looked at
 |4.xBSD manual pages.

I don't think so.  Maybe there should be a warning that the macro
is misued, if not used as documented.  Then the remaining
arguments could simply be printed, but i for one would then ignore
the obviously false arguments.
And hey -- you are the one which gives all the importance to
details, or is my memory fooling me.
But anyway, who am i, my roff clone is hanging for five years now,
i hope i can find some time next year, and anyway i hope i live
long enough to bring some life back to wonderful roff.  Sigh.

 |Date: Thu 26 Dec 2019 02:46:37 PM UTC  Name: mdoc-Dd.patch  Size: 4KiB \
 |  By:

 |schwarze
 |
 |

I would hope for that patch not being included as is, however.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: FAMILY-dependent apostrophe behaviour with -mom

[Steffen Nurpmeso]

Hello.

Deri wrote in <2403810.z0MjTcnAeh@pip>:
 |On Monday, 2 December 2019 16:22:34 GMT Marc Simpson wrote:
 |
 |> Hi Dale,
 |
 |> 
 |
 |> Thanks for your reply.

Sorry for jumping into your thread and being off-topic, but may
i ask what mailer you use?  It produces the most terrible HTML
that i have ever seen, as in:

  Content-Transfer-Encoding: 7Bit
  Content-Type: text/html; charset="us-ascii"

  http://www.w3.org/TR/REC-html40/strict.dtd;>
  
  p, li { white-space: pre-wrap; }
  
  On 
Monday, 2 December 2019 16:22:34 GMT Marc Simpson wrote:
   
Hi Dale,
   

   
Thanks for your reply.
   

  ...

 |>> Anyway, I hope this helps.
 |
 |> 
 |

It could be it interprets the above in text, too, however.
(It reiterates inline styles even though it does include
a per-document stylesheet, and puts everyhing in its own
paragraph.
Just so you know...

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Table of content for UTP in groff format

[Steffen Nurpmeso]

Andrea D'Amore wrote in :
 |Hello,
 |I got the "UNIX Text Processing" book in groff format, link "groff and
 |PostScript files--Beta" at [1] and built the default "utp_book.ps"
 |target.
 |The resulting PostScript file and its conversion to PDF via ps2pdf
 |have no outline.
 |
 |I see the Makefile is doing… something to generate the ToC and in fact
 |it has toc.t as dependency of utp_book.ps target, this file is not
 |used anymore when building utp_book.ps .
 |
 |I am very new to groff, I am in the process of reading the groff
 |chapter of the book now, can anyone enlighten me about what's
 |happening with the ToC there, if it is supposed to be available and
 |browseable from PS/PDF viewer or if it is an "incomplete feature" of
 |the groff port of the book?

In private i have pointed Andrea to the pdfmark macros, which
could be used to extend the UTP header macros (seem to be Se and
Ah) to gain PDF support.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Table of content for UTP in groff format

[Steffen Nurpmeso]

Andrea D'Amore wrote in :
 |On Thu, 24 Oct 2019 at 17:11, Andrea D'Amore  wrote:
 |> link "groff and PostScript files--Beta" at [1] and built the default \
 |> "utp_book.ps" target.
 |[…]
 |> [1]: https://www.oreilly.com/openbook/utp/
 |
 |While [1] is active the mentioned link points to a different server
 |that is not active now even if it was just a few days ago.
 |
 |If anyone is willing to check that out the Wayback Machine has it
 |backed up at 2019-09-21 [2].
 |
 |[2]: http://web.archive.org/web/20190921225220/http://home.windstream.ne\
 |t/kollar/utp/

I have the the tarball around for some years.  If anyone needs it.
Regarding your problem, Andrea, i cannot help, ..., but when i run
"make" i get a document with TOC and INDEX, just fine?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] MacTeX (was: groff and pipes)

[Steffen Nurpmeso]

Douglas Johnson wrote in <20190807133230.ga25...@panix.com>:
 |On Aug 07, 2019, at 08:40, John Gardner wrote:
 |
 |>Installing TeX on macOS also requires a 3.9 GB download of the full 
 |>MacTeX distribution, whereas Groff's source tree doesn't even consume 
 |>that much space...
 |
 |Installing the full MacTeX distribution does indeed require around 4 GB 
 |of space. One can also choose to install the BasicTeX distribution, 
 |which is a subset of the full distribution that provides only the 
 |essential components. The size of the BasicTeX distribution is 110 MB.
 |
 |As the difference in size indicates, BasicTeX lacks most of the packages 
 |that have accumulated around TeX in the last forty years. That absence 
 |may or may not matter to you, depending on your needs. BasicTeX provides 
 |functionality for installing missing packages manually.
 |
 |More information BasicTeX and the differences between the two 
 |distributions may be found here:
 |
 |

There is also kerTeX[1].  Never used it, but since it has all
i need if i would find the time and fun to redo my (mostly) lost
macro package, i am tracking it since .. 2012.  And even though we
come to a dozen updates, the git objects pack is <13 MB.

  [1] http://www.kergis.com/en/kertex.html

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20190704202830.ds7rz%stef...@sdaoden.eu>:
 |James K. Lowden wrote in <20190703140438.a516b5af83532af9d7aa883b@schema\
 |mania.org>:
 ||On Wed, 3 Jul 2019 07:08:44 +1000
 ||John Gardner  wrote:
 ||
 ||> Really? That's interesting. What did  do? On the terminal
 ...
 ||^Q/^S is xon/xoff.  Besides being keys you can type to control terminal
 ||scrolling, it was typically supported by printers so the computer
 |
 |Flow control you can use to totally stop byte transfers from and
 |to the terminal.  I had forgotten and sent a ridiculous mail to
 |the tmux ML somewhen in spring, getting "this is easy and has
 |nothing at all to do with tmux" (or so) response.

My personal actual background was that i "unbind-key -a" (since
ever), and in that situation i would not have expected anything to
step in from wherever.  None of the other programs i use do.
Though, it must be said: they are no terminal emulators.
I did not mention that context on the tmux list.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] [PATCH] new requests to case-transform string register values

[Steffen Nurpmeso]

G. Branden Robinson wrote in <20190703154957.27lxnueucvu2cr5v@localhost.\
localdomain>:
 |A recurring theme in my man page clean-up work has been my violent
 |antipathy for shouting capitals in their texts.  While I don't _like_
 |being shouted at for reasons other than true emergency, the real problem
 |with the capitalization convention in man pages is that it happens at
 |the input source, destroying information (case distinctions) that is
 |unrecoverable by the typesetting system later.
 |
 |Here is the last time we discussed the issue:
 |https://lists.gnu.org/archive/html/groff/2018-12/msg00141.html
 |
 |The consensus seemed to be that pushing case-transformation
 |functionality down into language would be worth trying.
 |
 |So, here's an implementation.  Comments welcome.
 |
 |I expect some bikeshedding on the names of the requests.  I'm not wedded
 |to the ones I have; my main criterion is:
 |
 |* The new request names should collate adjacently in the existing
 |  request namespace.  E.g., "stringup" and "stringdn" are a much better
 |  pair than "upstring" and "dnstring".  If someone is looking for one of
 |  them, it's not going to be long before they wonder what/where the
 |  other one is.

I am totally out still and for some time to come, but from looking
at the code all i know and can do is to wonder how far you come
with that 7-bit ASCII only toupper()/tolower().

 |Regards,
 |Branden
 --End of <20190703154957.27lxnueucvu2cr5v@localhost.localdomain>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

[Steffen Nurpmeso]

James K. Lowden wrote in <20190703140438.a516b5af83532af9d7aa883b@schema\
mania.org>:
 |On Wed, 3 Jul 2019 07:08:44 +1000
 |John Gardner  wrote:
 |
 |> Really? That's interesting. What did  do? On the terminal
 |> emulators I have on hand at the moment, none of them are responding
 |> or behaving differently.
 |
 |Same thing it still does do, because outside of the GUI all we do is
 |emulate 1970s hardware.  
 |
 |^Q/^S is xon/xoff.  Besides being keys you can type to control terminal
 |scrolling, it was typically supported by printers so the computer

Flow control you can use to totally stop byte transfers from and
to the terminal.  I had forgotten and sent a ridiculous mail to
the tmux ML somewhen in spring, getting "this is easy and has
nothing at all to do with tmux" (or so) response.

 |didn't overrun the printer's buffer.  
 |
 |--jkl
 |
 --End of <20190703140438.a516b5af83532af9d7aa8...@schemamania.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] no header in Japanese manpages

[Steffen Nurpmeso]

KUBO Koichi wrote in <51db73de-bc1a-e930-1be6-b5b04e432...@obuk.org>:
 |On 4/21/19 2:22 AM, Steffen Nurpmeso wrote:
 |> KUBO Koichi wrote in <51fe9714-c2f9-5351-e4d5-aacc92fa0...@obuk.org>:
 |>|I am using groff-1.22.4 on FreeBSD.
 |>|After updating groff, I realized that there is no header in Japanese
 |>|manpages using mdoc.tmac.  So I added the following line to
 |>|mdoc.local:
 |>|
 |>|.if ((\n[.x]\n[.y] >= 122) & (\n[.Y] >= 4)) \{\
 |>|.  if "\*[locale]"japanese" \{\
 |>|.als doc-section-namesection-name
 |>|.als doc-section-synopsissection-synopsis
 |>|.als doc-section-description section-description
 |>|.als doc-section-see-alsosection-see-also
 |>|.als doc-section-files   section-files
 |>|.als doc-section-authors section-authors
 |>|.  \}
 |>|.\}
 |>|
 |>|Please let me know if there are other things I have to do.
 |> 
 |> This should not be needed, the doc- is a shared prefix that will
 |> be stripped during installations, as it is not needed.  Whether it
 |> is good to strip it, i do not know.  I do not like it.  Namespaces
 |> would be much cooler, like being able to say "use namespace doc",
 |> but i cannot help it, at least not for the forseeable future.
 |> I am confident Ingo tested 1.22.4.
 |> 
 |> Out of interest, who needs this doc- prefix, actually?
 |
 |Thankyou for the explanation.
 |
 |I added mdoc/ja.UTF-8 for Japanese manpages after installing
 |groff-1.22.4. To do that, I took mdoc/ja.eucJP from FreeBSD ports
 |ja-groff (groff-1.18.x) and converted it to UTF-8. I did not know to
 |profix doc- to the symbol, so I used it as it was. It seems that there
 |was a problem there.

Well i think it has been changed from 1.22.3 to .4.  Now the doc-
prefix is not stripped no more, and any downstream consumers need
to adjust.

 |Sorry for taking up your time.

I see it was not mentioned in the 1.22.4 release announcement.
This surely was an oversight only, with no ill intent.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] no header in Japanese manpages

[Steffen Nurpmeso]

Hello.

KUBO Koichi wrote in <51fe9714-c2f9-5351-e4d5-aacc92fa0...@obuk.org>:
 |I am using groff-1.22.4 on FreeBSD.
 |After updating groff, I realized that there is no header in Japanese
 |manpages using mdoc.tmac.  So I added the following line to
 |mdoc.local:
 |
 |.if ((\n[.x]\n[.y] >= 122) & (\n[.Y] >= 4)) \{\
 |.  if "\*[locale]"japanese" \{\
 |
 |.als doc-section-namesection-name
 |
 |.als doc-section-synopsissection-synopsis
 |
 |.als doc-section-description section-description
 |
 |.als doc-section-see-alsosection-see-also
 |
 |.als doc-section-files   section-files
 |
 |.als doc-section-authors section-authors
 |
 |.  \}
 |
 |.\}
 |
 |Please let me know if there are other things I have to do.

This should not be needed, the doc- is a shared prefix that will
be stripped during installations, as it is not needed.  Whether it
is good to strip it, i do not know.  I do not like it.  Namespaces
would be much cooler, like being able to say "use namespace doc",
but i cannot help it, at least not for the forseeable future.
I am confident Ingo tested 1.22.4.

Out of interest, who needs this doc- prefix, actually?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Possible bug with utf8 encoded files, when sourced via .so

[Steffen Nurpmeso]

Paul Ito wrote in :
 |Very new to this list, so please be gentle.
 |
 |I have the following issue:
 |
 |I want to include a utf8-encoded file "text.txt" (with lots of german \
 |umlauts in my case) into a groff file "include.roff", 
 |that would then be processed with the -ms macro along with the -Kutf8 flag.
 |
 |However, this does not seem to work properly, as all the fancy umlauts \
 |aren't recognized and get "butchered".
 |
 |Having the same text and processing it directly works fine.
 |
 |Am I missing something here, or is this a bug in the way, utf8 input \
 |is handled?
 |
 |include.roff might look like this:
 |
 |[fancy formatting, headings, etc here]
 |
 |.so text.txt
 |
 |where text.txt includes all the text that matters
 |
 |the command I run is
 |
 |groff -Tpdf -Kutf8 -ms include.roff > out.pdf
 |
 |(with groff version 1.22.3 on ubuntu 18.10)

I think this has come up on this list already.  According to your
words it seems that the inclusion happens after the character set
conversion has taken place.  So using the traditional UNIX roff
pipeline could help you out, as in "soelim FILE | preconv | rest".
I think having an option to .so which allows special preconv
setting, or a different way to achive that, would also be cool.
I wished i had more time.  (I am hoping for a self-maintained roff
clone, somewhen.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff

Re: [bug #55449] Use FILENAME_MAX in maxfilename.cpp

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20190112142048.2xfrg%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in <20190112141035.ao9y8%stef...@sdaoden.eu>:
 ||Eli Zaretskii wrote in <838szqf00l@gnu.org>:
 |||> Date: Sat, 12 Jan 2019 14:42:31 +0100
 |||> From: Steffen Nurpmeso 
 |||> Cc: bug-groff@gnu.org
 |||> 
 |||>|I think FILENAME_MAX is Standard ANSI C symbol, so it can/should be
 |||> 
 |||> NAME_MAX was also ANSI C by Brian W. Kernighan and Dennis M. Ritchie.
 |||> ANSI C says
 |||> 
 |||>   NAME_MAX 14 /* longest filename-component; system-dependent */
 |||
 |||No, NAME_MAX is Posix, not ANSI.
 ||
 ||I was citing the ANSI C book of the mentioned, like i have said.
 |
 |Note that i realize that those great ones bugged it up in that
 |NAME_MAX was the name but a single stale reference to FILENAME_MAX
 |was left there / sneaked in too.  That was long after the legendary
 |Ritchie C standard frustration mail <7...@alice.uucp> (noalias comments to
 |X3J11; "In discussion with various X3J11 members, I learned that
 |this section is now regarded as an inadvertant error, and no one
 |thinks that it will last in its current form.  Nevertheless, it
 |seemed wisest to keep my comments in their original strong form.
 |The intentions of the committee are irrelevant; only their
 |document matters.")

That is to say.  Turning this oversight to patch thirty years
later is a thing that i do not understand.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
bug-groff mailing list
bug-groff@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-groff