pandoc generates a pdf from a markdown file that truncates and looses characters inside blocks ``` ... ```

Question

Under Debian 10 and for a long time, with various versions of Pandoc, I'm generating a pdf file from a markdown document, using this command :

pandoc elk.md -o elk.pdf

Inside the elk.md file there's this content under a ```bash block:

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list

It generates a pdf with its line truncated :

An attempt to copy it, even by selecting it as a block, with one line above and below in the generated pdf, only retains this part of the text :

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sou

and the original content is lost.
What is the workaround to make pandoc working properly ?

Note 1 : adding line feed manually (with also additional \ characters when necessary) like below :

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" \ 
  | sudo tee /etc/apt/sources.list.d/elastic-7.x.list

won't be a solution.
If I add a larger source content in a block, I don't plan to check and edit all of its lines.

Note 2 : In this sample, the markdown hasn't an header, so the pdf is generated with its (curious) default margin of 6 or 8 (?) centimeters. I usually add this header :

---
geometry: margin=2cm
classoption: fleqn
---

• To set its margin to 2 centimeters only.

• To allow better formatting of some latex content and allow the use of mathematic formula if needed, and also text color.

But this doesn't change the trouble I'm facing.

Revamp

I think these links should be useful: tex.stackexchange.com/q/323329, tex.stackexchange.com/q/179926. You could also try minted instead of listings, see github.com/pandoc/lua-filters/tree/master/minted. – Jammiejammin

Answer 1

@tarleb : Thanks a lot. Among your links, I found the beginning of a solution that improves greatly the situation:

Adding a header-includes section to my markdown headers is simple and removes most of the disturbances. (I read that other solutions like the \lstset definition were adding as many problems as solutions, and didn't try them).

---
header-includes:
- \usepackage{fvextra}
- \DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines,breakanywhere,commandchars=\\\{\}}
- \DefineVerbatimEnvironment{verbatim}{Verbatim}{breaklines,breakanywhere}

geometry: margin=2cm
classoption: fleqn
---

You can see the improvement!
But... An extra character is inserted: → and if you copy paste the content, your clipboard contains :

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee
, →
/etc/apt/sources.list.d/elastic-7.x.list

1. three lines, instead of one
2. one of them is especially wrong, with a parasite comma coming from nowhere and an extra →

This could cause problem if you copy-paste this content.
(for instance, if you paste it on your terminal, confident, it would begin to execute: echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee before taking into account all that is needed to execute the command)

Explanation of commands

1. The \DefineVerbatimEnvironment{Highlighting}... command redefines the Highlighting environment (which highlights code syntax) as a new "fancy" verbatim environment with special properties that allow it to break lines.
2. The \DefineVerbatimEnvironment{verbatim}... command does a similar thing for the verbatim environment (which is a different environment that has no syntax highlighting).

Revamp