跟进本文我用总计划为 Markdown 解析器提供支持潘多克与一些宏。不幸的是,gpp
似乎将所有空白复制到结果中。
例如,考虑文件test.md
% Title
% Raphael
% 2012
\lorem \ipsum
和test.gpp
\define{lorem}{Lorem}
\define{ipsum}{ipsum...}
现在,调用gpp -T --include test.gpp test.md
收益率
<empty line>
% Title
% Raphael
% 2012
Lorem ipsum...
这破坏了pandoc
.额外的换行确实是定义之间的换行;如果我使用
\define{lorem}{Lorem}@@@
\define{ipsum}{ipsum...}
有了额外的选项+c "@@@" "\n"
,空行就消失了。但这个解决方法不仅丑陋,还存在两个致命的缺陷。
首先,它@@@
也被视为源文件中的注释指示器。正如@@@
Markdown 中没有禁止的那样,当@@@
(或任何其他选定的分隔符)碰巧出现在源文件中时,可能会产生意想不到的后果。
其次,它不会覆盖由于正确缩进而导致的行开头的空格。例如,
\define{lorem}{@@@
\if{a == a}@@@
![some image](test.png)@@@
\endif@@@
}@@@
将导致所有此类图像标签缩进四个空格,从而将pandoc
其排版为代码(按照指定)。
那么,除了gpp
在一行中写入文件或引入丑陋的行尾注释并且不缩进之外,您可以采取什么措施来防止gpp
到处涂抹多余的空格呢?
答案1
假设所有垃圾都在包含文件中,因此在文档开始之前,您可以对其进行后处理:
测试.gpp:
\define{lorem}{Lorem}
\define{ipsum}{ipsum...}
----- cut here ------
然后做:
gpp -T --include test.gpp test.md | sed '1,/----- cut here ------/d'
(是否gpp
输出到标准输出?否则仅sed
在输出文件上运行。)
答案2
一种可能性是预处理包含的宏文件并将其缩小为一行(使用sed
)。结合艾迈斯半导体方法,这个 makefile 片段解决了这个问题:
sed 's/^\s*//;s/\s*?$$//;H;$$!d;:e;x;/^$$/d;s/\n//g' $(MACROFILE) > $(BUILDPATH)/$(MACROFILE);
echo "$(MFENDMARKER)" >> $(BUILDPATH)/$(MACROFILE);
gpp -T -x -Dtarget=pdf --include $(BUILDPATH)/$(MACROFILE) $(MAINFILE) | \
sed '1,/$(MFENDMARKER)/d' | \
pandoc -S -R --toc -f markdown -o $(DISTPATH)/$(NAME).pdf;
现在,肮脏的事情隐藏在幕后。