From: "k.st" <o@krj.st>
To: "Ingo Schwarze" <schwarze@usta.de>
Cc: <discuss@mandoc.bsd.lv>
Subject: Re: Option to disable sentence spacing in tty output?
Date: Fri, 14 Aug 2020 03:50:47 +0000 [thread overview]
Message-ID: <C4WEWKZYEUOX.V9Q4NBFX404I@szk> (raw)
In-Reply-To: <20200813232207.GB46177@athene.usta.de>
Sorry, I forgot to cc the list.
---
"Ingo Schwarze" <schwarze@usta.de> wrote:
> Though admittedly, pod2man(1) is already good enough and all others
> are basically unmaintained, hopeless crap.
Now that you mentioned pod2man(1), I noticed that it also has trouble
handling sentence breaks.
$ cat test.pod
=head1 Test
This is a line. This is another line.
$ pod2man test.pod | mandoc
TEST(1) User Contributed Perl Documentation TEST(1)
Test
This is a line. This is another line.
perl v5.32.0 2020-08-14 TEST(1)
> but workarounds for issues of little to no importance just
> encourage laziness and bad practice for no relevant benefit.
I agree that this issue is very minor. It should be handled by man(7)
generators, but as far as I know, the only generator that handles this
properly is Pandoc. This is quite difficult without enforcing the same
line-breaking style as roff. Pandoc uses an abbreviation list to handle
ambiguity, but there can be false positives.
I have addressed this issue to developers of multiple man(7) generators.
For asciidoc, it is tied to docbook, which hasn't been updated for years
and mostly deprecated in favor of a new format, so fixing it might be
hopeless [1].
> Respecting .ss would be easy indeed, but that would amount to letting
> the *author* choose rather than the user.
groff happens to have a man.local file that is loaded before processing
any man pages, but mandoc's workflow is quite different, so yes, I don't
think implementing this option would matter a lot to users.
> getopt_long? Over my dead body.
>
> But i don't think there is the slightest chance for building a
> sufficiently good argument for -O frenchspacing either.
Of course, I mean similar in functionality, not similar option names.
As an alternative to option flags, If anyone would like to disable
this behavior. The following patch should do the trick:
For revision 1.281.
--- a/term.c
+++ b/term.c
@@ -535,8 +535,6 @@ term_word(struct termp *p, const char *word)
if ((p->flags & TERMP_NOSPACE) == 0) {
if ((p->flags & TERMP_KEEP) == 0) {
bufferc(p, ' ');
- if (p->flags & TERMP_SENTENCE)
- bufferc(p, ' ');
} else
bufferc(p, ASCII_NBRSP);
}
- kst
[1]: https://github.com/asciidoc/asciidoc-py3/issues/137
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
prev parent reply other threads:[~2020-08-14 3:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 22:12 k.st
2020-08-13 23:22 ` Ingo Schwarze
2020-08-14 3:50 ` k.st [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C4WEWKZYEUOX.V9Q4NBFX404I@szk \
--to=o@krj.st \
--cc=discuss@mandoc.bsd.lv \
--cc=schwarze@usta.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).