emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [Bug] Verbatim code gets interpreted
@ 2011-03-07  8:06 Sébastien Vauban
  2011-03-07 15:30 ` Bastien
  0 siblings, 1 reply; 3+ messages in thread
From: Sébastien Vauban @ 2011-03-07  8:06 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi,

When trying to put some JS code in an Org file (to be published), I did it
that way:

#+begin_html
<div id="disqus_thread"></div>
<script type="text/javascript">
    (function() {
        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
        dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
    })();
</script>
#+end_html

But the [0] gets interpreted as a footnote... which is not found, hence an
error on the page, and the JS code is not usable.

The workaround is really easy for now:

#+HTML:<div id="disqus_thread"></div>
#+HTML:<script type="text/javascript">
#+HTML:    (function() {
#+HTML:        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
#+HTML:        dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
#+HTML:        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
#+HTML:    })();
#+HTML:</script>

But I wanted to report this finding.

Best regards,
  Seb

-- 
Sébastien Vauban

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bug] Verbatim code gets interpreted
  2011-03-07  8:06 [Bug] Verbatim code gets interpreted Sébastien Vauban
@ 2011-03-07 15:30 ` Bastien
  2011-03-08 16:02   ` Sébastien Vauban
  0 siblings, 1 reply; 3+ messages in thread
From: Bastien @ 2011-03-07 15:30 UTC (permalink / raw)
  To: Sébastien Vauban; +Cc: emacs-orgmode

Hi Sébastien,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> #+begin_html
> <div id="disqus_thread"></div>
> <script type="text/javascript">
>     (function() {
>         var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
>         dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
>         (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
>     })();
> </script>
> #+end_html
>
> But the [0] gets interpreted as a footnote... which is not found, hence an
> error on the page, and the JS code is not usable.
>
> [...]
>
> But I wanted to report this finding.

Thanks for reporting this.  I think we could rewrite the export
preprocess function to allow export parameters to be added:

,----
| #+begin_html ^:nil 
| ...
| #+end_html
`----

In such a block, the ^:nil option would take precedence over the
possibly ^:t option in the buffer.  I'll have a look into this for 
the next release.

Best,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bug] Verbatim code gets interpreted
  2011-03-07 15:30 ` Bastien
@ 2011-03-08 16:02   ` Sébastien Vauban
  0 siblings, 0 replies; 3+ messages in thread
From: Sébastien Vauban @ 2011-03-08 16:02 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hi Bastien,

> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>> #+begin_html
>> <div id="disqus_thread"></div>
>> <script type="text/javascript">
>>     (function() {
>>         var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
>>         dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
>>         (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
>>     })();
>> </script>
>> #+end_html
>>
>> But the [0] gets interpreted as a footnote... which is not found, hence an
>> error on the page, and the JS code is not usable.
>>
>> [...]
>>
>> But I wanted to report this finding.
>
> Thanks for reporting this. I think we could rewrite the export preprocess
> function to allow export parameters to be added:
>
> ,----
> | #+begin_html ^:nil 
> | ...
> | #+end_html
> `----
>
> In such a block, the ^:nil option would take precedence over the possibly
> ^:t option in the buffer. I'll have a look into this for the next release.

Such a behavior is OK for me (as who can do more can do less), but I wonder
why we simply don't treat the block between `#+begin/end_html' as verbatim,
without touching it at all?

Couldn't one do the same as what happens for the lines prefixed by `#+HTML'?

Best regards,
  Seb

-- 
Sébastien Vauban

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-03-08 16:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-07  8:06 [Bug] Verbatim code gets interpreted Sébastien Vauban
2011-03-07 15:30 ` Bastien
2011-03-08 16:02   ` Sébastien Vauban

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).