Aloha all, This Org source: - {{{kbdkey(S-,TAB)}}} or {{{kbdspckey(C-u,TAB)}}}, ~org-global-cycle~ :: yields this texinfo output: @item @kbd{S-@key{TAB}} or @kbd{C-u @key{TAB}}, @code{org-global-cycle} which looks fine in info: `S-<TAB>' or `C-u <TAB>', `org-global-cycle' and in pdf: S-TAB or C-u TAB, org-global-cycle but not in html: S-TABor C-u TAB, org-global-cycle which loses the space between `TAB' and `or'. Help? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Thomas S. Dye writes: > Help? Nice riddle. But here's what I think is happening: your macro expansion ends with a texinfo export snippet. That export snippet is ignored by the the HTML backend as it should, but in doing so the post-blank that the export snippet has gobbled up greedily during parsing also vanishes. What I'm unsure about is how it gets back into the game for the texinfo export, as the plain expansion does not seem to insert it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Aloha Achim, Achim Gratz <Stromeko@nexgo.de> writes: > Thomas S. Dye writes: >> Help? > > Nice riddle. But here's what I think is happening: your macro expansion > ends with a texinfo export snippet. That export snippet is ignored by > the the HTML backend as it should, but in doing so the post-blank that > the export snippet has gobbled up greedily during parsing also > vanishes. What I'm unsure about is how it gets back into the game for > the texinfo export, as the plain expansion does not seem to insert it. Oh, I didn't realize there are two sets of html files generated. The html generated by makeinfo --html is fine. The problem is with html generated by Org. I haven't worked with the new html exporter at all, so I won't be much help debugging this (as if!). I'll need to wait for Jonathan or Nicolas to chime in. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[-- Attachment #1: Type: text/plain, Size: 216 bytes --] Hi Thomas, the attached (dirty) patch fixes it. It's clearly not the right approach, though. I hope Nicolas can have a look soon, as the problem affect all uses of snippets in macros. Thanks for reporting this, [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: org-fix-snippet-post-blank.patch --] [-- Type: text/x-patch, Size: 1412 bytes --] Changes in master Modified lisp/ox-html.el diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 9307081..6750ffc 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -2024,8 +2024,9 @@ information." "Transcode a EXPORT-SNIPPET object from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information." - (when (eq (org-export-snippet-backend export-snippet) 'html) - (org-element-property :value export-snippet))) + (if (eq (org-export-snippet-backend export-snippet) 'html) + (org-element-property :value export-snippet) + (if (< 0 (org-element-property :post-blank export-snippet)) " "))) ;;;; Export Block Modified lisp/ox-latex.el diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index fa66bb4..5362edf 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -1337,8 +1337,9 @@ CONTENTS is nil. INFO is a plist holding contextual information." (defun org-latex-export-snippet (export-snippet contents info) "Transcode a EXPORT-SNIPPET object from Org to LaTeX. CONTENTS is nil. INFO is a plist holding contextual information." - (when (eq (org-export-snippet-backend export-snippet) 'latex) - (org-element-property :value export-snippet))) + (if (eq (org-export-snippet-backend export-snippet) 'latex) + (org-element-property :value export-snippet) + (if (< 0 (org-element-property :post-blank export-snippet)) " "))) ;;;; Fixed Width [-- Attachment #3: Type: text/plain, Size: 14 bytes --] -- Bastien
Hello,
Bastien <bzg@altern.org> writes:
> the attached (dirty) patch fixes it. It's clearly not the right
> approach, though. I hope Nicolas can have a look soon, as the problem
> affect all uses of snippets in macros.
I don't have time to look at the problem right now. I will probably do
it sunday.
Thank you.
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 608 bytes --] Hello, Bastien <bzg@altern.org> writes: > the attached (dirty) patch fixes it. It's clearly not the right > approach, though. I hope Nicolas can have a look soon, as the problem > affect all uses of snippets in macros. What about the following patch? The export framework usually treats differently empty string from nil output. Only in the former blank lines/white spaces are preserved. With this patch it will not be possible anymore to make this distinction with export snippets. What do you think? I'll add some tests in test-ox.el if this patch is to be applied. Regards, -- Nicolas Goaziou [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-ox-White-spaces-after-export-snippets-are-never-igno.patch --] [-- Type: text/x-patch, Size: 1319 bytes --] From 9fed50f6760aa34a426981d3606285c090ffd5bd Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou <n.goaziou@gmail.com> Date: Thu, 21 Mar 2013 20:08:24 +0100 Subject: [PATCH] ox: White spaces after export snippets are never ignored * lisp/ox.el (org-export-data): White spaces after export snippets are never ignored. Back-end developers should pay attention to the fact that white spaces before and after an ignored export snippet now are accumulated in the output. --- lisp/ox.el | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index a545bb9..160f73f 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -2062,8 +2062,12 @@ Return transcoded string." (eq (plist-get info :with-archived-trees) 'headline) (org-element-property :archivedp data))) (let ((transcoder (org-export-transcoder data info))) - (and (functionp transcoder) - (funcall transcoder data nil info)))) + (or (and (functionp transcoder) + (funcall transcoder data nil info)) + ;; Export snippets never return a nil value so + ;; that white spaces following them are never + ;; ignored. + (and (eq type 'export-snippet) "")))) ;; Element/Object with contents. (t (let ((transcoder (org-export-transcoder data info))) -- 1.8.2
Hi Nicolas,
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> The export framework usually treats differently empty string from nil
> output. Only in the former blank lines/white spaces are preserved. With
> this patch it will not be possible anymore to make this distinction with
> export snippets.
>
> What do you think?
I think it is good, please go ahead!
Thanks,
--
Bastien
Hello,
Bastien <bzg@altern.org> writes:
>> The export framework usually treats differently empty string from nil
>> output. Only in the former blank lines/white spaces are preserved. With
>> this patch it will not be possible anymore to make this distinction with
>> export snippets.
>>
>> What do you think?
>
> I think it is good, please go ahead!
Done.
Regards,
--
Nicolas Goaziou