💾 Archived View for thatit.be › 2023-04-20-22-36-13.gmi captured on 2024-05-12 at 15:31:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
➡️ Next capture (2024-05-26)
-=-=-=-=-=-=-
Apparently Pandoc is picky about what would otherwise be the alt text for a code block. My measuring stick has become to call Pandoc with a destination of -t markdown_strict so that it will show me the markdown it thinks it just parsed. I’m occasionally surprised by the results.
For example, this is entirely valid:
echo foo
This will produce the following in pandoc -t markdown_strict:
echo foo
Now here’s what it does with some of my (not fixed) notes…
#!/bin/bash
##
# This script does blah blah blah
. settings.sh
# more content...
And that will get butchered like this:
bash file: touch.sh #!/bin/bash ## # This script does blah blah blah . settings.sh # more content...
Instead of a fence, it’s apparently an empty inline code segment followed by some more inline code, and since it’s not a fence, it will condense the whitespaces.
My intention was to create a fence, indicate that it was bash syntax, and put the name in a convenient location. That didn’t work out so well.
This is also fine:
fun(){
local FOO=${1}
echo "${#FOO}"
}
It will correctly become this:
#!/bin/bash
##
# More comments...
fun(){
local FOO=${1}
echo "${#FOO}"
}
And this is not fine.
fun(){
local FOO=${1}
echo "${#FOO}"
}
It will similarly become:
`bash script: foo.sh #!/bin/bash ## # More comments... fun(){ local FOO=${1} echo "${#FOO}" }`
To summarize, these are all valid fence beginnings:
And these are not valid because of the additional words:
I had started putting a sentence at the beginning of the fence to act as alt text because I didn’t realize it was invalid.
I don’t know where using a sentence as the first line for alt text came from, but it’s not a thing and I should stop trying to do it.
updated: 2023-04-26 22:22:38
generated: 2024-05-03