It has been a long standing issue I observed but I think this time I want to raise it to see if anyone have a solution.
Basically the SB parsing and linking fails when the header contains a link like the following, this will break the syntax [[file#header]] because there is a pair of square bracket inside:
FYI, I filed a bug report for this on GitHub, since it shares an issue in common with some other rendering issues I discovered while reading through the manual.
Oops, I misread OP’s comment. To be clear, it looks to me like OP’s screenshot is showing two separate issues:
Putting markdown in a heading breaks internal linking
SilverBullet parses “Page Title#Header” as text (Page Title) + tag (#Header) (anywhere outside of a valid [[Internal Link]]).
OP was complaining about problem #1; that’s the “regression” you described (sort of; the PR that closed it only applies to TOC rendering) and the complaint in the other post with the “very similar issue”.
The GitHub issue I filed is for problem #2, which is still visible in OP’s screenshot, and in a couple places in the manual.
Yeah this is an issue. I looked at what obsidian does and they seem to just sanitize out any characters which are bad (so any closing and opening braces, other markdown characters are ok, it seems), i.e. links cannot include these characters (makes sense because if e.g. the header would contain ]] it would end the link early and the heading wouldn’t be complete). This seems reasonable, but good luck to anybody implementing that, all the linking code is stitched together regexes, with so much “undefined behaviour” … (This also isn’t really related to the regression I think tho)
I don’t quiet know what you mean. I think the “issue” here is that the parser parsers the inner link, which was part of the original title, but not the outer one. This is kind of expected, I didn’t look at the markdown spec (although I don’t even know if wiki links are spec), but I wouldn’t know what else the parser should do except parse the outer link first. I think the best solution and the solution to all the numerous other issues here and on github, would be to provide a new markdown syscall, which more or less does what the “stripping” function did and anytime anybody puts user generated text into a link or something similar one should sanitize it. (Including the stdlib for the TOC for example)