Re: new exporter

Re: new exporter

[Jambunathan K]

Achim Gratz <Stromeko@nexgo.de> writes:

> * contrib/lisp/org-e-html.el: Remove declarations and replace with
>   require.

Thanks for this.  I have applied some hunks.  The rest I will revisit at
opportune moment.

I have also taken care of org-e-odt.

-- 

Re: new exporter

[Achim Gratz]

Achim Gratz writes:
> The way org-export is structured unfortunately produces circular
> dependencies due to the dispatcher and that prevents it from being
> compiled properly.

It appears the reason for this is rather the use of cl macros in the
dispatcher code.  Depending on where you require org-export and what is
already byte-compiled, things start to explode.  Nicolas, could you have
a look on what is going on there?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

>here's my first stab on fixing some of that:
>
> From d7ef1bfbaef873521731697d86112029f02cdc8b Mon Sep 17 00:00:00 2001
> From: Achim Gratz <Stromeko@Stromeko.DE>
> Date: Sat, 2 Jun 2012 18:38:24 +0200
> Subject: [PATCH 5/5] Make byte-compiler more happy
>
> * contrib/lisp/org-e-ascii.el: Remove declarations and replace with
>   require.
>
> * contrib/lisp/org-e-html.el: Remove declarations and replace with
>   require.
>
> * contrib/lisp/org-e-latex.el: Remove declarations and replace with
>   require.
>
> * contrib/lisp/org-e-publish.el: Remove declarations and replace with
>   require.
>
> * contrib/lisp/org-export.el: Remove declarations and replace with
>   require.  Prevent byte-compilation, it currently would produce an
>   error due to circular dependencies in the file.

declarations (instead of requires) are here to avoid circular
dependencies. Why do you want to revert that in the first place?

> The way org-export is structured unfortunately produces circular
> dependencies due to the dispatcher and that prevents it from being
> compiled properly.

I think that adding autoload cookies on export functions and removing
requires in the dispatcher should solve most problems.

> One of test fails (but independently of compiling or not compiling the
> rest of the new exporter).  The failing test is
> test-org-element/src-block-interpreter, it appears that the test
> expects the block to be indented by two spaces, but it starts at the
> beginning of line for me.  Maybe some configuration is missing, but in
> any case that should be provided by the test.

It should be fixed now. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> declarations (instead of requires) are here to avoid circular
> dependencies. Why do you want to revert that in the first place?

...because so many of them were missing that it seemed easier to simply
pull in the definitions by requirement.

>> The way org-export is structured unfortunately produces circular
>> dependencies due to the dispatcher and that prevents it from being
>> compiled properly.
>
> I think that adding autoload cookies on export functions and removing
> requires in the dispatcher should solve most problems.

Yes, that was what I was thinking as well.  But that is not actually the
problem with the compilation, but rather your use of cl macros in some
places.  Somehow this messes up the compilation in a non-obvious way,
see my other post.  If you want to try it yourself, delete one of the
org-e-*.elc files after the first compilation and try to compile that
again and watch it explode...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
>> One of test fails (but independently of compiling or not compiling the
>> rest of the new exporter).  The failing test is
>> test-org-element/src-block-interpreter, it appears that the test
>> expects the block to be indented by two spaces, but it starts at the
>> beginning of line for me.  Maybe some configuration is missing, but in
>> any case that should be provided by the test.
>
> It should be fixed now. Thank you.

As long as I don't compile org-export.el, all tests are now passing.
Thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: new exporter

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> declarations (instead of requires) are here to avoid circular
>> dependencies. Why do you want to revert that in the first place?
>
> ...because so many of them were missing that it seemed easier to simply
> pull in the definitions by requirement.

But it isn't easier in the end, as you can see.

By the way, I have a (ugly and mostly working) function to add those
declarations.

#+begin_src emacs-lisp
(defun ngz-declare-function (package)
  "Insert necessary declare-function calls at point.
PACKAGE is the package from which functions should be declared."
  (interactive "sPackage name: ")
  (dolist (obj (save-excursion
                 (goto-char (point-min))
                 (let (acc (re (format "\\(^\\|[^`]\\)\\(%s-[-a-z]+\\)"
                                       package)))
                   (while (re-search-forward re nil t)
                     (let ((func (org-match-string-no-properties 2)))
                       (unless (member func acc) (push func acc))))
                   (sort acc 'string<))))
    (cond
     ((fboundp (intern obj))
      (let ((args
             (let* ((desc (save-window-excursion
                            (describe-function (intern obj))))
                    (args
                     (and (string-match (format "(%s \\([^)]+\\)?)" obj) desc)
                          (downcase
                           (replace-regexp-in-string
                            "[ \t]*\n[ \t]*" " "
                            (org-match-string-no-properties 1 desc))))))
               (insert
                (format "(declare-function %s \"%s\" (%s))\n"
                        obj package (or args ""))))))))
     ((boundp (intern obj)) (insert (format "(defvar %s)\n" obj))))))
#+end_src

> Yes, that was what I was thinking as well.  But that is not actually the
> problem with the compilation, but rather your use of cl macros in some
> places.  Somehow this messes up the compilation in a non-obvious way,
> see my other post.  If you want to try it yourself, delete one of the
> org-e-*.elc files after the first compilation and try to compile that
> again and watch it explode...

I do not notice anything like this.  There are many compilation errors
on some files, but they are the same before and after removing an
org-e-*.el file.


Regards,

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> I do not notice anything like this.  There are many compilation errors
> on some files, but they are the same before and after removing an
> org-e-*.el file.

I get them very consistently, in both Emacs 23.3 and 24.1, with and
without my patches.

org-mode> rm lisp/org-{export,element,e-*}.{el,elc}
org-mode> ln contrib/lisp/org-{export,element,e-*}.el lisp/
org-mode> make compile
org-mode> rm lisp/org-e-*.elc
org-mode> make compile-dirty

If I pre-load either org-element or org-export (or both) and they have
been byte-compiled things get worse to the point where Emacs simply
craps out.  I don't know why this is happening, but it's very obvious
that these files can't be used byte-compiled.  Whatever the reason, it
needs fixing.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> If I pre-load either org-element or org-export (or both) and they have
> been byte-compiled things get worse to the point where Emacs simply
> craps out.  I don't know why this is happening, but it's very obvious
> that these files can't be used byte-compiled.  Whatever the reason, it
> needs fixing.

What happens if you revert commit:

  4b0121fc2a18e00ce2c80e145563e41accfc4ddb


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> What happens if you revert commit:
>
>   4b0121fc2a18e00ce2c80e145563e41accfc4ddb

I've played with that before.  As I already said, the requires and maybe
even the circular dependencies are not the problem.  It apparently
croaks on the runtime use of cl macros and/or functions, but just
exactly how is a mystery to me.  I also do not know if the byte-compiler
output is already faulty or if running it (as in load or require) before
byte-compiling another file is triggering the error.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> It apparently croaks on the runtime use of cl macros and/or functions,
> but just exactly how is a mystery to me.

org-element uses `every' twice. Since this function doesn't belong to cl
but cl-extra, could it be the source of the problem?

If so, it may be worth a try to remove them from code base.

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> It apparently croaks on the runtime use of cl macros and/or functions,
>> but just exactly how is a mystery to me.
>
> org-element uses `every' twice. Since this function doesn't belong to cl
> but cl-extra, could it be the source of the problem?

Dunno.  I have just rid org-element and org-export of all cl macros
(incf, decf, loop, case, ...) and things start to compile correctly.
But that is too big a hammer obviously.  The use of cl macros at compile
time is officially sanctioned, so the reason for this must be that you
violate some assumption about their use or capture symbols used by the
byte compiler.

> If so, it may be worth a try to remove them from code base.

I'd start with the uses of macros inside let clauses.  These look really
fishy to me some of those symbols look like something the byte-compiler
might use itself: count, line, etc.  It is clear by now that something
throws the byte-compiler off really hard.


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

Re: new exporter

[Achim Gratz]

Achim Gratz writes:
> As long as I don't compile org-export.el, all tests are now passing.
> Thank you.

I've had a look at the byte-compiled code and traced at least one of
those errors to the following construct in org-export.el(org-export-as):

#BEGIN_SRC emacs_lisp
…
  (save-excursion
    (save-restriction
      ;; Narrow buffer to an appropriate region or subtree for
      ;; parsing.  If parsing subtree, be sure to remove main headline
      ;; too.
      (cond ((org-region-active-p)
	     (narrow-to-region (region-beginning) (region-end)))
	    (subtreep
	     (org-narrow-to-subtree)
	     (goto-char (point-min))
	     (forward-line)
	     (narrow-to-region (point) (point-max))))
      ;; 1. Get export environment from original buffer.  Store
      ;;    original footnotes definitions in communication channel as
      ;;    they might not be accessible anymore in a narrowed parse
      ;;    tree.  Also install user's and developer's filters.
      (let ((info (org-export-install-filters
		   (org-export-get-environment backend subtreep ext-plist)))
	    ;; 2. Get parse tree.  Buffer isn't parsed directly.
	    ;;    Instead, a temporary copy is created, where include
	    ;;    keywords are expanded and code blocks are evaluated.
	    (tree (let ((buf (or (buffer-file-name (buffer-base-buffer))
				 (current-buffer))))
…
#END_SRC

This causes the (current-buffer) to expand literally into the byte-code
(look at the byte-code!) instead of being compiled as a function, which
obviously isn't going to work.  This does not happen if I either remove
the cond form or if I wrap the BODY in save-restriction in progn, but I
haven't done any further investigation if the code still works with that
change and if maybe there are other places that are similarly struck.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: new exporter

[Achim Gratz]

Achim Gratz writes:
> This causes the (current-buffer) to expand literally into the byte-code
> (look at the byte-code!) instead of being compiled as a function, which
> obviously isn't going to work.  This does not happen if I either remove
> the cond form or if I wrap the BODY in save-restriction in progn, but I
> haven't done any further investigation if the code still works with that
> change and if maybe there are other places that are similarly struck.

No, that's not right... as long as I compile org-export.el in isolation,
it compiles correctly.  It croaks if I compile either one of
org-e-html.el or org-e-odt.el in the same session.  These are the two
backends that have a (require 'org-export) in them.  SOmething about
this must be altering the environment in a way that throws the
byte-compiler off-course.  Back to the drawing board.  :-(


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Achim Gratz writes:
>> This causes the (current-buffer) to expand literally into the byte-code
>> (look at the byte-code!) instead of being compiled as a function, which
>> obviously isn't going to work.  This does not happen if I either remove
>> the cond form or if I wrap the BODY in save-restriction in progn, but I
>> haven't done any further investigation if the code still works with that
>> change and if maybe there are other places that are similarly struck.
>
> No, that's not right... as long as I compile org-export.el in isolation,
> it compiles correctly.  It croaks if I compile either one of
> org-e-html.el or org-e-odt.el in the same session.  These are the two
> backends that have a (require 'org-export) in them.

Speaking about that, as you suggested already, we should move,
temporarily, the dispatcher into another file (i.e. org-e-extra.el)
which would require everything (org-element, org-export, org-e-publish,
org-e-latex,...) and have _every_ back-end require org-export and
org-element only.

That may not solve the problem, but could at least simplify it.

Is that fine?


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> Speaking about that, as you suggested already, we should move,
> temporarily, the dispatcher into another file (i.e. org-e-extra.el)
> which would require everything (org-element, org-export, org-e-publish,
> org-e-latex,...) and have _every_ back-end require org-export and
> org-element only.

Sure, but if I didn't goof up on my earlier investigations, it doesn't
solve the problem we are facing here.  Yet it would make the
dependencies more manageable, so if you could do that please go ahead.

I'll have to try and cut down the problem so that it becomes clear where
it fails.  Right now it is a Heisenbug, each time you change something
the error moves to some other place...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> That may not solve the problem, but could at least simplify it.

The problem can be demonstrated with just this code snippet in place of
org-export.el:

--8<---------------cut here---------------start------------->8---
(eval-when-compile (require 'cl))
(require 'org-macs)
(defun org-export-as
  (backend &optional subtreep visible-only body-only ext-plist noexpand)
    (org-export-with-current-buffer-copy
     ()))
(defmacro org-export-with-current-buffer-copy (&rest body)
  (org-with-gensyms (original-buffer offset buffer-string overlays)
    `(let ((,original-buffer ,(current-buffer)))
       (with-temp-buffer))))
(provide 'org-export)
--8<---------------cut here---------------end--------------->8---

So it might be a bit easier to solve now (I hope).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Achim Gratz]

Achim Gratz writes:
> Nicolas Goaziou writes:
>> That may not solve the problem, but could at least simplify it.
>
> The problem can be demonstrated with just this code snippet in place of
> org-export.el:
[...]
> So it might be a bit easier to solve now (I hope).

This code snippet has at last after revealed where the problem is: the
function call to (current-buffer) gets unquoted, when it clearly needs
to be in the expansion.  The literal expansion of the buffer content
into the compiled bytecode is similarly explained by an unquoting of
(buffer-string).  Here's a patch that seems to fix the compilation
(without changelog and everything because I think you may want to check
the rest of the new exporters for similar constructs).

--8<---------------cut here---------------start------------->8---
 contrib/lisp/org-export.el |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-export.el b/contrib/lisp/org-export.el
index 7e82050..8776086 100644
--- a/contrib/lisp/org-export.el
+++ b/contrib/lisp/org-export.el
@@ -2475,9 +2475,9 @@ (defmacro org-export-with-current-buffer-copy (&rest body)
 
 Point is at buffer's beginning when BODY is applied."
   (org-with-gensyms (original-buffer offset buffer-string overlays)
-    `(let ((,original-buffer ,(current-buffer))
+    `(let ((,original-buffer (current-buffer))
 	   (,offset ,(1- (point-min)))
-	   (,buffer-string ,(buffer-string))
+	   (,buffer-string (buffer-string))
 	   (,overlays (mapcar
 		       'copy-overlay (overlays-in (point-min) (point-max)))))
        (with-temp-buffer
-- 
1.7.10.4
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> This code snippet has at last after revealed where the problem is: the
> function call to (current-buffer) gets unquoted, when it clearly needs
> to be in the expansion.  The literal expansion of the buffer content
> into the compiled bytecode is similarly explained by an unquoting of
> (buffer-string).  Here's a patch that seems to fix the compilation
> (without changelog and everything because I think you may want to check
> the rest of the new exporters for similar constructs).

Nice catch.

I think you can go ahead and commit it: your description of the problem
will be more accurate than mine.

Thank you for this investigation and, obviously, for the fix.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> I think you can go ahead and commit it: your description of the problem
> will be more accurate than mine.
>
> Thank you for this investigation and, obviously, for the fix.

You give me too much credit here... the patch fixes things in that it
will now consistently compile, but it doesn't work correctly anymore,
compiled or otherwise.  I'm not sure what you intended the
macroexpansion to be at the place of use, hence my suggestion to check
these macros again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> The patch fixes things in that it will now consistently compile, but
> it doesn't work correctly anymore, compiled or otherwise.

Ok, I misunderstood your answer: I thought you had solved the problem.

> I'm not sure what you intended the macroexpansion to be at the place
> of use, hence my suggestion to check these macros again.

I will look more carefully at the `org-export-with-current-buffer-copy'
macro, but, since I cannot reproduce the compilation error it may be
hard to find the mistake.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> Ok, I misunderstood your answer: I thought you had solved the problem.

I thought that too at first, but it didn't survive closer scrutiny...

>> I'm not sure what you intended the macroexpansion to be at the place
>> of use, hence my suggestion to check these macros again.
>
> I will look more carefully at the `org-export-with-current-buffer-copy'
> macro, but, since I cannot reproduce the compilation error it may be
> hard to find the mistake.

I gave a very detailed example of how to arrive at the error.
Additionally, even if I change the order of compilation so that I don't
get the error during compilation itself, the result doesn't survive the
test suite since the compiled bytecode is actually wrong.  I've tested
this with several Emacs versions.  So when you say you can't reproduce
it you must be doing something quite different, would you care to
explain what that is?  Compiling from the edit buffer doesn't count
since it is non-reproduceable by default (although if you knew what
packages you've loaded it may give a hint on what is amiss).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> I will look more carefully at the `org-export-with-current-buffer-copy'
> macro, but, since I cannot reproduce the compilation error it may be
> hard to find the mistake.

After some consideration, I think this is what the macro should look
like:

--8<---------------cut here---------------start------------->8---
(defmacro org-export-with-current-buffer-copy (&rest body)
  "Apply BODY in a copy of the current buffer.

The copy preserves local variables and visibility of the original
buffer.

Point is at buffer's beginning when BODY is applied."
  `(org-with-gensyms (original-buffer offset buffer-string overlays)
     (let ((original-buffer (current-buffer))
	   (offset (1- (point-min)))
	   (buffer-string (buffer-string))
	   (overlays (mapcar
		       'copy-overlay (overlays-in (point-min) (point-max)))))
       (with-temp-buffer
	 (let ((buffer-invisibility-spec nil))
	   (org-clone-local-variables
	    original-buffer
	    "^\\(org-\\|orgtbl-\\|major-mode$\\|outline-\\(regexp\\|level\\)$\\)")
	   (insert buffer-string)
	   (mapc (lambda (ov)
		   (move-overlay
		    ov
		    (- (overlay-start ov) offset)
		    (- (overlay-end ov) offset)
		    (current-buffer)))
		 overlays)
	   (goto-char (point-min))
	   (progn ,@body))))))
(def-edebug-spec org-export-with-current-buffer-copy (body))
--8<---------------cut here---------------end--------------->8---

In other words I think you'll want to quote the whole expansion
including the let-forms into the place of the macro call.  The expansion
actually is into (org-with-gensyms... which then gets expanded further
into what you want to compile, but at that point the formal parameter of
the original macro call is already resolved.  This is what happens
during (non-compiled) interpretation anyway.  With that change the file
compiles and seems to work the same compiled and uncompiled.

The org-export-define-derived-backend macro seems similarly starstruck,
but I really don't know what you think the expansion should be.
Fortunately it's only used in org-e-beamer so far...

One of your recent changes introduced four test fail when org-element is
compiled.  I haven't yet looked why that would be, the four tests are:

   FAILED  test-org-export/table-cell-alignment
   FAILED  test-org-export/table-cell-borders
   FAILED  test-org-export/table-row-ends-header-p
   FAILED  test-org-export/table-row-starts-header-p

The new org-e-beamer.el doesn't compile at all:
org-e-beamer.el:258:1:Error: Wrong type argument: listp, org-e-beamer-export-block



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> After some consideration, I think this is what the macro should look
> like:
>
> (defmacro org-export-with-current-buffer-copy (&rest body)
>   "Apply BODY in a copy of the current buffer.
>
> The copy preserves local variables and visibility of the original
> buffer.
>
> Point is at buffer's beginning when BODY is applied."
>   `(org-with-gensyms (original-buffer offset buffer-string overlays)
>      (let ((original-buffer (current-buffer))
> 	   (offset (1- (point-min)))
> 	   (buffer-string (buffer-string))
> 	   (overlays (mapcar
> 		       'copy-overlay (overlays-in (point-min) (point-max)))))
>        (with-temp-buffer
> 	 (let ((buffer-invisibility-spec nil))
> 	   (org-clone-local-variables
> 	    original-buffer
> 	    "^\\(org-\\|orgtbl-\\|major-mode$\\|outline-\\(regexp\\|level\\)$\\)")
> 	   (insert buffer-string)
> 	   (mapc (lambda (ov)
> 		   (move-overlay
> 		    ov
> 		    (- (overlay-start ov) offset)
> 		    (- (overlay-end ov) offset)
> 		    (current-buffer)))
> 		 overlays)
> 	   (goto-char (point-min))
> 	   (progn ,@body))))))
> (def-edebug-spec org-export-with-current-buffer-copy (body))

Not exactly. With this version, symbols generated with gensym are never
used, and the macro isn't hygienic anymore.

I still think your first take about this macro was the good one. I've
pushed something very similar. Could you verify if it is correct on the
compiling side?

> The org-export-define-derived-backend macro seems similarly starstruck,
> but I really don't know what you think the expansion should be.

Something along the lines of:

#+begin_src emacs-lisp
(progn
  (defconst org-e-beamer-options-alist '(...)
    "Alist between filters keywords and back-end specific filters.
See `org-export-filters-alist' for more information.")
  (defvar org-e-beamer-translate-alist '(...)
    "Alist between element or object types and translators."))
#+end_src

> One of your recent changes introduced four test fail when org-element is
> compiled.  I haven't yet looked why that would be, the four tests are:
>
>    FAILED  test-org-export/table-cell-alignment
>    FAILED  test-org-export/table-cell-borders
>    FAILED  test-org-export/table-row-ends-header-p
>    FAILED  test-org-export/table-row-starts-header-p

Could you paste the error reported by ERT? I can't think of any recent
change in this area.

> The new org-e-beamer.el doesn't compile at all:
> org-e-beamer.el:258:1:Error: Wrong type argument: listp,
> org-e-beamer-export-block

It should be fixed.

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> Not exactly. With this version, symbols generated with gensym are never
> used, and the macro isn't hygienic anymore.

Yeah, I missed out on some commas along the way and it probably needs
double quoting (which I was trying to avoid).  The first version interns
the gensymed symbols at compile time, the later one should have done it
each time the code was called.

> I still think your first take about this macro was the good one. I've
> pushed something very similar. Could you verify if it is correct on the
> compiling side?

Yes, the compile error is easy to fix.  Both versions could do the
correct thing, the later one was just trying to be more conservative.
Looking superficially at the generated bytecode I think the current
version should be correct.

>> The org-export-define-derived-backend macro seems similarly starstruck,
>> but I really don't know what you think the expansion should be.
>
> Something along the lines of:
>
> #+begin_src emacs-lisp
> (progn
>   (defconst org-e-beamer-options-alist '(...)
>     "Alist between filters keywords and back-end specific filters.
> See `org-export-filters-alist' for more information.")
>   (defvar org-e-beamer-translate-alist '(...)
>     "Alist between element or object types and translators."))
> #+end_src
>
>> One of your recent changes introduced four test fail when org-element is
>> compiled.  I haven't yet looked why that would be, the four tests are:
>>
>>    FAILED  test-org-export/table-cell-alignment
>>    FAILED  test-org-export/table-cell-borders
>>    FAILED  test-org-export/table-row-ends-header-p
>>    FAILED  test-org-export/table-row-starts-header-p
>
> Could you paste the error reported by ERT? I can't think of any recent
> change in this area.

There's only a backtrace that doesn't make much sense to me:

--8<---------------cut here---------------start------------->8---
Test test-org-export/table-row-starts-header-p backtrace:
  signal(ert-test-failed (((should (equal (quote (yes no no no)) (org-
  ert-fail(((should (equal (quote (yes no no no)) (org-element-map tre
  (if (unwind-protect (setq value-3951 (apply fn-3949 args-3950)) (set
  (unless (unwind-protect (setq value-3951 (apply fn-3949 args-3950)) 
  (let (form-description-3953) (unless (unwind-protect (setq value-395
  (let ((value-3951 (quote ert-form-evaluation-aborted-3952))) (let (f
  (let ((fn-3949 (function equal)) (args-3950 (list (quote (yes no no 
  (should (equal (quote (yes no no no)) (org-element-map tree (quote t
  (let* ((tree (org-element-parse-buffer)) (info (org-export-collect-t
  (prog1 (let* ((tree (org-element-parse-buffer)) (info (org-export-co
  (progn (org-mode) (progn (insert "\n| a |\n| b |\n|---|\n| c |") (go
  (unwind-protect (progn (org-mode) (progn (insert "\n| a |\n| b |\n|-
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (with-current-buffer temp-buffer (unwind-protect (progn (org-mode) (
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (with-current-b
  (with-temp-buffer (org-mode) (progn (insert "\n| a |\n| b |\n|---|\n
  (org-test-with-temp-text "\n| a |\n| b |\n|---|\n| c |" (let* ((tree
  (org-test-with-parsed-data "\n| a |\n| b |\n|---|\n| c |" (should (e
  (lambda nil (org-test-with-parsed-data "\n| a |\n| b |\n|---|\n| c |
  byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  byte-code("\306\307!\211▒r\310\311!q\210\312 d\313\223)L\210\314\216
  ert-run-test([cl-struct-ert-test test-org-export/table-row-starts-he
  ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
  ert-run-tests("\\(org\\|ob\\)" #[(event-type &rest event-args) \30
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-id-locations-file (convert-stan
  org-test-run-batch-tests()
  call-interactively(org-test-run-batch-tests nil nil)
  command-execute(org-test-run-batch-tests)
  command-line-1(("--eval" "(add-to-list 'load-path \"./lisp\")" "--ev
  command-line()
  normal-top-level()
Test test-org-export/table-row-starts-header-p condition:
    (ert-test-failed
     ((should
       (equal '...
        (org-element-map tree ... ... info)))
      :form
      (equal
       (yes no no no)
       (yes yes no no))
      :value nil :explanation
      (list-elt 1
                (different-atoms no yes))))
--8<---------------cut here---------------end--------------->8---


>> The new org-e-beamer.el doesn't compile at all:
>> org-e-beamer.el:258:1:Error: Wrong type argument: listp,
>> org-e-beamer-export-block
>
> It should be fixed.

Thanks, that works correctly now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Achim Gratz]

Current testing results with the exporter files uncompiled:

2 unexpected results:
   FAILED  test-org-export/read-attribute
   FAILED  test-org-export/unravel-code

...and compiled:

6 unexpected results:
   FAILED  test-org-export/read-attribute
   FAILED  test-org-export/table-cell-alignment
   FAILED  test-org-export/table-cell-borders
   FAILED  test-org-export/table-row-ends-header-p
   FAILED  test-org-export/table-row-starts-header-p
   FAILED  test-org-export/unravel-code


You said you don't get those errors for the table exporter, which is
still puzzling me.

Tracebacks for the two new test errors:

--8<---------------cut here---------------start------------->8---
Test test-org-export/read-attribute backtrace:
  org-element-current-element()
  (prog1 (org-element-current-element) (kill-buffer))
  (progn (org-mode) (progn (insert "#+ATTR_HTML: :a 1 :b 2\nParagraph"
  (unwind-protect (progn (org-mode) (progn (insert "#+ATTR_HTML: :a 1 
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (with-current-buffer temp-buffer (unwind-protect (progn (org-mode) (
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (with-current-b
  (with-temp-buffer (org-mode) (progn (insert "#+ATTR_HTML: :a 1 :b 2\
  (org-test-with-temp-text "#+ATTR_HTML: :a 1 :b 2\nParagraph" (org-el
  (org-export-read-attribute :attr_html (org-test-with-temp-text "#+AT
  (list (org-export-read-attribute :attr_html (org-test-with-temp-text
  (let ((fn-4401 (function equal)) (args-4402 (list (org-export-read-a
  (should (equal (org-export-read-attribute :attr_html (org-test-with-
  (lambda nil (should (equal (org-export-read-attribute :attr_html (or
  byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  byte-code("\306\307!\211▒r\310\311!q\210\312 d\313\223)L\210\314\216
  ert-run-test([cl-struct-ert-test test-org-export/read-attribute "Tes
  ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
  ert-run-tests("\\(org\\|ob\\)" #[(event-type &rest event-args) \30
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-id-locations-file (convert-stan
  org-test-run-batch-tests()
  call-interactively(org-test-run-batch-tests nil nil)
  command-execute(org-test-run-batch-tests)
  command-line-1(("--eval" "(add-to-list 'load-path \"./lisp\")" "--ev
  command-line()
  normal-top-level()
Test test-org-export/read-attribute condition:
    (wrong-number-of-arguments
     #[(limit &optional granularity special structure)
313=\203:\314@A!\203`\30!\203\307y\210\202      \306\310!\203   b\210)\311\n\205(\n\312=?
\317=\203T\320@!\202\332\311B\321 \211CD\322CPE\323 ,\203r\324@
\325=\203\326@!\202\332\306F!\203\235\327\330!G\232\203\226\331@!\202\332\332@!\202\332\323 \203\252\333@
                                                                                                         \"\202\332\306\334!\203\317\212\335\336\337\340\327\330!!\"\307\311#)\203\310\341@!\202\332\342@!\202\332\306H!\203\327\330!I\212\335\343\307\311#)\204\354\342@!\202\376I\344\232\203\372\345@!\202\376\346@!)\202\332\306\347!\203\350@!\202\332\306\351!\203\213\352\225b\210\306\353!\203)\354 \210\355@!\202\332\306\356!\203Q\354 \210\357\327\330!\226J\"\211K\203IKA@!\202M\360@!)\202\332\306\361!\203a\354 \210\362@!\202\332\306\363!\203q\354 \210\364@!\202\332\306\365!\203\201\354 \210\366@!\202\332\354 \210\355@!\202\332\307f\367=\203\231\355@!\202\332\306L!\203\247\370@!\202\332\306\371!\203\264\372@!\202\332\373\311!\203\301\374@!\202\332\306\375 !\203\326\376@A\206\322\377 \"\202\332\34
 2@!+\207"
       [org-element--affiliated-re opoint granularity raw-secondary-p case-fold-search special looking-at nil "[        ]*$" t ...]
       7
       ("/home/gratz/lisp/org-mode/lisp/org-element.elc" . 82655)]
     0)
   FAILED  308/362  test-org-export/read-attribute
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
Test test-org-export/unravel-code backtrace:
  org-element-current-element()
  (org-export-unravel-code (org-element-current-element))
  (list (org-export-unravel-code (org-element-current-element)) (quote
  (let ((fn-4727 (function equal)) (args-4728 (list (org-export-unrave
  (should (equal (org-export-unravel-code (org-element-current-element
  (prog1 (should (equal (org-export-unravel-code (org-element-current-
  (progn (org-mode) (progn (insert "#+BEGIN_EXAMPLE\n(+ 1 1)\n#+END_EX
  (unwind-protect (progn (org-mode) (progn (insert "#+BEGIN_EXAMPLE\n(
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (with-current-buffer temp-buffer (unwind-protect (progn (org-mode) (
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (with-current-b
  (with-temp-buffer (org-mode) (progn (insert "#+BEGIN_EXAMPLE\n(+ 1 1
  (org-test-with-temp-text "#+BEGIN_EXAMPLE\n(+ 1 1)\n#+END_EXAMPLE" (
  (let ((org-coderef-label-format "(ref:%s)")) (org-test-with-temp-tex
  (lambda nil (let ((org-coderef-label-format "(ref:%s)")) (org-test-w
  byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  byte-code("\306\307!\211▒r\310\311!q\210\312 d\313\223)L\210\314\216
  ert-run-test([cl-struct-ert-test test-org-export/unravel-code "Test 
  ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
  ert-run-tests("\\(org\\|ob\\)" #[(event-type &rest event-args) \30
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-id-locations-file (convert-stan
  org-test-run-batch-tests()
  call-interactively(org-test-run-batch-tests nil nil)
  command-execute(org-test-run-batch-tests)
  command-line-1(("--eval" "(add-to-list 'load-path \"./lisp\")" "--ev
  command-line()
  normal-top-level()
Test test-org-export/unravel-code condition:
    (wrong-number-of-arguments
     #[(limit &optional granularity special structure)
313=\203:\314@A!\203`\30!\203\307y\210\202      \306\310!\203   b\210)\311\n\205(\n\312=?
\317=\203T\320@!\202\332\311B\321 \211CD\322CPE\323 ,\203r\324@
\325=\203\326@!\202\332\306F!\203\235\327\330!G\232\203\226\331@!\202\332\332@!\202\332\323 \203\252\333@
                                                                                                         \"\202\332\306\334!\203\317\212\335\336\337\340\327\330!!\"\307\311#)\203\310\341@!\202\332\342@!\202\332\306H!\203\327\330!I\212\335\343\307\311#)\204\354\342@!\202\376I\344\232\203\372\345@!\202\376\346@!)\202\332\306\347!\203\350@!\202\332\306\351!\203\213\352\225b\210\306\353!\203)\354 \210\355@!\202\332\306\356!\203Q\354 \210\357\327\330!\226J\"\211K\203IKA@!\202M\360@!)\202\332\306\361!\203a\354 \210\362@!\202\332\306\363!\203q\354 \210\364@!\202\332\306\365!\203\201\354 \210\366@!\202\332\354 \210\355@!\202\332\307f\367=\203\231\355@!\202\332\306L!\203\247\370@!\202\332\306\371!\203\264\372@!\202\332\373\311!\203\301\374@!\202\332\306\375 !\203\326\376@A\206\322\377 \"\202\332\34
 2@!+\207"
       [org-element--affiliated-re opoint granularity raw-secondary-p case-fold-search special looking-at nil "[        ]*$" t ...]
       7
       ("/home/gratz/lisp/org-mode/lisp/org-element.elc" . 82655)]
     0)
   FAILED  327/362  test-org-export/unravel-code
--8<---------------cut here---------------end--------------->8---


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

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Current testing results with the exporter files uncompiled:
>
> 2 unexpected results:
>    FAILED  test-org-export/read-attribute
>    FAILED  test-org-export/unravel-code
>
> ...and compiled:
>
> 6 unexpected results:
>    FAILED  test-org-export/read-attribute
>    FAILED  test-org-export/table-cell-alignment
>    FAILED  test-org-export/table-cell-borders
>    FAILED  test-org-export/table-row-ends-header-p
>    FAILED  test-org-export/table-row-starts-header-p
>    FAILED  test-org-export/unravel-code
>
>
> You said you don't get those errors for the table exporter, which is
> still puzzling me.

In fact, I do get the errors from a "make test" but I don't know how to
reproduce them from emacs.

Also, I cannot determine when they appeared for the first time: I tried
various points back in time, but they always seem to be present.

> Tracebacks for the two new test errors:

The two new errors should be gone. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> In fact, I do get the errors from a "make test" but I don't know how to
> reproduce them from emacs.

For starters you could try to run Emacs like "make test" does, but
remove "-batch".  This error somehow seems to involve that the test
always returns "'left 'left 'right" rather than what the tests expects.

> Also, I cannot determine when they appeared for the first time: I tried
> various points back in time, but they always seem to be present.

Yes, that has been my impression as well.  Again, I can make them go
away by removing one of the byte-compiled files, so I rather suspect
another case of a macro expansion that's not quite what was intented.
Only this time I really don't see from the backtrace what that would be.

>> Tracebacks for the two new test errors:
>
> The two new errors should be gone. Thank you.

Thanks.  I meanwhile had figured that the limit parameter was missing,
but not if it should always be (point-max).  However since you did make
that mistake yourself, maybe you could reconsider the function signature
and perhaps making limit optional and replacing it with (point-max) if
not present (reads as nil)?  It seems that it would unclutter the code
for the typical use...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Yes, that has been my impression as well.  Again, I can make them go
> away by removing one of the byte-compiled files, so I rather suspect
> another case of a macro expansion that's not quite what was intented.
> Only this time I really don't see from the backtrace what that would
> be.

It looks like table-cells have a wrong `:parent' property when
org-element.el is byte-compiled.  In `org-element-table-cell-parser',
replacing backquote with `list' solves the problem.

This is related to modifications by side-effect of list elements, but
I don't know why it only happens when the file is byte-compiled and why
it only focus table cells.

> Thanks.  I meanwhile had figured that the limit parameter was missing,
> but not if it should always be (point-max).  However since you did make
> that mistake yourself, maybe you could reconsider the function signature
> and perhaps making limit optional and replacing it with (point-max) if
> not present (reads as nil)?  It seems that it would unclutter the code
> for the typical use...

`org-element-current-element' is an internal function and (point-max) is
an unusual value, albeit sufficient for testing purpose.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> It looks like table-cells have a wrong `:parent' property when
> org-element.el is byte-compiled.  In `org-element-table-cell-parser',
> replacing backquote with `list' solves the problem.
>
> This is related to modifications by side-effect of list elements, but
> I don't know why it only happens when the file is byte-compiled and why
> it only focus table cells.

I'll try to grok this later... at least now I know where to look.

> `org-element-current-element' is an internal function and (point-max) is
> an unusual value, albeit sufficient for testing purpose.

OK.  Minor nit: if strictly an internal function (even if useful for
testing) you might consider naming it org-element--current-element to
make it more self-documenting.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: new exporter

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Yes, that has been my impression as well.  Again, I can make them go
>> away by removing one of the byte-compiled files, so I rather suspect
>> another case of a macro expansion that's not quite what was intented.
>> Only this time I really don't see from the backtrace what that would
>> be.
>
> It looks like table-cells have a wrong `:parent' property when
> org-element.el is byte-compiled.  In `org-element-table-cell-parser',
> replacing backquote with `list' solves the problem.


> This is related to modifications by side-effect of list elements, but
> I don't know why it only happens when the file is byte-compiled and why
> it only focus table cells.

There is an interesting  "pitfall" mentioned wrt `nconc' under:
   (info "(elisp) Rearrangement").

I try to make sense of the pitfall by conjuring up this argument.  This
seems right to me.
- `list' will dynamically allocate the list at runtime.  It comes from
  C's heap.

- A quote list is allocated at compile time (atleast the constant
  bits). It comes from memory that is allocated for global variables -
  externs or static externs.  Think value of list is the pointer to an
  extern C variable.

I am not sure what backquote does.

Wrt above problem, you may want to verify the following:
1. It works right the first time.  But subsequent invocations create
   side-effect.
2. Focus on what happens to the `head' of the list.

I am more or less facing similar problems wrt element translation.  I am
holding off any checkin mainly because I see some undesirable
side-effects.
-- 

Re: new exporter

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Hello,
>>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>
>>> Yes, that has been my impression as well.  Again, I can make them go
>>> away by removing one of the byte-compiled files, so I rather suspect
>>> another case of a macro expansion that's not quite what was intented.
>>> Only this time I really don't see from the backtrace what that would
>>> be.
>>
>> It looks like table-cells have a wrong `:parent' property when
>> org-element.el is byte-compiled.  In `org-element-table-cell-parser',
>> replacing backquote with `list' solves the problem.
>
>
>> This is related to modifications by side-effect of list elements, but
>> I don't know why it only happens when the file is byte-compiled and why
>> it only focus table cells.
>
> There is an interesting  "pitfall" mentioned wrt `nconc' under:
>    (info "(elisp) Rearrangement").
>
> I try to make sense of the pitfall by conjuring up this argument.  This
> seems right to me.
> - `list' will dynamically allocate the list at runtime.  It comes from
>   C's heap.
>
> - A quote list is allocated at compile time (atleast the constant
>   bits). It comes from memory that is allocated for global variables -
>   externs or static externs.  Think value of list is the pointer to an
>   extern C variable.
>
> I am not sure what backquote does.
>
> Wrt above problem, you may want to verify the following:
> 1. It works right the first time.  But subsequent invocations create
>    side-effect.
> 2. Focus on what happens to the `head' of the list.

Do table-cell gets "composed" in a special way wrt other elements.

> I am more or less facing similar problems wrt element translation.  I am
> holding off any checkin mainly because I see some undesirable
> side-effects.

I dont't have handle on it yet.  May be it is just a coincidence that
the translation involves lists and tables.

ps: If only there way to see the C pointers underlying the objects one
could actually sensibly see what is happening underneath.

The closest I have come to doing so is to use a combination of
`pp-display-expression' with (setq print-circle t).  This latter part
was added to my .emacs only in the last 2 days in an effort to bring out
the differnce between `eq' and `equal'.

For example a table like this

| 1 | 2 |
| a | b |

gets rendered as below.  Track the :parent properties, the Ns and #es
and you have no ambiguity on what objects they point to.

#1=(org-data nil #2=(section
		     (:begin 2 :end 22 :contents-begin 2 :contents-end 22 :post-blank 0 :parent #1#)
		     #3=(table
			 (:begin 2 :end 22 :type org :tblfm nil :contents-begin 2 :contents-end 22 :value nil :post-blank 0 :parent #2#)
			 #4=(table-row
			     (:type standard :begin 2 :end 12 :contents-begin 3 :contents-end 11 :post-blank 0 :parent #3#)
			     (table-cell
			      (:begin 3 :end 7 :contents-begin 4 :contents-end 5 :post-blank 0 :parent #4#)
			      "1")
			     (table-cell
			      (:begin 7 :end 11 :contents-begin 8 :contents-end 9 :post-blank 0 :parent #4#)
			      "2"))
			 #5=(table-row
			     (:type standard :begin 12 :end 22 :contents-begin 13 :contents-end 21 :post-blank 0 :parent #3#)
			     (table-cell
			      (:begin 13 :end 17 :contents-begin 14 :contents-end 15 :post-blank 0 :parent #5#)
			      "a")
			     (table-cell
			      (:begin 17 :end 21 :contents-begin 18 :contents-end 19 :post-blank 0 :parent #5#)
			      "b")))))

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> This is related to modifications by side-effect of list elements, but
> I don't know why it only happens when the file is byte-compiled and why
> it only focus table cells.

I just see that you fixed this.  Congratulations and thank you!


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> I just see that you fixed this.  Congratulations and thank you!

Unfortunately, there's now an

  "(invalid function org-export-with-current-buffer-copy)"

error when using make test


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Bastien]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Unfortunately, there's now an
>
>   "(invalid function org-export-with-current-buffer-copy)"
>
> error when using make test

Mhh.. just tried now and I don't have this error.

A leftover from the previously loaded definition maybe?

-- 
 Bastien

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> Unfortunately, there's now an
>
>   "(invalid function org-export-with-current-buffer-copy)"
>
> error when using make test

Not for me...  how do you have the build and the test configured?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: new exporter

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:

>> Unfortunately, there's now an
>>
>>   "(invalid function org-export-with-current-buffer-copy)"
>>
>> error when using make test
>
> Not for me...  how do you have the build and the test configured?

I hard-link org-element.el and org-export.el in lisp/ and I use the
following local change to default.mk (I know I should be modifying
local.mk instead, but this was easier to do).

Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch to default.mk --]
[-- Type: text/x-patch, Size: 796 bytes --]

From bfaf80e49c033f75b326063cf755fe5bb14f010c Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Mon, 16 Jul 2012 10:43:43 +0200
Subject: [PATCH] default.mk: Also test org-export

---
 default.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/default.mk b/default.mk
index c037919..f398f6b 100644
--- a/default.mk
+++ b/default.mk
@@ -54,8 +54,9 @@ BTEST	= $(BATCH) \
 	  $(BTEST_POST) \
 	  -l org-install.el \
 	  -l testing/org-test.el \
-	  $(foreach ob-lang,$(BTEST_OB_LANGUAGES),$(req-ob-lang)) \
 	  $(foreach req,$(BTEST_EXTRA),$(req-extra)) \
+          --eval '(require '"'"'org-export)' \
+          -l testing/lisp/test-org-export.el \
 	  --eval '(setq org-confirm-babel-evaluate nil)' \
 	  -f org-test-run-batch-tests
 
-- 
1.7.11.2

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
> I hard-link org-element.el and org-export.el in lisp/ and I use the

Ditto, to be exact:

rm -f lisp/org-{export,element,e-*}.{el,elc}
ln contrib/lisp/org-{export,element,e-*}.el lisp/

> following local change to default.mk (I know I should be modifying
> local.mk instead, but this was easier to do).

Actually, it wasn't.  These two lines would be the only additions you
need AFAICS and you could even make them on the command line:

--8<---------------cut here---------------start------------->8---
BTEST_EXTRA = org-export
BTEST_OB_LANGUAGES =
--8<---------------cut here---------------end--------------->8---

I still don't get that error and all tests are pass, with Emacs24 from
Bzr.  I do get an error from Emacs 23.3 (Lisp nesting exceeds
`max-lisp-eval-depth'), but that can be circumvented by increasing the
limit via

BTEST_PRE="--eval '(setq max-lisp-eval-depth 18000)'"

I then get two fails with really lengthy backtraces of what look to be
nested macro expansions

2 unexpected results:
   FAILED  test-org-element/parent-property
   FAILED  test-org-element/set-element


...but still not the error you've been reporting.  What's your version
of Emacs and how is it configured?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Actually, it wasn't.  These two lines would be the only additions you
> need AFAICS and you could even make them on the command line:
>
> BTEST_EXTRA = org-export BTEST_OB_LANGUAGES =

Good to know, thank you.

> I still don't get that error and all tests are pass, with Emacs24 from
> Bzr.  I do get an error from Emacs 23.3 (Lisp nesting exceeds
> `max-lisp-eval-depth'), but that can be circumvented by increasing the
> limit via
>
> BTEST_PRE="--eval '(setq max-lisp-eval-depth 18000)'"
>
> I then get two fails with really lengthy backtraces of what look to be
> nested macro expansions
>
> 2 unexpected results:
>    FAILED  test-org-element/parent-property
>    FAILED  test-org-element/set-element

I cannot get those. Have you tried with a recent Org (i.e. post
95cd07d058da79cb1767946dba6e4b9128a3a702)?

> ...but still not the error you've been reporting.

I also cannot anymore. I suppose I had fumbled with hard links
(i.e. forgetting to remove the previous one).


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
>> 2 unexpected results:
>>    FAILED  test-org-element/parent-property
>>    FAILED  test-org-element/set-element
>
> I cannot get those. Have you tried with a recent Org (i.e. post
> 95cd07d058da79cb1767946dba6e4b9128a3a702)?

I used whatever I had pulled yesterday... again, that failure happens
only with Emacs 23, which may well be a bug in that version or the
particular build.  It actually got worse in that I can't seem to find an
eval limit that works today, so the corruption that backtraced yesterday is
gone and I now have a truly infinite recursion apparently.

The current test suite gives the following failure on Emacs 24, probably
a fallout from the changes you did to the timestamp handling:

1 unexpected results:
   FAILED  test-org-element/timestamp-interpreter

Otherwise the same tests that are failing on Emacs 23 are clean on
Emacs 24.

>> ...but still not the error you've been reporting.
>
> I also cannot anymore. I suppose I had fumbled with hard links
> (i.e. forgetting to remove the previous one).

Git will unlink them each time something changes at the original place
and you are left with an inconsistent set of sources.  You really need
to remove and copy (or link) them each time you do a new checkout with
Git; but add this to local.mk and make will do it for you each time you
do a compile:

--8<---------------cut here---------------start------------->8---
compile::
	$(CP) contrib/lisp/org-{export,element,e-*}.el lisp/
cleanall:	cleanexporter
cleanexporter:
	$(RM) lisp/org-{export,element,e-*}.{el,elc}
--8<---------------cut here---------------end--------------->8---

If you want to switch back to a branch that doesn't use the new
exporter, remember to do a cleanall.  BTW, I've added a description of
how to use multiple local.mk setups (for different Emacsen or different
test setups) on Worg.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: new exporter

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> I used whatever I had pulled yesterday... again, that failure happens
> only with Emacs 23, which may well be a bug in that version or the
> particular build.  It actually got worse in that I can't seem to find an
> eval limit that works today, so the corruption that backtraced yesterday is
> gone and I now have a truly infinite recursion apparently.

Would you happen to have any backtrace for them?

> The current test suite gives the following failure on Emacs 24, probably
> a fallout from the changes you did to the timestamp handling:
>
> 1 unexpected results:
>    FAILED  test-org-element/timestamp-interpreter

This should be fixed in a recent commit. I was quicker than the patrol
this time.

> Git will unlink them each time something changes at the original place
> and you are left with an inconsistent set of sources.  You really need
> to remove and copy (or link) them each time you do a new checkout with
> Git; but add this to local.mk and make will do it for you each time you
> do a compile:
>
> compile::
> 	$(CP) contrib/lisp/org-{export,element,e-*}.el lisp/
> cleanall:	cleanexporter
> cleanexporter:
> 	$(RM) lisp/org-{export,element,e-*}.{el,elc}
>

Noted. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: new exporter

[Nicolas Goaziou]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> I used whatever I had pulled yesterday... again, that failure happens
>> only with Emacs 23, which may well be a bug in that version or the
>> particular build.  It actually got worse in that I can't seem to find an
>> eval limit that works today, so the corruption that backtraced yesterday is
>> gone and I now have a truly infinite recursion apparently.
>
> Would you happen to have any backtrace for them?

Nevermind: I fixed them. I think all tests should pass now, in both
emacs 24 and emacs 23.

If you confirm this, I will move org-element.el into core.

Regards,

Re: new exporter

[Achim Gratz]

Nicolas Goaziou writes:
>> compile::
>> 	$(CP) contrib/lisp/org-{export,element,e-*}.el lisp/
>
> Noted. Thank you.

That should be "all compile::", really.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: new exporter

[Achim Gratz]

[re-sent due to no-show on the list... sorry if you get it twice]

Nicolas Goaziou writes:
> Nevermind: I fixed them. I think all tests should pass now, in both
> emacs 24 and emacs 23.

Yes!

> If you confirm this, I will move org-element.el into core.

Go ahead... and let us all celebrate that moment.

REgards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

new exporter

[itmejl]

Hello!

This is about using the new exporter.

I use Emacs 24.2 on win7 and org-mode 7.9.2.

The following two lines (with real paths of course) are in .emacs:
(require 'org-export)
(add-to-list 'load-path (expand-file-name "/path/to/org/contrib/lisp"))

When starting with M-x org-export-dispatch I come to the new dispatcher
but then nothing goes.

Regardless of what I choose the message is:
Symbol's function definition is void: org-e-ascii-export-as-ascii or
org-e-html..... or whatever export format chose.

When I hit M-x org-e tab nothing is listed. Emacs does not seam to find
the exporter commands.

What am I missing?

/

Re: new exporter

[Nicolas Goaziou]

Hello,

itmejl <itmejl@chrikro.net> writes:

> This is about using the new exporter.
>
> I use Emacs 24.2 on win7 and org-mode 7.9.2.

If you plan to use the new exporter, I strongly advise to load Org from
git development branch instead of the latest release.

> The following two lines (with real paths of course) are in .emacs:
> (require 'org-export)

You don't need to (require 'org-export) but you have to require the
export back-ends you will need. I.e.: (require 'org-e-latex) or (require
'org-e-ascii).


Regards,

-- 
Nicolas Goaziou

New exporter

[Sebastien Vauban]

Hello Nicolas,

I want to (really) start using the new exporter as of now. I think it's high
time for me to benefit from it...

Here some first comments and questions.

I've been hit by trying to export with `C-c E p' [1] to PDF, but had troubles
doing so. In fact, I had to do `C-c l p' -- though the new dispatcher is much
more clear and _easy_ to use, I thought there was a problem.

Why? Because there was no beep to say that `p' entered at that moment was a
wrong choice, nor other form of message. I think that'd help, if there was
such a sound produced, for example. Right now, the bad keys are simply ignored
without further notice.

Second thing that puzzled me: the focus (active modeline) is on the window
with the Org source, not on the window with the dispatcher. It was the same
with the old exporter, but I wonder whether it must be like that, or whether
that could be changed, to emphasize that the key events are well going to the
dispatcher window?

At first, I thought that my first problem (`p' not doing anything was due to
that -- dispatcher window not active). I wanted to switch over to it (via
`F6' [2]) and ended with garbage in the echo area... C-c E p f6 p p f6...

Does this make sense?

Best regards,
  Seb

[1] I have `C-c E' mapped to `org-export-dispatch'.

[2] I have `f6' mapped to `other-window'.

-- 
Sebastien Vauban

Re: New exporter

[Yagnesh Raghava Yakkala]

Hello Sebastien,

Unless you found a bug in org-export-dispatch, I think its `C-c E l p' (since
you have C-c E for org-export-dispatch). Watch the highlighted characters as
you press `l'. The difference is you need to press two keys instead of one as
in old one in the dispatcher window.

Actually I found that the new dispatch command is designed more sophisticated
way even though there is an extra key press.

 Of course there is also obvious another way `M-x org-e-latex-export-to-pdf'.



"Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:

> Hello Nicolas,
>
> I want to (really) start using the new exporter as of now. I think it's high
> time for me to benefit from it...
>
> Here some first comments and questions.
>
> I've been hit by trying to export with `C-c E p' [1] to PDF, but had troubles
> doing so. In fact, I had to do `C-c l p' -- though the new dispatcher is much
> more clear and _easy_ to use, I thought there was a problem.
>
> Why? Because there was no beep to say that `p' entered at that moment was a
> wrong choice, nor other form of message. I think that'd help, if there was
> such a sound produced, for example. Right now, the bad keys are simply ignored
> without further notice.
>
> Second thing that puzzled me: the focus (active modeline) is on the window
> with the Org source, not on the window with the dispatcher. It was the same
> with the old exporter, but I wonder whether it must be like that, or whether
> that could be changed, to emphasize that the key events are well going to the
> dispatcher window?
>
> At first, I thought that my first problem (`p' not doing anything was due to
> that -- dispatcher window not active). I wanted to switch over to it (via
> `F6' [2]) and ended with garbage in the echo area... C-c E p f6 p p f6...
>
> Does this make sense?
>
> Best regards,
>   Seb
>
> [1] I have `C-c E' mapped to `org-export-dispatch'.
>
> [2] I have `f6' mapped to `other-window'.


Thanks.,
-- 
ఎందరో మహానుభావులు అందరికి వందనములు
YYR

Re: New exporter

[Nicolas Goaziou]

Hello,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

> I've been hit by trying to export with `C-c E p' [1] to PDF, but had troubles
> doing so. In fact, I had to do `C-c l p' -- though the new dispatcher is much
> more clear and _easy_ to use, I thought there was a problem.
>
> Why? Because there was no beep to say that `p' entered at that moment was a
> wrong choice, nor other form of message. I think that'd help, if there was
> such a sound produced, for example. Right now, the bad keys are simply ignored
> without further notice.
>
> Second thing that puzzled me: the focus (active modeline) is on the window
> with the Org source, not on the window with the dispatcher. It was the same
> with the old exporter, but I wonder whether it must be like that, or whether
> that could be changed, to emphasize that the key events are well going to the
> dispatcher window?
>
> At first, I thought that my first problem (`p' not doing anything was due to
> that -- dispatcher window not active). I wanted to switch over to it (via
> `F6' [2]) and ended with garbage in the echo area... C-c E p f6 p p f6...
>
> Does this make sense?

It does. I've implemented suggested changes in master. Thanks for
suggesting them.


Regards,

-- 
Nicolas Goaziou

Re: New exporter

[Sebastien Vauban]

Hello Yagnesh,

Yagnesh Raghava Yakkala wrote:
> "Sebastien Vauban" writes:
>> I've been hit by trying to export with `C-c E p' [1] to PDF, but had troubles
>> doing so. In fact, I had to do `C-c l p' -- though the new dispatcher is much
>> more clear and _easy_ to use, I thought there was a problem.
>
> Unless you found a bug in org-export-dispatch, I think its `C-c E l p' (since
> you have C-c E for org-export-dispatch).

Of course, typo (!), I meant: I had to type `C-c E l p'...

Thanks for correcting.

> Watch the highlighted characters as you press `l'. The difference is you
> need to press two keys instead of one as in old one in the dispatcher
> window.
>
> Actually I found that the new dispatch command is designed more sophisticated
> way even though there is an extra key press.
>
>  Of course there is also obvious another way `M-x org-e-latex-export-to-pdf'.

Yes, always possible, but I wanted to report my (stupid) problem using the new
dispatcher *and* the old habits!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: New exporter

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>
>> I've been hit by trying to export with `C-c E p' [1] to PDF, but had troubles
>> doing so. In fact, I had to do `C-c l p' -- though the new dispatcher is much
>> more clear and _easy_ to use, I thought there was a problem.
>>
>> Why? Because there was no beep to say that `p' entered at that moment was a
>> wrong choice, nor other form of message. I think that'd help, if there was
>> such a sound produced, for example. Right now, the bad keys are simply ignored
>> without further notice.
>>
>> Second thing that puzzled me: the focus (active modeline) is on the window
>> with the Org source, not on the window with the dispatcher. It was the same
>> with the old exporter, but I wonder whether it must be like that, or whether
>> that could be changed, to emphasize that the key events are well going to the
>> dispatcher window?
>>
>> At first, I thought that my first problem (`p' not doing anything was due to
>> that -- dispatcher window not active). I wanted to switch over to it (via
>> `F6' [2]) and ended with garbage in the echo area... C-c E p f6 p p f6...
>>
>> Does this make sense?
>
> It does. I've implemented suggested changes in master. Thanks for
> suggesting them.

Many thanks. I'll have a look...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: New exporter

[Sebastien Vauban]

Hello Nicolas,

"Sebastien Vauban" wrote:
> Nicolas Goaziou wrote:
>> "Sebastien Vauban" writes:
>>
>>> I've been hit by trying to export with `C-c E p' [1] to PDF, but had
>>> troubles doing so. In fact, I had to do `C-c l p' -- though the new
>>> dispatcher is much more clear and _easy_ to use, I thought there was a
>>> problem.
>>>
>>> Why? Because there was no beep to say that `p' entered at that moment was
>>> a wrong choice, nor other form of message. I think that'd help, if there
>>> was such a sound produced, for example. Right now, the bad keys are simply
>>> ignored without further notice.
>>>
>>> Second thing that puzzled me: the focus (active modeline) is on the window
>>> with the Org source, not on the window with the dispatcher. It was the
>>> same with the old exporter, but I wonder whether it must be like that, or
>>> whether that could be changed, to emphasize that the key events are well
>>> going to the dispatcher window?
>>>
>>> At first, I thought that my first problem (`p' not doing anything was due
>>> to that -- dispatcher window not active). I wanted to switch over to it
>>> (via `F6' [2]) and ended with garbage in the echo area... C-c E p f6 p p
>>> f6...
>>>
>>> Does this make sense?
>>
>> It does. I've implemented suggested changes in master. Thanks for
>> suggesting them.

Did you mean both changes?  That is:

- beep (or message) when erroneous key is typed, and
- dispatcher becomes the active window?

> Many thanks. I'll have a look...

I didn't notice any of these when using Org-mode version 7.9.2
(release_7.9.2-428-ge2e545 @ d:/home/sva/src/org-mode/lisp/)?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: New exporter

[Sebastien Vauban]

Hello Nicolas,

"Sebastien Vauban" wrote:
> "Sebastien Vauban" wrote:
>> Nicolas Goaziou wrote:
>>> "Sebastien Vauban" writes:
>>>> Does this make sense?
>>>
>>> It does. I've implemented suggested changes in master. Thanks for
>>> suggesting them.
>
> Did you mean both changes?  That is:
>
> - beep (or message) when erroneous key is typed, and
> - dispatcher becomes the active window?
>
>> Many thanks. I'll have a look...
>
> I didn't notice any of these when using Org-mode version 7.9.2
> (release_7.9.2-428-ge2e545 @ d:/home/sva/src/org-mode/lisp/)?

Forget it. It *does* work. Somehow, I wasn't up to date.

Now: Org-mode version 7.9.2 (release_7.9.2-436-g9b11e6 @
d:/home/sva/src/org-mode/lisp/).

Excellent!  Thanks a lot...

Best regards,
  Seb

-- 
Sebastien Vauban