[O] Bug in new exporter?
Hi list,
when I try to use the new exporter outside of an Org buffer, e.g. from a
function or with M-:, it seems that there is a problem with the current
buffer that is used for exporting - it is not the buffer of the Org file
given as argument.
I think the problem is here (line 2319 of org-export.el, function
org-export-as):
#+begin_src emacs-lisp
(tree (let ((buf (or (buffer-file-name (buffer-base-buffer))
(current-buffer
#+end_src
What I actually do to produce the backtrace above is a bit complicated,
I eval a function of mine with M-:, which in turn calls:
#+begin_src emacs-lisp
(org-export-to-file
'e-html "/home/mydir/myfile.org")
#+end_src
When I do this with point in a different buffer, I get an error (see
backtrace below). When I do it with point in myfile.org, the export
actually works, but replaces the Org text in myfile.org with the exported
html. When I do M-x org-e-html-export-to-html with point in myfile.org,
everything works fine and myfile.html is produced.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
looking-at(nil)
(and (looking-at org-planning-or-clock-line-re))
(cond ((eq special (quote item)) (org-element-item-parser (or structure
(org-list-struct)) raw-secondary-p)) ((eq special (quote quote-section))
(org-element-quote-section-parser)) ((eq special (quote table-row))
(org-element-table-row-parser)) ((org-with-limited-levels (org-at-heading-p))
(org-element-headline-parser raw-secondary-p)) ((eq special (quote section))
(org-element-section-parser)) ((and (looking-at org-planning-or-clock-line-re))
(if (equal (match-string 1) org-clock-string) (org-element-clock-parser)
(org-element-planning-parser))) ((when (looking-at "[
]*#\\+BEGIN_\\([-A-Za-z0-9]+\\)\\(?: \\|$\\)") (let ((name (upcase
(match-string 1))) parser) (cond ((not (save-excursion ...))
(org-element-paragraph-parser)) ((setq parser (assoc name
org-element-block-name-alist)) (funcall (cdr parser))) (t
(org-element-special-block-parser)) ((org-at-heading-p)
(org-element-inlinetask-parser raw-secondary-p)) ((looking-at "[
]*begin{\\([A-Za-z0-9*]+\\)}") (if (save-excursion (re-search-forward
(format "[]*end{%s}[ ]*" (regexp-quote (match-string 1))) nil t))
(org-element-latex-environment-parser) (org-element-paragraph-parser)))
((looking-at org-drawer-regexp) (let ((name (match-string 1))) (cond ((not
(save-excursion (re-search-forward "^[ ]*:END:[]*$" nil t)))
(org-element-paragraph-parser)) ((equal "PROPERTIES" name)
(org-element-property-drawer-parser)) (t (org-element-drawer-parser)
((looking-at "[ ]*:\\( \\|$\\)") (org-element-fixed-width-parser))
((looking-at "[ ]*#\\+\\([a-z]+\\(:?_[a-z]+\\)*\\):") (let ((key (upcase
(match-string 1 (cond ((equal key "CALL") (org-element-babel-call-parser))
((and (equal key "BEGIN") (save-excursion (re-search-forward "^[
]*#\\+END:\\(?: \\|$\\)" nil t))) (org-element-dynamic-block-parser)) ((and
(not (equal key "TBLFM")) (not (member key org-element-affiliated-keywords)))
(org-element-keyword-parser)) (t (org-element-paragraph-parser)
((looking-at org-footnote-definition-re)
(org-element-footnote-definition-parser)) ((looking-at "\\(#\\|[
]*#\\+\\(?: \\|$\\)\\)") (org-element-comment-parser)) ((looking-at "[
]*-\\{5,\\}[]*$") (org-element-horizontal-rule-parser)) ((org-at-table-p t)
(org-element-table-parser)) ((looking-at (org-item-re))
(org-element-plain-list-parser (or structure (org-list-struct (t
(org-element-paragraph-parser)))
(let ((case-fold-search t) (raw-secondary-p (and granularity (not (eq
granularity (quote object)) (cond ((eq special (quote item))
(org-element-item-parser (or structure (org-list-struct)) raw-secondary-p))
((eq special (quote quote-section)) (org-element-quote-section-parser)) ((eq
special (quote table-row)) (org-element-table-row-parser))
((org-with-limited-levels (org-at-heading-p)) (org-element-headline-parser
raw-secondary-p)) ((eq special (quote section)) (org-element-section-parser))
((and (looking-at org-planning-or-clock-line-re)) (if (equal (match-string 1)
org-clock-string) (org-element-clock-parser) (org-element-planning-parser)))
((when (looking-at "[ ]*#\\+BEGIN_\\([-A-Za-z0-9]+\\)\\(?: \\|$\\)") (let
((name (upcase ...)) parser) (cond ((not ...) (org-element-paragraph-parser))
((setq parser ...) (funcall ...)) (t (org-element-special-block-parser))
((org-at-heading-p) (org-element-inlinetask-parser raw-secondary-p))
((looking-at "[ ]*begin{\\([A-Za-z0-9*]+\\)}") (if (save-excursion
(re-search-forward (format "[]*end{%s}[ ]*" (regexp-quote ...)) nil
t)) (org-element-latex-environment-parser) (org-element-paragraph-parser)))
((looking-at org-drawer-regexp) (let ((name (match-string 1))) (cond ((not
(save-excursion ...)) (org-element-paragraph-parser)) ((equal "PROPERTIES"
name) (org-element-property-drawer-parser)) (t (org-element-dr
Re: [O] Bug in new exporter?
Thorsten Jolitz writes: > when I try to use the new exporter outside of an Org buffer, e.g. from a > function or with M-:, it seems that there is a problem with the current > buffer that is used for exporting - it is not the buffer of the Org file > given as argument. You should read the docstring again: the file name you give to that function is the name of the file that will be exported _into_ from the current buffer. So the current buffer should contain the org document to be exported. 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: [O] Bug in new exporter?
Achim Gratz writes: > Thorsten Jolitz writes: >> when I try to use the new exporter outside of an Org buffer, e.g. from a >> function or with M-:, it seems that there is a problem with the current >> buffer that is used for exporting - it is not the buffer of the Org file >> given as argument. > > You should read the docstring again: the file name you give to that > function is the name of the file that will be exported _into_ from the > current buffer. So the current buffer should contain the org document > to be exported. Right, that got me confused. Sorry for the noise, and thanks for the tip. -- cheers, Thorsten
Re: [O] new exporter
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
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
Hi Toby, On 25.06.2012 13:35, Toby Cubitt wrote: > On Sun, Jun 24, 2012 at 11:52:41PM +0200, Toby Cubitt wrote: >> On Sun, Jun 24, 2012 at 11:39:08PM +0200, Bastien wrote: >>> Hi Toby, >>> >>> Toby Cubitt writes: >>> For some unknown reason, org-mode is causing the undo boundary between the (2 . 4) and (1 . 2) entries to be removed from `buffer-undo-list'. >>> >>> Can you try again with >>> >>> (setq org-self-insert-cluster-for-undo nil) >>> >>> and report? >> >> Yup, that fixes the problem. >> >> I don't fully understand the purpose of >> `org-self-insert-cluster-for-undo', given that the Emacs command loop >> already groups consecutive undo entries together, but presumably it >> enables a more aggressive form of clustering. >> > [snip] >> >> I could try to work around this in undo-tree-mode, but it seems to me >> that org-mode shouldn't be throwing away an undo boundary that comes >> before an entry which definitely shouldn't be clustered with anything >> (namely the undo-tree-canary symbol, which is meaningless to org-mode). > > I've now added a work-around for this in undo-tree-mode (currently only > in git, but I'll push to ELPA once it's sufficiently tested). > > I'm still not entirely convinced that the boundary discarding logic in > org-self-insert-command is correct. For example, if I do the following: > > 1. Type some text at some location in an org-mode buffer > 2. Move to another location very far away >(without invoking any commands other than point motion) > 3. Type some more text > > then org-self-insert-cluster-for-undo collapses the undo changesets for > these two changes into one. Undoing then reverts both sets of changes at > once, even though those changes might be so far apart that they aren't > both visible at the same time in the buffer. > > That seems very undesirable to me. Having been involved in org-mode's collapsing code I am interested in this, but I cannot reproduce your problem. I used a very large org-mode file, inserted some text, moved down some pages and inserted some text again (3 chars each). Undoing was split between both parts, exactly as desired. Could you provide more details please? Thanks, Martin
