From: Abhinav Upadhyay <email@example.com> To: Ingo Schwarze <firstname.lastname@example.org> Cc: email@example.com 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 <firstname.lastname@example.org> 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? Regards Abhinav -- To unsubscribe send an email to email@example.com
prev parent 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: 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='CAHwRYJ=OZb-xZXAbokqhm7tuPYWMCHR98TsW2+5RyAasb+z_Kg@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Parsing of .Ex with -std argument' \ /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
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).