discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
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


      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).