From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Federico Vaga <federico.vaga@vaga.pv.it>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH] docs: conf.py: avoid thousands of duplicate label warning on Sphinx
Date: Fri, 20 Mar 2020 12:59:18 +0100 [thread overview]
Message-ID: <20200320125918.5eb5af04@coco.lan> (raw)
In-Reply-To: <3508337.2CZTLhteCP@harkonnen>
Em Fri, 20 Mar 2020 12:24:45 +0100
Federico Vaga <federico.vaga@vaga.pv.it> escreveu:
> On Friday, March 20, 2020 12:12:35 PM CET Mauro Carvalho Chehab wrote:
> > The autosectionlabel extension is nice, as it allows to refer to
> > a section by its name without requiring any extra tag to create
> > a reference name.
> >
> > However, on its default, it has two serious problems:
> >
> > 1) the namespace is global. So, two files with different
> > "introduction" section would create a label with the
> > same name. This is easily solvable by forcing the extension
> > to prepend the file name with:
> >
> > autosectionlabel_prefix_document = True
> >
> > 2) It doesn't work hierarchically. So, if there are two level 1
> > sessions (let's say, one labeled "open" and another one "ioctl")
> > and both have a level 2 "synopsis" label, both section 2 will
> > have the same identical name.
> >
> > Currently, there's no way to tell Sphinx to create an
> > hierarchical reference like:
> >
> > open / synopsis
> > ioctl / synopsis
> >
> > This causes around 800 warnings. So, the fix should be to
> > not let autosectionlabel to produce references for anything
> > that it is not at level one, with:
> >
> > autosectionlabel_maxdepth = 1
>
> So, for level 1 headers is fine to use autosectionlabel, but if we want to
> refer to level 2,3... we have to create labels manually.
Yes.
If we want to use it for other levels, the autosectionlabel extension
would need to be modified to work on an hierarchical way, creating an
unique label that would contain the entire hierarchy, starting from
the filename.
Also, ideally, it should also handle cross-reference locally, searching
first for a reference at the same hierarchical level, then at level - 1
and so on.
I suspect that, even with that, we may still have some troubles, as
right now some files may have explicitly defined a reference like
that, but those would likely be easy to fix.
Thanks,
Mauro
next prev parent reply other threads:[~2020-03-20 11:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 11:53 [PATCH] doc: fix reference to core-api/namespaces.rst Federico Vaga
2019-11-22 17:34 ` Jonathan Corbet
2019-11-24 17:02 ` Federico Vaga
2020-03-20 10:21 ` Mauro Carvalho Chehab
2020-03-20 11:12 ` [PATCH] docs: conf.py: avoid thousands of duplicate label warning on Sphinx Mauro Carvalho Chehab
2020-03-20 11:24 ` Federico Vaga
2020-03-20 11:59 ` Mauro Carvalho Chehab [this message]
2020-03-20 13:22 ` Mauro Carvalho Chehab
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=20200320125918.5eb5af04@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=corbet@lwn.net \
--cc=federico.vaga@vaga.pv.it \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).