Nick Dokos <nicholas.do...@hp.com> wrote:
> Carsten Dominik <carsten.domi...@gmail.com> wrote:
>
> > OK, I see, this seems to be because the "\n" is no longer
> > interpreted as a newline character upon macro expansion, so the
> > entire text ends up in the ATTR_HTML line and is treated as a
> > comment.
>
> It seems to be coming from deep with emacs: if I create a buffer
> with
>
> x y z \ x y z
>
> and evaluate (with point somewhere on that line)
>
> (buffer-substring-no-properties (point-at-bol) (point-at-eol))
>
> I get "x y z \\ x y z", so the backslash is escaped willy-nilly.
>
> This happens in org-element-keyword-parser. I don't know if the
> macro expansion would replace \n with a newline absent the extra
> backslash, but I'm sure that its presence does not help any.
>
Even if I delete the extra backslash from the value of the macro
in org-macro-initialize-templates, the regexp fails to properly
match:
,----
| ;; Install buffer-local macros.
| (org-with-wide-buffer
| (goto-char (point-min))
| (while (re-search-forward "^[ \t]*#\\+MACRO:" nil t)
| (let ((element (org-element-at-point)))
| (when (eq (org-element-type element) 'keyword)
| (let ((value (org-element-property :value element)))
| (when (string-match "^\\(.*?\\)\\(?:\\s-+\\(.*\\)\\)?\\s-*$" value)
| (funcall set-template
| (cons (match-string 1 value)
| (or (match-string 2 value) "")))))))))
`----
OTOH, if I modify the cell argument inside set-template[fn:1] to get rid of
the extra backslash, the macro expansion happened as expected.
Nick
Footnotes:
[fn:1] This is obviously a gross hack, only meant as a debugging aid.
In fact, I didn't even code it up: I just stepped through the
thing with edebug and slammed the modified value into the cell
argument.
