Open dudelson opened 3 years ago
Originally I thought that this bug occurred when a page ref was followed by any non-whitespace character, but I noticed just now that it actually appears to be only alphanumeric characters. I've updated the issue title and initial comment accordingly.
@tangjeff0 @neotyk Is this a bug or a feature? Either way, we have to make it consistent. Currently one can prepend a page ref with character/word but it is not possible to append a word or to have a page ref be surrounded by word. We either have to allow all 3 cases or disallow them, if allow all the cases then it would inconsistent with hashtags where we disallow all the cases.
Certainly a bug @neotyk
I looked into this issue and found that this issue can be reproduced for many structures which are parsed inline. For e.g all of the following structures can have a character/word prepended to them but cannot append :
This is because I think the inline parser has some bugs is inconsistent:
text-run
's grammar $
, #
, {
while others are escaped. This causes inconsistency in my opinion, I think we should allow any inline structure to be surrounded by words and leave the decision of how to format text to the user.*
, ^
etc. parser produces a tree with node text-run
which contains the characters till the escaped character, for e.g for the sequence abc*def*
parser will produce text-run abc
and emphasis *...
. This causes the issue of prepended characters getting accepted along with the structure.So, to solve this issue I think we have to correct text-run's grammar and update the grammar of structures for whom it is acceptable to be surrounded by words/characters as we do for block-ref.
Please correct me if I mistake somewhere @neotyk @tangjeff0
Problem
If a page ref is immediately followed by an alphanumeric character after the closing double brackets, it is not parsed as a page ref, and is thus not clickable.
Screenshots/Demo
Athens Version
1.0.0-beta.82