From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: New exporter macro question Date: Mon, 11 Feb 2013 11:31:23 -0500 Message-ID: <419.1360600283@alphaville> References: <8312EEB6-F657-449E-B025-167031ECACAC@gmail.com> <25A6F4AE-47C2-4D7E-9C84-3CC890B3937E@gmail.com> <31732.1360593792@alphaville> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4wIf-0002Av-Eg for emacs-orgmode@gnu.org; Mon, 11 Feb 2013 11:32:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4wIe-00037q-Av for emacs-orgmode@gnu.org; Mon, 11 Feb 2013 11:32:13 -0500 Received: from vms173009pub.verizon.net ([206.46.173.9]:30588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4wIe-00031Y-43 for emacs-orgmode@gnu.org; Mon, 11 Feb 2013 11:32:12 -0500 Received: from alphaville.dokosmarshall.org ([unknown] [108.7.96.134]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MI200H9HDWCFE70@vms173009.mailsrvcs.net> for emacs-orgmode@gnu.org; Mon, 11 Feb 2013 10:31:30 -0600 (CST) In-reply-to: Message from Nick Dokos of "Mon, 11 Feb 2013 09:43:12 EST." <31732.1360593792@alphaville> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Cc: "emacs-orgmode@gnu.org List" , Carsten Dominik Nick Dokos wrote: > Carsten Dominik 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.