Re: Unsupported nroff macros on MacOS X
Apologies. enter (send) before typing. on FreeBSD 13.1 fc [delimchar [padchar]]Define a delimiting and a padding character for fields. Currently unsupported. Also, fc is not recognised in mdoc as far as I can tell. A different mechanism might be needed no matter what. in which case, dropping use of fc and retaining man might work, but that said, this comment from the man 7 man on OSX: DESCRIPTION The man language was the standard formatting language for AT UNIX manual pages from 1979 to 1989. Do not use it to write new manual pages: it is a purely presentational language and lacks support for semantic markup. Use the mdoc(7) language, instead. -G
Re: Unsupported nroff macros on MacOS X
On Mon, Apr 3, 2023 at 3:43 PM Anthony J. Bentley wrote: > Ken Hornstein writes: > > - Switch to tbl(1) macros which as far as I can tell are supported by > > mandoc and seem to work everywhere. > > tbl is supported by mandoc, yes. In my opinion, this is the best option. > Well, converting to mdoc macros would be nicer, but also much more work, > and who would do it? > > > (I do not know when tbl(1) was created, but it wouldn't surprise me > > if MH predated it). > > According to the mandoc manuals: > > HISTORY > The tbl utility, a preprocessor for troff, was originally written by > M. E. Lesk at Bell Labs in 1975. > >
Re: Unsupported nroff macros on MacOS X
Ken Hornstein writes: > - Switch to tbl(1) macros which as far as I can tell are supported by > mandoc and seem to work everywhere. tbl is supported by mandoc, yes. In my opinion, this is the best option. Well, converting to mdoc macros would be nicer, but also much more work, and who would do it? > (I do not know when tbl(1) was created, but it wouldn't surprise me > if MH predated it). According to the mandoc manuals: HISTORY The tbl utility, a preprocessor for troff, was originally written by M. E. Lesk at Bell Labs in 1975.
Re: Unsupported nroff macros on MacOS X
Ken,
> I will admit that my roff-fu is not very good, but I took a look at this.
> It seems this is a common idiom for nmh man pages. Specifically (this
> is from packf(1) but it's similar everywhere else):
any roff-fu i had expired at my last birthday.
i've recently switched to use asciidoc, which seems to support tables
https://docs.asciidoctor.org/asciidoc/latest/tables/build-a-basic-table/
i convert to man using a configuration file (asciidoc.conf) from Eli
Schwartz:
https://github.com/eli-schwartz/aurpublish/blob/master/doc/asciidoc.conf
my makefile rule:
./%: %.asciidoc asciidoc.conf
${A2X} --no-xmllint --asciidoc-opts="-f asciidoc.conf" -d manpage -f
manpage $<
(i'm sure all this could be improved.)
converting to asciidoc been liberating, though i'm sure, like any of
these "lightweight markup languages", defeats attempts at fine-tuning
(which, itself, can be very liberating :).
cheers, Greg
Re: Unsupported nroff macros on MacOS X
Date:Sun, 02 Apr 2023 18:59:03 -0400 From:Ken Hornstein Message-ID: <20230402225904.db62e187...@pb-smtp2.pobox.com> | Given my druthers I think I'd rather do the last one, since this kind | of seems like a table! I would do it that way (now) too, either that way, or just use mdoc primitives - an appropriate layout could probably be achieved using the list macros (with tags) in compact mode. | (I do not know when tbl(1) was created, but it wouldn't surprise me | if MH predated it). tbl was in (at least, if not earlier) 6th edition - so it predates MH. But the man command (and the man macros) used to not support use of tbl, that was for MS (or MM for those who had those macros) (and later ME from Berkeley). So, it is no surprise that man pages wouldn't use it. kre
Re: mhl nocomponent
Date:Sun, 02 Apr 2023 11:44:23 -0700 From:Jon Steinhart Message-ID: <202304021844.332iin922005...@darkstar.fourwinds.com> | It does seem like the size of the headers exceeds the size of the body | in a lot of cases :-) Like in this message from you ... even though you quoted Ken's message in its entirety. Likely to be the same in this message from me, and in most other e-mail that doesn't contain attachments, or HTML noise. ls -l B H; wc -l B H -rw-r--r-- 1 kre wheel 1031 Apr 3 07:19 B -rw-r--r-- 1 kre wheel 3484 Apr 3 07:19 H 27 B 67 H B is the body, H the header (I omitted the separator newline char, and also the total line from wc (you can add 27+67 yourself, then add one more for that separator between header and body). But it would be good if at least in this community, we could get the terminology correct, e-mail messages have a header (just one) and usually have a body (also just one, but this one is optional). The header contains fields (From To (etc) and all of the junk). kre
Re: mhl nocomponent
>It does seem like the size of the headers exceeds the size of the body >in a lot of cases :-) I mean ... yes? Doesn't seem like there's much we can do about that unfortunately. --Ken
Unsupported nroff macros on MacOS X
So I noticed that after an upgrade to MacOS X, I started getting this warning on certain nmh man pages: This manpage is not compatible with mandoc(1) and might display incorrectly. After some digging, it turns out man(1) is a shell script and to make a long story short is running this command: mandoc -Tlint -Wunsupp Which returns this: mandoc: whom.man:140:2: UNSUPP: unsupported roff request: fc And some quick googling suggests that in fact the mandoc macros only support a subset of roff requests, and .fc aint one of them. I will admit that my roff-fu is not very good, but I took a look at this. It seems this is a common idiom for nmh man pages. Specifically (this is from packf(1) but it's similar everywhere else): .SH "PROFILE COMPONENTS" .fc ^ ~ .nf .ta 2.4i .ta \w'ExtraBigProfileName 'u ^Path:~^To determine the user's nmh directory ^Current\-Folder:~^To find the default current folder ^Msg\-Protect:~^To set mode when creating a new `file' .fi So as I vaguely understand it, the .fc line sets '^ as a field delimeter and '~' as the character to pad a field. .nf sets the following lines to no-fill mode. ".ta 2.4i" sets the tab stop to 2.4 inches. The following line sets the tab stop to the width of "ExtraBigProfileName" and 'u is the default horizontal span for the terminal (now that I look at it, I'm not sure why there are two .ta lines right after another). The following lines use '^' to delimine each field and the "~" to pad out each field. So you get something that is supposed to look like: PROFILE COMPONENTS Path:To determine the user's nmh directory Current-Folder: To find the default current folder Msg-Protect: To set mode when creating a new `file' But on MacOS X you now get: PROFILE COMPONENTS ^Path:~^To determine the user's nmh directory ^Current-Folder:~^To find the default current folder ^Msg-Protect:~^To set mode when creating a new `file' This isn't wonderful and I'd like to fix it, but I'm not sure what to do. Ideas include: - Tell MacOS X users to install groff(1) (the man(1) script will try to call groff if it encounters a warning like this from mandoc) - Switch to some other roff construct; I was under the impression that actual tabs would work? I'm not sure why tabs aren't used here. - Switch to tbl(1) macros which as far as I can tell are supported by mandoc and seem to work everywhere. Given my druthers I think I'd rather do the last one, since this kind of seems like a table! But I'd like to hear what other people think since I know there are people here with much greater roff-fu than I (I do not know when tbl(1) was created, but it wouldn't surprise me if MH predated it). --Ken
Re: mhl nocomponent
Ken Hornstein writes: > >I use MH-E, which does it's header display/hiding outside of MH. In > >general, I like to see extra headers, but they have gotten way out of > >hand from the MS/Outlook space. We probably need a better list of > >common "this is junk" header list that probably has to have wildcards in > >it. > > Sigh. I mean, it seems like this has been expanding, and "everybody > else" doesn't consider it a problem since every OTHER MUA only shows > "relevant" headers by default. Even Robert Elz (who was a long-time > proponent of showing those headers) finally gave up and deleted the > extras:nocomponent line in his mhl file: > > https://lists.nongnu.org/archive/html/nmh-workers/2021-06/msg00025.html > > I am thinking maybe we should change the nmh default mhl files as well > to recognize current reality (in that thread Ralph also chimed in and > said the current default doesn't make sense). > > --Ken It does seem like the size of the headers exceeds the size of the body in a lot of cases :-) Jon
Re: mhl nocomponent
>I use MH-E, which does it's header display/hiding outside of MH. In >general, I like to see extra headers, but they have gotten way out of >hand from the MS/Outlook space. We probably need a better list of >common "this is junk" header list that probably has to have wildcards in >it. Sigh. I mean, it seems like this has been expanding, and "everybody else" doesn't consider it a problem since every OTHER MUA only shows "relevant" headers by default. Even Robert Elz (who was a long-time proponent of showing those headers) finally gave up and deleted the extras:nocomponent line in his mhl file: https://lists.nongnu.org/archive/html/nmh-workers/2021-06/msg00025.html I am thinking maybe we should change the nmh default mhl files as well to recognize current reality (in that thread Ralph also chimed in and said the current default doesn't make sense). --Ken
Re: mhl nocomponent
I use MH-E, which does it's header display/hiding outside of MH. In general, I like to see extra headers, but they have gotten way out of hand from the MS/Outlook space. We probably need a better list of common "this is junk" header list that probably has to have wildcards in it. signature.asc Description: PGP signature
