Don't output a newline between .SH and heading text for nroff
#138
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for looking in to this! I'll look over it closely in the coming days... did it run thru all regressions? |
Ah, no, thanks for the reminder. In particular, this seems to render incorrectly: --- regress/header-with-links.man 2024-09-10 17:05:08.982373613 -0700
+++ /var/folders/z5/fclwwdms3r1gq4k4p3pkvvc00000gn/T/tmp.YBOJG0uKmv 2024-09-11 09:47:03.831861466 -0700
@@ -1,4 +1,3 @@
-.SH
-a \fIhttps://foo.com\fR now \fBworld\fR <\fIhttps://bar.com\fR> b
+.SH a \fIhttps://foo.com\fR now \fBworld\fR <\fIhttps://bar.com\fR> b
.LP
cAnd this isn't supposed to happen: --- regress/diff/metadata-keep.man 2024-09-10 17:05:08.977468465 -0700
+++ /var/folders/z5/fclwwdms3r1gq4k4p3pkvvc00000gn/T/tmp.YBOJG0uKmv 2024-09-11 09:47:05.030526226 -0700
@@ -1,10 +1,7 @@
.\" -*- mode: troff; coding: utf-8 -*-
.TH "" "7" ""
.PP
-.gcolor blue
-shmext
+.gcolor blue shmext
.gcolor black
-.gcolor red
-text
-.gcolor black
-here
+.gcolor red text
+.gcolor black here |
|
I think this will need a slight restructuring to only apply this logic when a |
9999years
force-pushed
the
no-newline-after-sh
branch
from
30be440 to
3bd865a
Compare
|
OK, I've fixed up the patch!
|
On macOS, `makewhatis` fails to parse `NAME` headings in man pages if
there's a newline between `.SH` and `NAME`. This is silly, but I can't
exactly get them to update it:
```
$ /usr/libexec/makewhatis -v -o /tmp/whatis outputs/out/share/man | head
man directory outputs/out/share/man
outputs/out/share/man/man5
reading outputs/out/share/man/man5/nix.conf.5
ignoring junk description ""
reading outputs/out/share/man/man5/nix-profiles.5
ignoring junk description ""
```
Through a circuitous sequence of events, this results in shell
completions for the `man` command being broken in Fish for man pages
generated with Lowdown:
https://git.lix.systems/lix-project/lix/issues/515
This patch, then, replaces the trailing newline after blocks with a
trailing space for `.SH` blocks which only contain normal text in
`nroff` output.
The restriction that `.SH` blocks only contain normal text is because
(for example) this doesn't render correctly:
```
.SH a \fIhttps://foo.com\fR now \fBworld\fR <\fIhttps://bar.com\fR> b
```
9999years
force-pushed
the
no-newline-after-sh
branch
from
3bd865a to
e05929a
Compare
|
Awesome how Mac OS X now uses mandoc to format manpages yet still uses some ancient craptastic makewhatis/apropos that has this bug (not respecting how |
kristapsdz
added a commit
that referenced
this pull request
Sep 15, 2024
This allows any content under an SH that is either normal text or entities to be serialised on the same line as SH instead of the subsequent line. Properly call this "headerhack" to point out that this is not because of lowdown or man(7), but other buggy software. References #138
|
Yeah, I'm not surprised. Very frustrating! |
13 tasks
sternenseemann
pushed a commit
to NixOS/nixpkgs
that referenced
this pull request
Sep 16, 2024
- Improve UTF-8 handling by not treating bytes >=0x80, which tend to be UTF-8 continuation bytes, as control characters. This leaves control characters U+0080 through U+009F in the output (incorrectly) but doesn't mangle other UTF-8 characters, so it's a net win. See: kristapsdz/lowdown#140 - Don't output a newline between a `.SH` and a heading. This fixes `makewhatis` output on macOS and (as a result) `man` completions for `fish` on macOS. See: kristapsdz/lowdown#138
github-actions bot
pushed a commit
to NixOS/nixpkgs
that referenced
this pull request
Sep 19, 2024
- Improve UTF-8 handling by not treating bytes >=0x80, which tend to be UTF-8 continuation bytes, as control characters. This leaves control characters U+0080 through U+009F in the output (incorrectly) but doesn't mangle other UTF-8 characters, so it's a net win. See: kristapsdz/lowdown#140 - Don't output a newline between a `.SH` and a heading. This fixes `makewhatis` output on macOS and (as a result) `man` completions for `fish` on macOS. See: kristapsdz/lowdown#138 (cherry picked from commit 7784c97)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On macOS,
makewhatisfails to parseNAMEheadings in man pages if there's a newline between.SHandNAME. This is silly, but I can't exactly get them to update it:Through a circuitous sequence of events, this results in shell completions for the
mancommand being broken in Fish for man pages generated with Lowdown:https://git.lix.systems/lix-project/lix/issues/515
This patch, then, replaces the trailing newline after blocks with a trailing space for
.SHblocks innroffoutput.