wiki text ( triple back-ticks \ escaped
<!-- -->
<details>
<summary> bar </summary>
odd
\```
foo
\```
help!
</details>
the content of details is …
odd `
foo
help!
</details>
what non obvious (to me) error(s)
have i made ??!
**or how have i broken the wiki-text parser ?
** idiot available for testing the limits of “idiot proofing”
“yes, I know what a parking meters are” ( quote from Chris morris “Jam” - https://cl.pinterest.com/pin/462041243003990653/)
I think the wikitext parser would still try to parse that somehow, escaping the first backtick still leaves the second/third intact for parsing…
I think you could use <$text text="```" /> to display those backticks, though that’s quite bulky to write…
ahhh
sorry! i was escaping the backticks for THIS forum
because it also uses triple backticks !!!
iv attached the example that fails (for me;)
test-nest-wiki-html.json (214 Bytes)
https://tiddlywiki.com/static/Code%20Blocks%20in%20WikiText.html
aaaah, ok, sorry, misunderstandig
The contents of the <details> element are defaulting to “inline” rendering, which is preventing the tripled backticks from being parsed in “block” mode. To force block mode rendering, wrap the contents inside <div>...</div> with a blank line after the opening <div>, like this (ignore the leading “x” before the tripled backticks… they are just to defeat the Discourse parsing.)
Try this:
<!-- -->
<details>
<summary> bar </summary>
<div>
odd
x```
foo
x```
help!
</div>
</details>
-e
tbh that (div wrap)
was the first thing i looked up and tried !
the single backtick
`
at/from the start of the block
is hinting (imho) that a triple backtick is being
seen as 2 single backticks and this case causes unexpected results
for some reason
?? because the wiki text is “in” html ??
… because it works fine when not warped in <detail>
It needs a blank line after the opening <div>, otherwise it’s still parsed as “inline” content.
from bit more testing it
seams my problem was also
caused by a space after ```
so div without newline
AND spaces after ```
can cause strange / counterintuitive results
so this related to the parser ? ( and not html css , block inline??)
as i see in
editor>preview
has options for [ block / inline ]
There is a button in the editor toolbar that you can select multiple lines with and click to add the backticks in the block form, this takes account of the requirements.
The buttons help you by adding the empty lines etc…
wiki_user dont click
like “Dereks don’t run!”
try it 
day dreams
id take wiki-text lint
… informing me of my dodgy markup syntax
… ( better still visually convey white space[1])
over
hiding that info behind <do-magical-correct-thing> button
and the advice “just click”
=/
… more just the facts : this is bad syntax (doc link(click))
… less change your processes : click our button
…***
.List of tools for static code analysis - Wikipedia
id rather click once (and only once) on a plugin that adds a
"bad wiki-text klaxon 
"
or just highlight-space-at-end-of-line plugin
or go off on some css tangent to find how to highlight space char
… or not
=[
text areas can only contain plain text.
In other words, we’re unable to style the content that’s entered.
compared to the above hack needed to even
begin to mess with highlighting in web-browser-land
in other environments (terminal,) its better natively supported
.https://unix.stackexchange.com/questions/556643/nano-highlight-trailing-whitespaces
i guess i need to take a step back
from the click-addiction / gui’s
& reduce my productivity expectations for such environments
and kind of use/thought patterns they encourage 
i guess my best bet to work around the gui enviroment is
update-filesystem-plugin and a terminal text editor
see-also: https://wiki.c2.com/?PowerOfPlainText
\rant
like
just add more ram/memory
or
just add more data/context to a anthropomorphized statistical model
just click a bit more
it’s not a practical solution , or sustainable
at best
its a (the button: 20+ year old ) stop gap
at worst that sort of thinking is
.Repetitive strain injury - Wikipedia
waiting to happen
imho
/rant
with all due respect I don’t know what you are saying.
in my ideal world 
id click less
and
the tools might help make bad syntax obvious
via some text ‘bad syntax alert’
or
probably the similar reasons motivate this sort of thing
common theme’s : external editors + less clicks
sorry my post was to long
it should have been less words
less is more !
the editing process is to long
it should(could it?) be less clicking !
(and some how more informative )
Please let me highlight the point I was making. Use the keyboard as much as you want and avoid touching button but when this self imposed limit means you dont know how to use the features and formatting, just use an Editor toolbar button to see what it does.
before
select this and click
after
becomes
before
'''
select this and click
'''
after
single quotes used to simulate backticks
It inserts the triple backticks with the required proceeding and following blank lines.
I am sure you can “find your people” here in tiddlywiki, there is a large number of “keyboard centric” tiddlywiki users and many tools to placate them.
im only hear to chew gum
and shoo bugs & bad iu
and im all out of gum!
what im saying
could the editing process make ~problem-causing~ syntax ambiguities / errors more obvious / with out introducing more process/clicking?
and partially answered
conclusion
tiddly-wiki is/was a wonderful thing
making the best of an
(increasingly) terrible (enshittified) environment
browsers (and the influences that develop them)
are
more HYPER
less text
from an increasingly more text
perspective its some what tragic to observe
that many who can’t/don’t see any alternative to
graphic user interface (ever existed)
wont know what advantages such environment’s (can) bring
or how subtlety dominant graphic user interface
can influence perspectives / imagination & possibilities
c’est la vie