[BUG?] Strange message in minibuffer while exporting into HTML

[BUG?] Strange message in minibuffer while exporting into HTML

[Vladimir Lomov]

Hello,
please consider this sample Org document (ex-call.org):

-------------------------------------------- 8< --------------------------------------------

#+TITLE: Example with CALL directive
#+AUTHOR: Vladimir Lomov
#+OPTIONS: num:nil

* This is first section

Recently I faced with a strange message in minibuffer:
#+BEGIN_EXAMPLE
Marker points into wrong buffer: #<marker in no buffer>
#+END_EXAMPLE
when exporting the Org document into HTML.

At first I was puzzled what causes this message in that particular Org
document, while rest my Org documents are exported to HTML just fine.

After a while I tried to strip down that document to figure out what
may cause that message. And seems that problem is in CALL strings.

In that particural document I have several CALL directive, commenting
out them (just added a ~#~ at beginning of a line with a space after
it) allows me to export that document into HTML.

The purpose of this example document to ensure that even simple CALL
line could cause such behaviour.

This is CALL directive, it calls function defined below
#+CALL: simple-func()

Even without evaluation of this directive exporting into HTML fails
with above message.

Commenting that directive make it possible to export into HTML.

Another attempt:
#+CALL: simple-func(name="Vladimir Lomov")

* The simple Emacs Lisp function

This simple Emacs Lisp function has to be called by CALL directive:
#+NAME: simple-func
#+BEGIN_SRC emacs-lisp :var name="My name"
  (format "[You told me:] %S" name)
#+END_SRC

-------------------------------------------- 8< --------------------------------------------

My system:
- Archlinux x86_64, gcc 4.8.1, make 4.0
- emacs: GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.0) of 2013-10-10 on smoon4
  (compile from bzr trunk, revno 114606)
- org-mode: Org-mode version 8.2.1 (release_8.2.1-77-g8aaf3c @ /usr/share/emacs/site-lisp/org/)

I have typed above document in Emacs run as
emacs -Q -l min-org.el --eval "(require 'ox-html)" ex-call.org


Is this really a bug or my misunderstanding of 'CALL' directive usage?

---
WBR, Vladimir Lomov

-- 
Being overloaded is the sign of a true Debian maintainer.
	-- JHM on #Debian

Re: [BUG?] Strange message in minibuffer while exporting into HTML

[Vladimir Lomov]

Hi,
** Vladimir Lomov [2013-10-11 13:11:11 +0900]:

> Hello,
> please consider this sample Org document (ex-call.org):

[...]

> I have typed above document in Emacs run as
> emacs -Q -l min-org.el --eval "(require 'ox-html)" ex-call.org

I forgot to include minimal configuration 'min-org.el':

------------------------------- 8< -------------------------------
(add-to-list 'load-path "/usr/share/emacs/site-lisp/org")
------------------------------- 8< -------------------------------

---
WBR, Vladimir Lomov

-- 
Cat, n.:
	Lapwarmer with built-in buzzer.

Re: [BUG?] Strange message in minibuffer while exporting into HTML

[Sebastien Vauban]

Hello Vladimir,

Vladimir Lomov wrote:
> please consider this sample Org document (ex-call.org):
>
> #+TITLE: Example with CALL directive
> #+AUTHOR: Vladimir Lomov
> #+OPTIONS: num:nil
>
> * This is first section
>
> Recently I faced with a strange message in minibuffer:
> #+BEGIN_EXAMPLE
> Marker points into wrong buffer: #<marker in no buffer>
> #+END_EXAMPLE
> when exporting the Org document into HTML.
>
> At first I was puzzled what causes this message in that particular Org
> document, while rest my Org documents are exported to HTML just fine.
>
> After a while I tried to strip down that document to figure out what
> may cause that message. And seems that problem is in CALL strings.
>
> In that particural document I have several CALL directive, commenting
> out them (just added a ~#~ at beginning of a line with a space after
> it) allows me to export that document into HTML.
>
> The purpose of this example document to ensure that even simple CALL
> line could cause such behaviour.
>
> This is CALL directive, it calls function defined below
> #+CALL: simple-func()
>
> Even without evaluation of this directive exporting into HTML fails
> with above message.
>
> Commenting that directive make it possible to export into HTML.
>
> Another attempt:
> #+CALL: simple-func(name="Vladimir Lomov")
>
> * The simple Emacs Lisp function
>
> This simple Emacs Lisp function has to be called by CALL directive:
> #+NAME: simple-func
> #+BEGIN_SRC emacs-lisp :var name="My name"
>   (format "[You told me:] %S" name)
> #+END_SRC
>
> My system:
> - Archlinux x86_64, gcc 4.8.1, make 4.0
> - emacs: GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.0) of 2013-10-10 on smoon4
>   (compile from bzr trunk, revno 114606)
> - org-mode: Org-mode version 8.2.1 (release_8.2.1-77-g8aaf3c @ /usr/share/emacs/site-lisp/org/)
>
> I have typed above document in Emacs run as
> emacs -Q -l min-org.el --eval "(require 'ox-html)" ex-call.org
>
> Is this really a bug or my misunderstanding of 'CALL' directive usage?

I confirm the problem on my Windows environment:

- GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-09-30 on LEG570
- Org-mode version 8.1.1 (release_8.1.1-13-ga1f9a1)

... and I don't see any problem with your syntax. I'm as puzzled as you are.

Would you wanna help, I think trying to bisect Org mode would be a great step
into fixing what I think to be a problem in Org.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [BUG?] Strange message in minibuffer while exporting into HTML

[Vladimir Lomov]

Hello,
** Sebastien Vauban [2013-10-11 09:32:12 +0200]:

> Hello Vladimir,

[...]

> I confirm the problem on my Windows environment:

> - GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-09-30 on LEG570
> - Org-mode version 8.1.1 (release_8.1.1-13-ga1f9a1)

> ... and I don't see any problem with your syntax. I'm as puzzled as you are.

> Would you wanna help, I think trying to bisect Org mode would be a great step
> into fixing what I think to be a problem in Org.

Hm, this is my the best approach to "debug":
1. in all cases I run emacs like
   #+BEGIN_EXAMPLE
     emacs -Q --eval "(add-to-list 'load-path \"~/tmp/org-mode\")" --eval "(require 'org)" --eval "(require 'ox-html)" ex-call2.org
   #+END_EXAMPLE
2. this is the file 'ex-call2.org':
   #+BEGIN_SRC org
     ,* This is title of first section
     
     Call me:
     ,#+CALL: simp-func()

     ,* Function definition

     ,#+NAME: simp-func()
     ,#+BEGIN_SRC emacs-lisp :var name="My name is..."
       (format "[You passed data] %S" name)
     ,#+END_SRC
   #+END_SRC
3. before run 'C-c C-e h h' (export into HTML) I run ~M-x org-version~
   to ensure what version I run;
4. I started from releases: 8.2.1, 8.2... 8.0 and found that in all
   release begins with 8.1 I see mentioned message, but in releases
   8.0.6 and 8.0.7 there is another message:
   #+BEGIN_QUOTE
     Reference 'simp-func' not found in this buffer
   #+END_QUOTE
   so I decided to find out which commit changed this message.
5. I did: =git bisect release_8.1 release_8.0.7= and after some steps I
   got:
   #+BEGIN_EXAMPLE
     685b2967247597f75d22cb77896bc8a70503b2c3 is the first bad commit
     commit 685b2967247597f75d22cb77896bc8a70503b2c3
     Author: Eric Schulte <schulte.eric@gmail.com>
     Date:   Tue Jun 25 07:55:32 2013 -0600

         evaluate elisp header args at original call site
    
         * lisp/ob-core.el (org-babel-execute-src-block): Ensure that the
           location is set before anything else is done.
         * lisp/ob-ref.el (org-babel-ref-parse): Evaluate Emacs Lisp values in
           header arguments at the location of the original code block.
         * testing/lisp/test-ob.el (test-ob/location-of-header-arg-eval): Test
           defending the new header argument evaluation behavior.

     :040000 040000 9e11b15cf73c6a0a9856f2a3393f27419e251f14 b106e079f13673e440c391bcb6a1e6dddb4994ed M	lisp
     :040000 040000 3935206e2970ec1f338a8b5524906a6d32e58d0e 19f36ce174bbfcd58f6e2bad5313d2de7cdc43c7 M	testing
   #+END_EXAMPLE

I have to stop here because I don't know Emacs Lisp and org-mode
internals to debug further.

---
WBR, Vladimir Lomov

-- 
<wichert> solaris is bsd, so it should work
* Espy takes wichert's crack pipe away

Re: [BUG?] Strange message in minibuffer while exporting into HTML

[Eric S Fraga]

Vladimir Lomov <lomov.vl@gmail.com> writes:

> Hello,
> please consider this sample Org document (ex-call.org):

[...]

> Recently I faced with a strange message in minibuffer:
> #+BEGIN_EXAMPLE
> Marker points into wrong buffer: #<marker in no buffer>
> #+END_EXAMPLE
> when exporting the Org document into HTML.

[...]

I think this might be a is the same problem I posted about a couple of days ago, a
problem that affects both #+call: and call_ invocations of babel blocks.

When I try your file, exporting to either HTML or LaTeX, I get the same
error.  I am using the latest emacs snapshot.

What is interesting is that if I save your file as t.org, extra buffers
named t.org<2> and t.org<2><2> are created after having done two export
attempts.  Do either of these appear for you?

By the way, what version of Emacs are you using?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.1-86-gbe3dad

Re: [BUG?] Strange message in minibuffer while exporting into HTML

[Vladimir Lomov]

Hello,
** Eric S Fraga [2013-10-11 08:45:09 +0100]:

> Vladimir Lomov <lomov.vl@gmail.com> writes:

>> Hello,
>> please consider this sample Org document (ex-call.org):

> [...]

>> Recently I faced with a strange message in minibuffer:
>> #+BEGIN_EXAMPLE
>> Marker points into wrong buffer: #<marker in no buffer>
>> #+END_EXAMPLE
>> when exporting the Org document into HTML.

> [...]

> I think this might be a is the same problem I posted about a couple of days ago, a
> problem that affects both #+call: and call_ invocations of babel blocks.

> When I try your file, exporting to either HTML or LaTeX, I get the same
> error.  I am using the latest emacs snapshot.

> What is interesting is that if I save your file as t.org, extra buffers
> named t.org<2> and t.org<2><2> are created after having done two export
> attempts.  Do either of these appear for you?

No, I think because export function fails so it can't produce any buffer.

> By the way, what version of Emacs are you using?

Emacs compile from bzr repository (currently this is 114588).

---
WBR, Vladimir Lomov

-- 
"For three days after death hair and fingernails continue to grow but
phone calls taper off."
		-- Johnny Carson