> Would it be feasible for the https://ctan.org/pkg/markdown package to support an option to control whether to generate ASCII space or \pandocSpace (perhaps with a default of generation ASCII spaces)? The https://ctan.org/pkg/markdown package is just a rendering backend for the various *\pandoc** macros. The decision to produce an ASCII space instead of the *\pandocSpace* macro falls on the plain TeX writer *pandoc-to-markdown.lua* from https://github.com/drehak/pandoc-to-markdown/. The option could be passed to the writer easily enough through metadata. Dne středa 2. listopadu 2022 v 15:23:55 UTC+1 uživatel wlu...-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org napsal: > Would it be feasible for the https://ctan.org/pkg/markdown package to > support an option to control whether to generate ASCII space or > \pandocSpace (perhaps with a default of generation ASCII spaces)? > > On Wed, 2 Nov 2022 at 14:17, Vít Novotný wrote: > >> > So, for example, you couldn’t make Spaces appear as visible ␠ >> characters, and you couldn’t make SoftBreaks create hard breaks in the >> output. >> >> Replacing *\pandocSpace* with ASCII spaces makes it difficult to >> reprogram spaces on the top level of the document, but we can definitely >> substitute spaces in parameters of commands such as *\pandocCode*, >> which would cover many (if not most) use cases. >> >> The following example LaTeX document produces the text >> *we␣want␣visible␣spaces␣here* in a monospaced font: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *\documentclass{standalone}\usepackage{xparse}\ExplSyntaxOn\ProvideDocumentCommand >> { \pandocCode } { m } { \pandoc_code:n { #1 } }\cs_new:Nn >> \pandoc_code:n { \tl_set:Nn \l_tmpa_tl { #1 } >> \regex_replace_all:nnN { \s } { \c{textvisiblespace} } >> \l_tmpa_tl \texttt { \l_tmpa_tl } >> }\ExplSyntaxOff\begin{document}\pandocCode{we want visible spaces >> here}\end{document}* >> >> > There may also be line breaks in the source that don't correspond to >> SoftBreak. >> >> Any lines that end with a comment character (%) will skip over the >> newline character. Therefore, we can have newlines in the source code that >> wouldn't trigger the active newline character. >> >> The following example plain TeX document produces the text *foo bar baz*: >> >> *\catcode`\^^M=13* >> >> >> *\def^^M{ bar }%foobaz%* >> *\bye* >> >> Dne čtvrtek 27. října 2022 v 19:09:30 UTC+2 uživatel fiddlosopher napsal: >> >>> >>> > On Oct 27, 2022, at 12:07 AM, Bastien DUMONT >>> wrote: >>> > >>> > Fortunately, it is possible by making the space and the newline >>> characters active in TeX! (Provided that a SoftBreak is rendered as a line >>> break in the TeX output.) This is how \obeylines and \obeyspaces work. >>> >>> But this might not be what you want; after all there are going to be >>> spaces in code blocks, and you might not want to treat them the same way >>> (they do not correspond to pandoc Space elements). There may also be line >>> breaks in the source that don't correspond to SoftBreak. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "pandoc-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com >> >> . >> > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/d2933f0d-4a51-4fd4-bb4f-32b5da362ab9n%40googlegroups.com.