A smiley: :)
A footnote
A smiley after the footnote: :)
The smiley before the footnote renders, the one after no.
BUGZ!
moar pain !
The old problem (that is likely the same this time) was that the parses cuts at \r (IIRC) to identify the blocks to parse and parses any other one (all the odds I think), but when the footnotes is present, in order to... I don't remember why, a \r is added that is not paired with a corresponding one and the counting breaks.
I even found the two commits:
https://github.com/elkarte/Elkarte/commit/85b61e1acaa2406645a28cc451c859b81f7f4ea0
https://github.com/elkarte/Elkarte/commit/cef7d23473c1e8e239f9fc5ce2b82323a745d64a
the changes seem to be still there, so it may be some other side-effect.
This parser is (still) pretty fragile... :-\
As a test I reverted
https://github.com/elkarte/Elkarte/commit/85b61e1acaa2406645a28cc451c859b81f7f4ea0#diff-77070835a61e61758d87314cb3c2ad65L1205
and
https://github.com/elkarte/Elkarte/commit/85b61e1acaa2406645a28cc451c859b81f7f4ea0#diff-77070835a61e61758d87314cb3c2ad65L1207
And the second smiley rendered correctly. Were those two changes just for this testcase or are there others that it fixed?
Just reverting the change on the return (line 1207) https://github.com/elkarte/Elkarte/commit/85b61e1acaa2406645a28cc451c859b81f7f4ea0#diff-77070835a61e61758d87314cb3c2ad65R1207 seems to allow the second smiley to render ...
Ah .. but then a smiley inside of the footnote does not render LOL
OK .. I think reverting those changes inside of footnoteCallback() and then changing the following code in handleFootnotes() may fix the issue.
$this->message .= '<div class="bbc_footnotes">' . implode('', $this->fn_content) . '</div>'; $this->message .= $this->smiley_marker . '<div class="bbc_footnotes">' . implode('', $this->fn_content) . '</div>' . $this->smiley_marker;
/me feels we need a test as well. :P
Yeah I'll add one to the parser tests when I make the above PR ... most times when we get a bug we should really add a coverage test :(
Fixed at some point.
With a test :D
Footnote directly at the end of line.[footnote]Footnote[/footnote]
Should be an empty line in between.
Footnote directly at the end of line.
Should be an empty line in between.
Traditional workaround:Footnote not directly at the end of line, but with an extra space at the end.[footnote]Footnote[/footnote]
Should be an empty line in between.
Footnote not directly at the end of line, but with an extra space at the end.
Should be an empty line in between.
Workaround for the sake of testing:Footnote not directly at the end of line, but with an extra [i]thin[/i] space at the end.[footnote]Footnote[/footnote]
Should be an empty line in between.
Footnote not directly at the end of line, but with an extra
thin space at the end.
Should be an empty line in between.
Edit: same problem in the OP btw.
A footnote[footnote]Something[/footnote]
A smiley after the footnote: :)
So basically the easy space workaround has been broken. NOOOOO! :P
I think we should drop footnotes as to hard, can't fix !
lol, but they're so nice!
If I change the code to:
self::ATTR_TRIM => self::TRIM_NONE,
...
self::ATTR_BLOCK_LEVEL => false,
the examples by
@Frenzie are working as expected.
Is there a particular reason why it is block level?
If you want it to start on a a new line (div, p), should it not be block level? I'm glad we have a fix :D, but it seems counter intuitive, or I've just had to much wine tonight! Did you try it with just the self::TRIM_NONE?
If you made that live on this site then it looks like you may have broken code-block escaping with that.
Edit: pastebin just to be safe although all should be clear when you quote/edit https://pastebin.com/66sU7B0x
Yep, tried with only trim and doesn't change much.
But why do you need a new line after the footnote?
The bbcode converts:
a [footnote]something[/footnote] else
to:
a [1] else
and that "[1]" should not be a block-level. Or not?
@Frenzie yep, I noticed, I applied locally a possible fix, but I'm not entirely sure it doesn't break anything else, basically I strtr "[" and "]" inside any code block to the corresponding html entity so that the footnote code doesn't replace them with the html.
TBH I'm not sure what the behavior should be after the [1] .... I don't think it should cause an automatic line break, in which case it should not be block level (the [1] that is, where as the notes themselves should each be on a new line)
Footnotes are inline, but they shouldn't eat the next paragraph when they are at the very end of a line. They should behave exactly the same as
a regular superscript link (http://duckduckgo.com). Fake footnote follows.
[1] (http://duckduckgo.com)A new paragraph.
Edit:
Um, btw, that's:
[sup][url=http://duckduckgo.com][1][/url][/sup]
Testing subscript:
a regular subscript link (http://duckduckgo.com)Testing superscript:
a regular superscript link (http://duckduckgo.com)
Humm links inside sub / sup are fighting the vertical alignment ... trying a css tweak now
Looks good to me. How do we add a unit test to prevent regressions?
https://github.com/elkarte/Elkarte/pull/2904