Re: New exporter macro question

[Nick Dokos <nicholas.dokos@hp.com>]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Carsten Dominik <carsten.dominik@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.