Closed gwern closed 3 years ago
This bit of trace output shows what I think is the problem: it looks like we're doing one Pop too many on line end. We should end up still in CommandArgs, I think. So my guess is that there is a problem in the logic where checkLineEnd
is run.
RegExpr MATCHED Just (NormalTok,"f")
CONTEXT STACK ["PathThenPop","WordRedirection2","CommandArgs","Group","Start"]
checkLineEnd for "PathThenPop" eol = True cLineEndContext = [Pop,Pop]
checkLineEnd for "WordRedirection2" eol = True cLineEndContext = [Pop]
checkLineEnd for "CommandArgs" eol = True cLineEndContext = [Pop]
CONTEXT STACK ["Group","Start"]
Never mind, I don't think that's the issue. This is fine, I just misinterpreted it.
Real problem is shown just a bit further down:
CONTEXT STACK ["PathThenPop","WordRedirection2","CommandArgs","Group","Start"]
checkLineEnd for "PathThenPop" eol = True cLineEndContext = [Pop,Pop]
Doing context switches for [Pop,Pop]
checkLineEnd for "WordRedirection2" eol = True cLineEndContext = [Pop]
Doing context switches for [Pop]
checkLineEnd for "CommandArgs" eol = True cLineEndContext = [Pop]
Doing context switches for [Pop]
CONTEXT STACK ["Group","Start"]
CONTEXT STACK ["Group","Start"]
CONTEXT STACK ["Group","Start"]
CONTEXT STACK ["Start"]
We shouldn't be exiting from the Group context til we hit the }
.
I was reinstalling Pandoc/skylighting from HEAD last week, and that has led to a crop of sudden appearances of the "er" syntax highlighting class on code that ran fine when I wrote them*, and didn't have any syntax highlighting issues before. Looks like it's only 'Bash' syntax, and it seems to usually involve '>' and periods in identifiers.
* since I don't use "er" in any code samples deliberately, I have a grep test to make sure none appear in generated outputs
The simplest example I could construct by hand:
(This is valid Bash and executing
f
simply creates an empty file namedf
.)pandoc -w html
→Delete the
>
and the final bracket gets correctly parsed as<span class="kw">}</span>
. This can be simplified further to>f
but I'm not sure whether that's really sensible Bash; it does suggest that the error is triggered by a '>' with anything after it.(One caveat here: to work around the self-linking numbering-lines in skylighting, which completely screws up gwern.net CSS and can't be disabled in any way even when numbered-lines are not ever used, I manually edit skylighting to delete the
H.span
stuff fromsourceLineToHtml
; I can't see how that patch would screw up only a handful of my Bash code samples, but I mention it just in case.)