help / color / mirror / Atom feed
From: Abhinav Upadhyay <er.abhinav.upadhyay@gmail.com>
To: Ingo Schwarze <schwarze@usta.de>
Cc: discuss@mdocml.bsd.lv
Subject: Re: Parsing of .Ex with -std argument
Date: Thu, 12 Jan 2017 02:00:42 +0530	[thread overview]
Message-ID: <CAHwRYJ=OZb-xZXAbokqhm7tuPYWMCHR98TsW2+5RyAasb+z_Kg@mail.gmail.com> (raw)
In-Reply-To: <20170111185309.GA40572@athene.usta.de>

On Thu, Jan 12, 2017 at 12:23 AM, Ingo Schwarze <schwarze@usta.de> wrote:
> Hi Abhinav,
> sorry for not answering this one in a timely fashion.
> I was occupied with other matters back then and forgot
> to send a preliminary answer.

No problem, thanks for resolving it :)

> Abhinav Upadhyay wrote on Sun, Oct 02, 2016 at 11:13:00PM +0530:
>> I'm having issues parsing man pages which use the .Ex macro in the
>> EXIT STATUS section. For example mandoc -Ttree shows following output
>> for a man page using it:
>> Sh (block) *138:2
>>   Sh (head) 138:2
>>       EXIT STATUS (text) 138:5
>>   Sh (body) 138:2
>>       Ex (elem) -std *139:2
>>           nbperf (text) 139:2
>> This is causing makemandb(8) (NetBSD's indexing tool) parse the EXIT
>> STATUS section just as "nbperf" instead of the complete expanded text.
> This was a symptom of a more general problem.  The text production
> macros - .At, .Bsx, .Bx, .Ex, .Fx, .Lb, .Nx, .Ox, .Rv, .St, .Ux
> and the obsolete .Bt and .Ud - handled their task inconsistently.
> Some produced text at the validation stage and added it to the
> syntax tree, notably .Lb and .St.  Others did little at the
> validation stage and left text production to the formatters,
> notably .Ex and .Rv.  Both approaches had downsides.  Text
> production at the validation stage obscured the content of the
> original source document, making it impossible to recover the source
> from the finalized syntax tree.  Text production in the formatters
> implied code duplication and the problem you describe for tools
> using the library.
> I now committed substantial changes cleaning this up, introducing
> a flag NODE_NOPRT such that content that is required in the source
> code but not intended to be printed can remain in the tree, for
> example the argument of .St, solving the first problem, and introducing
> a flag NODE_NOSRC such that generated content not contained in the
> source document can be marked, allowing to solve the second problem
> and do text generation at the validation stage for all macros, even
> for .Ex and .Rv.  This work required a number of commits; i'm
> appending the commit message of the final one at the end.
> The resulting changes will be in mandoc-1.13.5 and in mandoc-1.14.x
> when released.

This is pretty awesome, any clues about when will 1.13.5 or 1.14.x come out?

 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

      reply	other threads:[~2017-01-11 20:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-02 17:43 Abhinav Upadhyay
2017-01-11 18:53 ` Ingo Schwarze
2017-01-11 20:30   ` Abhinav Upadhyay [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHwRYJ=OZb-xZXAbokqhm7tuPYWMCHR98TsW2+5RyAasb+z_Kg@mail.gmail.com' \
    --to=er.abhinav.upadhyay@gmail.com \
    --cc=discuss@mdocml.bsd.lv \
    --cc=schwarze@usta.de \
    --subject='Re: Parsing of .Ex with -std argument' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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