Hi Alex,
At 2023-01-04T21:15:00+0100, Alejandro Colomar wrote:
> > That's true. But what is _not_ true is that you don't have a
> > minimum expected terminal width. You do, you just might not know
> > what it is and it may not even have been consciously chosen.
>
> I haven't consciously chosen it, but I often use 66-col terminals,
> especially when I plan to paste text into an email.
Well, by "you" I mean in your capacity as Linux man-pages maintainer.
There is some threshold of terminal width in the corpus of pages below
which things start to look really horrible.
Maybe you'd like my shell wrapper for man(1).
# View a man page but report all warnings.
man () {
if command man "$@"
then
command man --warnings=w "$@" >/dev/null
fi
}
It shows me the formatter's warnings _after_ the page is rendered.
> Even if unfilled blocks exceed the terminal width, and therefore might
> be unpleasant to the eyes, they have a nice feature: the line never
> breaks, and you can still pipe it to other programs, or paste it, and
> it will be a single line.
You can therefore simulate this for any man page by setting the `LL`
register to some large value. Once it exceeds your terminal width, it
will certainly be ugly as hell, but if you want line-by-line
piping/pasting, maybe you'll find it useful.
-rLL=line‐length
Set line length; the default is 78n for terminal devices and
6.5i for typesetter devices.
man-db man(1) simulates this with the MANWIDTH environment variable.
Presently it uses a hack, which I hope will go away after groff 1.23.
https://savannah.gnu.org/bugs/index.php?58992
> > In any event, groff man(7)'s SY/YS extension macros are _built_ for
> > this application. I'm happy to "port" this page to use them; doing
> > so will permit removal of the PD macro calls, among other benefits.
>
> Yup, that would be nice!
Okay, there's another change for v3, then! :)
> > > Is there anything that "reverts" \%? So that if it were the
> > > default, we could use \anti-% to say "groff, you might break this
> > > word"?
> >
> > Yes. \% itself does that.
>
> I mean something like \X\%foobar, so that the \X "cancels" the \%.
> Not manually inserting break points. So, imagining a world in which
> hyphenation was disabled _only_ within font-selection macros, I could
> specify that a word is fine to be hyphenated like this:
>
> .B \Xidontcareifthisishyphenated
Hmm, no, there is no *roff escape sequence for "apply automatic
hyphenation to the following word".
But your hypothetical is already a counterfactual. Macros like .B
_already_ don't disable hyphenation. So it seems to me like you're
proposing second-order machinery to get yourself out of the bind you're
creating with your first-order demand to make the font macros disable
hyphenation.
It really seems better to me to leave the font macros alone and have
a semantic tagging facility for those things you really don't want
hyphenated.
Or, proceed as the groff man pages have to date, stick to the font
selection macros as they are, and use \% with them.
Most of the 94 printable Basic Latin characters already have meaning
as *roff escape sequences when preceded by an escape character. The
scarce name space that remains must be occupied only with great
consideration. Dave Kemper and I have kicked around ideas for an
"extension" character for escape sequences to surmount this problem. \<
is available, and despite giving me nightmare memories of HTML, it might
be the best choice among what remains.[1]
> > Like changes in lettercase, this is _information_.
>
> I don't argue against that, but if there was a way to return that
> information explicitly, we wouldn't be loosing it.
As noted above, I think a good way to achieve that is by not discarding
it such that it needs recovery later.
> Oh, I do complain a lot; however, I don't express it too much in the
> form of bug reports, since I don't believe it's the fault of the
> writer, but rather lack of support from groff(1).
I don't think groff is missing support for anything you want here; we
have a disagreement over the design of the man(7) package.
> But I do find it very uncomfortable, similar to when manual page authors
> don't use the proper \-. However, I do think that one is fault of the
> author, and you can already find many such reports signed by me :)
My Debian colleagues teased me twenty years for railing against man
pages that didn't escape their hyphens. I was an early adopter of UTF-8
terminal emulators.
> > I suppose people who copy-and-paste multiple lines from a man page
> > realize they need to remove the hyphens along with newlines.
> > Fortunately, on UTF-8 terminals, they have hope of seeing the
> > difference between hyphens and the ASCII hyphen-minus that is
> > always(?) meant as a literal.
>
> My problem is not about pasting text. That's very minor. My problem
> is finding text.
Yes, I've seen many people complain about this, justifiably, over the
years. When people leave hyphenation enabled and try full-text searches
of man pages, often inside less(1), they get frustrated by the broken
words.
> For finding command options, I usually type:
>
> / --foo
>
> If \- hasn't been used, I need to use:
>
> / ..foo
>
> and skip all the noise. When there's too much noise, sometimes using
> an anchor (^) helps. But it's way nicer when writers use \-. I keep
> finding such bugs, and reporting them as much as I can.
Yup. Improving hyphen-minus hygiene here produces wins.
> When searching for keywords, the problem is the following: I do
> `/keyword`, but then if the keyword is hyphenated... well, good luck.
Right. less(1) is an interesting program. It has lots of features,
many more than any one user will use. But it seems to be pretty
indifferent to helping with searches for hyphenated words.
It's _possible_ to design an extension to ISO 6429 for communicating
hyphenation break information to terminals (and pagers). A big question
is what would bother to use that information. If Mark Nudelmann doesn't
want to support it, it's DOA, and he views ISO 6429 grudgingly enough in
the first place, hence "less -R".
I have only two recommendations.
1. Disable hyphenation in your man.local; or
2. Back my play for semantic tagging in man(7). ;-)
> > I think marking break points, hyphenated and otherwise (as with
> > URLs), is the opposite of laziness. It is a level of fastidiousness
> > I don't actually expect of many man(7) writers apart from myself.
>
> I would want to use \:. What I want is a tool which re-enables the
> default hyphenation points after they have been cancelled.
I submit again: if you don't cancel them in the first place, they don't
have to be reconstructed.
> I would. I wouldn't be able to count how many times I've tried to
> search for such a keyword, and it was hyphenated.
Semantic tags would solve this problem.
Regards,
Branden
[1] What's available?
\+ \1 \2 \3 \4 \5 \6 \7 \8 \9 \; \< \= \> \@
\G \i \I \j \J \P \T \U \W \y \]
Attachment:
signature.asc
Description: PGP signature
