MyST-Parser
MyST-Parser copied to clipboard
Incorrect line number being shown
Describe the bug
I am using sphinx-build to build some markdown pages.
I noticed some errors in the build yesterday that were referring to lines that don't exist in the file affected.
e.g. I received this error message:
/opt/azdo-agent/_work/1/s/solution_components/platform-tci.md:6172: WARNING: Non-consecutive header level increase; 2 to 4 [myst.header]
So this suggests the error is on line 6172 of the platform-tci.md file. However, that file only has 5475 lines.
When checking, all the other warnings that were found in that build (and others) refer to seemingly random line numbers?
Initially logged here but advised to log in this project.
Reproduce the bug
Hard to share steps as I can't share the document in use (sensitive info), but essentially:
make html
where the Makefile is:
SPHINXOPTS = -W -n --keep-going
SPHINXBUILD = sphinx-build
SOURCEDIR = .
BUILDDIR = .
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
List your environment
Ubuntu 20.04
pyhon v3.8
sphinx-build v4.3.1
Sphinx extensions:
- myst_parser
- sphinxcontrib.mermaid
- sphinxcontrib.inkscapeconverter
- sphinx.ext.githubpages
- sphinx.ext.autosectionlabel
- sphinx_markdown_tables
- sphinx_panels
Thanks @tomkivlin, but yeh, it would certainly be helpful if you could provide any details for reproducibility, prefereably a minimal working example 😬
For example, do you see the correct line number for something simple like:
# A
### B
what directives are used within the document?
are you using any include directives?
Thanks @tomkivlin, but yeh, it would certainly be helpful if you could provide any details for reproducibility, prefereably a minimal working example 😬
For example, do you see the correct line number for something simple like:
# A ### Bwhat directives are used within the document? are you using any
includedirectives?
OK - I will put something together
thanks, that would be much appreciated 🙏
I am experiencing something at least similar to what @tomkivlin reported. In a project using both myst_parser and sphinxcontrib.spelling, the spelling errors are attributed to the wrong lines in many situations. This appears to affect Markdown files in many more scenarios than reStructuredText files (though the spelling extension still gets it slightly wrong for headings in reStructuredText files, but this is much less annoying since they're closer to the typo that matters).
With MyST files, I observe that:
- Some spelling errors are attributed to line 0
- Some spelling errors are attributed to the most recent directive, no matter how far below that directive they actually appear.
You should be able to clone https://github.com/leifwalsh/myst-parser-issue-546 in a dev container (dependencies should be automatically installed) and reproduce what I see with:
sphinx-build -WEa -b spelling source build
You should see output like this:
source/index.md:0: : Spell check: mispeld: This paragraph has a mispeld word. But that misspelling is attributed.
source/index.md:6: : Spell check: attributd: I contain a typo. But that typo is attributd to the warning above..
source/rst-file.rst:2: : Spell check: reStructuredText: reStructuredText file.
source/rst-file.rst:4: : Spell check: reStructuredText: This file contains reStructuredText, which amazingly, is a misspelled word..
source/rst-file.rst:10: : Spell check: paragrphs: A note between paragrphs doesn't make sphinxcontrib.spelling confused.
source/rst-file.rst:14: : Spell check: typoed: This paragraph also has a typoed word. But it is correctly attributed to.
The text in that repo explains the problem. The spelling errors noted in the Markdown file are both wrong in different ways, but the errors in the reStructuredText file are attributed to more or less the correct lines.
For impact context, we have some repos in which we would like to provide a spellcheck VS Code task that runs the spell checker plugin and uses a VS Code problem matcher to identify those as problems in the source. When we do this it underlines completely incorrect lines and makes life harder for authors and editors of documentation.
(I would be happy to share a working config for this task if anyone is interested in including it in ExecutableBooks documentation: it's quite nice apart from this bug)