help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Aman Verma <amanraoverma+vim@gmail.com>
Cc: discuss@mandoc.bsd.lv
Subject: Re: Not all section headers have id in HTML output
Date: Fri, 30 Oct 2020 14:35:16 +0100	[thread overview]
Message-ID: <20201030133516.GA90785@athene.usta.de> (raw)
In-Reply-To: <CA+c7JOB8Qk-wWzcytLqQf4FuopBfRnLF16DtmXftPnkE7C3obQ@mail.gmail.com>

Hello Aman,

Aman Verma wrote on Wed, Oct 28, 2020 at 06:40:45PM -0400:

> Thanks for the fix for the `pre` bug. I have another (possible)
> bug to report:
> In the HTML output for mdoc(7)[1] the first two section headers don't
> have an id attribute. In fact, it seems that two other elements down the
> page have taken the ids ("NAME" and "DESCRIPTION") that the first two
> headers were supposed to have.

That is true.  Automatic tagging of the .It macro tagged with
TAG_STRONG whereas .Sh only tagged with TAG_WEAK.

> This makes it impossible to link to those headers and also breaks the
> table of contents generated with the `-O toc` option to mandoc.

You are right; arguably, that is not ideal.

So i changed the priority from TAG_WEAK to TAG_STRONG for all
headers where the header text can be used as the fragment identifier
without any modification; that includes single-word titles, in
particular NAME and DESCRIPTION, see the patch below.

I do see value in having ...#DESCRIPTION always linking to the
description, just as you say.

I have also installed the changed code on https://man.openbsd.org/
such that the new behaviour can be easily inspected.

Thanks for the suggestion,

Log Message:
Promote section headers that can can be used unmodified as fragment 
identifiers from TAG_WEAK to TAG_STRONG, 
such that for example ...#DESCRIPTION always works.
Suggested by Aman Verma on the discuss@ list.

Modified Files:

Revision Data
Index: mdoc_validate.c
RCS file: /home/cvs/mandoc/mandoc/mdoc_validate.c,v
retrieving revision 1.387
retrieving revision 1.388
diff -Lmdoc_validate.c -Lmdoc_validate.c -u -p -r1.387 -r1.388
--- mdoc_validate.c
+++ mdoc_validate.c
@@ -2617,7 +2617,7 @@ post_section(POST_ARGS)
 			if ((nch = n->child) != NULL &&
 			    nch->type == ROFFT_TEXT &&
 			    strcmp(nch->string, tag) == 0)
-				tag_put(NULL, TAG_WEAK, n);
+				tag_put(NULL, TAG_STRONG, n);
 				tag_put(tag, TAG_FALLBACK, n);
Index: man_validate.c
RCS file: /home/cvs/mandoc/mandoc/man_validate.c,v
retrieving revision 1.154
retrieving revision 1.155
diff -Lman_validate.c -Lman_validate.c -u -p -r1.154 -r1.155
--- man_validate.c
+++ man_validate.c
@@ -324,7 +324,7 @@ post_SH(CHKARGS)
 					*cp = '_';
 			if (nc != NULL && nc->type == ROFFT_TEXT &&
 			    strcmp(nc->string, tag) == 0)
-				tag_put(NULL, TAG_WEAK, n);
+				tag_put(NULL, TAG_STRONG, n);
 				tag_put(tag, TAG_FALLBACK, n);
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

      reply	other threads:[~2020-10-30 13:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 22:40 Aman Verma
2020-10-30 13:35 ` Ingo Schwarze [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=20201030133516.GA90785@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=amanraoverma+vim@gmail.com \
    --cc=discuss@mandoc.bsd.lv \


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