Macro question

Macro question

[Fabrice Popineau]

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

I was wondering if macros could be used to output raw html code, but that
doesn't seem to be the case.

Namely:

#+macro: bfoo @@html:<div class"foo">@@
#+macro: efoo @@html:</div>@@

The macros {{{bfoo}}} and {{{efoo}}} are expanded surrounded by <p> ...
</p>.

This is quite a limitation. Is it the intended behavior?
If the reason is that the macro could output text that needs the <p> ...
</p>, then
the problem is the point at which macros are expanded in the flow.
An option would be to allow #+html: in the macro, but that doesn't work.
The #+html:
directive gets straight on the output.

Sorry if this has already been discussed here.
(I vaguely remember some discussions about recursive macros)

Fabrice

[-- Attachment #2: Type: text/html, Size: 1018 bytes --]

Re: Macro question

[Nicolas Goaziou]

Hello,

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> I was wondering if macros could be used to output raw html code, but that
> doesn't seem to be the case.
>
> Namely:
>
> #+macro: bfoo @@html:<div class"foo">@@
> #+macro: efoo @@html:</div>@@
>
> The macros {{{bfoo}}} and {{{efoo}}} are expanded surrounded by <p> ...
> </p>.

Macros can output raw inline HTML code. If you want to generate any HTML
code, you can use some babel block to do that.

Regards,

-- 
Nicolas Goaziou

Re: Macro question

[Fabrice Popineau]

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

Hello Nicolas,

2015-10-23 22:37 GMT+02:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>
> > I was wondering if macros could be used to output raw html code, but that
> > doesn't seem to be the case.
> >
> > Namely:
> >
> > #+macro: bfoo @@html:<div class"foo">@@
> > #+macro: efoo @@html:</div>@@
> >
> > The macros {{{bfoo}}} and {{{efoo}}} are expanded surrounded by <p> ...
> > </p>.
>
> Macros can output raw inline HTML code. If you want to generate any HTML
> code, you can use some babel block to do that.
>
>
I agree that raw html can be output by macros, but it can easily break too.

At the moment :

---------------------------------------------------------------------------------------------
#+macro: bfoo @@html:<div class"foo">@@
#+macro: efoo @@html:</div>@@

* Section

{{{bfoo}}}

Some text.

{{{efoo}}}
---------------------------------------------------------------------------------------------

is exported as :

---------------------------------------------------------------------------------------------
<div id="outline-container-orgheadline1" class="outline-2">
<h2 id="orgheadline1">Section</h2>
<div class="outline-text-2" id="text-orgheadline1">
<p>

</p>

<p>
<div class"foo">
</p>

<p>
Some text.
</p>

<p>
</div>
</p>
</div>
</div>
---------------------------------------------------------------------------------------------

But :

---------------------------------------------------------------------------------------------
#+macro: bfoo @@html:<div class"foo">@@
#+macro: efoo @@html:</div>@@

* Section

{{{bfoo}}}
Some text.
{{{efoo}}}
---------------------------------------------------------------------------------------------

is exported as :

---------------------------------------------------------------------------------------------
<div id="outline-container-orgheadline1" class="outline-2">
<h2 id="orgheadline1">Section</h2>
<div class="outline-text-2" id="text-orgheadline1">
<p>

</p>

<p>
<div class"foo">
Some text.
</div>
</p>
</div>
</div>
---------------------------------------------------------------------------------------------

In the first case, the <p> ... </p> are quite annoying.
In the second case,  the <p> ... </p> is spurious, but at least it doesn't
break the structure.

I wonder if there is a way to guess where ox-html could avoid to emit
paragraphs.

Regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 4383 bytes --]

Re: Macro question

[Nicolas Goaziou]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> I agree that raw html can be output by macros, but it can easily break
> too.

I think you are missing the "inline part". You cannot use macros to
generate, or even replace a block element in HTML (e.g., a paragraph).

Regards,

Re: Macro question

[Fabrice Popineau]

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

2015-10-24 0:18 GMT+02:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>
> > I agree that raw html can be output by macros, but it can easily break
> > too.
>
> I think you are missing the "inline part". You cannot use macros to
> generate, or even replace a block element in HTML (e.g., a paragraph).
>
> Well, thinking about it, "raw inline html" needs to be clarified for me,
because
even a mere :

@@html:<br/>@@

is surrounded by a paragraph.

My point is that what can be achieved by macros depends on the backend,
which defeats part of the purpose of having a high level markup language.

#+MACRO: newline @@latex:\\@@ @@html:<br/>@@

This works for LaTeX, because LaTeX has no markup for paragraphs (I agree
it is pure luck), but fails
for HTML because there is one.

OTOH, resorting to babel blocks to insert a newline is not viable option:
it takes much more to achieve something very simple.

Basically, macros are of no help to solve this :

------------------------------------------------------------------------------------------
#+MACRO: newline @@latex:\\@@ @@html:<br/>@@

* Section 2

Some text.

{{{newline}}}

Some other text.

#+html: <br/>
#+latex: \\

Some other other text.
------------------------------------------------------------------------------------------

The macro way isn't a proper way: the <br/> will be embedded in a
paragraph, where it shouldn't.
Only the second way achieves cleanly the expected effect. Well, not quite
because in LaTeX, the \\ should stick to the paragraph.
So it should be :

Some other text.
#+latex: \\

#+html: <br/>

If I'm wrong, thanks for pointing me to the right way to use macros.
And if I'm right, maybe in the long term, Org needs another, different,
macro system
to help at this level.

Regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 3022 bytes --]

Re: Macro question

[Nicolas Goaziou]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> Well, thinking about it, "raw inline html" needs to be clarified for
> me, because even a mere :
>
> @@html:<br/>@@
>
> is surrounded by a paragraph.
>
> My point is that what can be achieved by macros depends on the backend,
> which defeats part of the purpose of having a high level markup language.
>
> #+MACRO: newline @@latex:\\@@ @@html:<br/>@@
>
> This works for LaTeX, because LaTeX has no markup for paragraphs (I agree
> it is pure luck), but fails
> for HTML because there is one.
>
> OTOH, resorting to babel blocks to insert a newline is not viable option:
> it takes much more to achieve something very simple.
>
> Basically, macros are of no help to solve this :
>
> ------------------------------------------------------------------------------------------
> #+MACRO: newline @@latex:\\@@ @@html:<br/>@@
>
> * Section 2
>
> Some text.
>
> {{{newline}}}
>
> Some other text.
>
> #+html: <br/>
> #+latex: \\
>
> Some other other text.
> ------------------------------------------------------------------------------------------
>
> The macro way isn't a proper way: the <br/> will be embedded in a
> paragraph, where it shouldn't.

Exactly. Macros are not a solution for that, which is fine, IMO.

> Only the second way achieves cleanly the expected effect. Well, not quite
> because in LaTeX, the \\ should stick to the paragraph.
> So it should be :
>
> Some other text.
> #+latex: \\
>
> #+html: <br/>

I don't get it.

What about simply writing

  Some other text.
  \\

?

> If I'm wrong, thanks for pointing me to the right way to use macros.
> And if I'm right, maybe in the long term, Org needs another, different,
> macro system to help at this level.

Org already provides various tools. If a macro doesn't fit, you can use
a filter, or Babel, etc.

Regards,

Re: Macro question

[Fabrice Popineau]

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

>
>
> I don't get it.
>
> What about simply writing
>
>   Some other text.
>   \\
>
> ?
>
>
Ok for a new line, but I was looking for a way to get 2 columns on a slide,
independently of the backend, beamer or reveal.

One easy way would have been to write :

{{{beginColumns}}}

{{{nextColumn}}}

{{{endColumns}}}

I find that using headers as in beamer is not pleasant (maybe that is just
me ?)
Moreover, it works only in beamer.

At the moment, there is no "easy" way. Either resort to babel, or probably
better, derive a new backend.


Fabrice

[-- Attachment #2: Type: text/html, Size: 1046 bytes --]

Re: Macro question

[Nicolas Goaziou]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> Ok for a new line, but I was looking for a way to get 2 columns on a slide,
> independently of the backend, beamer or reveal.
>
> One easy way would have been to write :
>
> {{{beginColumns}}}
>
> {{{nextColumn}}}
>
> {{{endColumns}}}
>
> I find that using headers as in beamer is not pleasant (maybe that is just
> me ?)
> Moreover, it works only in beamer.
>
> At the moment, there is no "easy" way. Either resort to babel, or probably
> better, derive a new backend.

I don't know ox-reveal, so I cannot help here. However, macros are not
meant for structural changes, only contents changes (and small ones).


Regards,

Re: Macro question

[Eric S Fraga]

On Saturday, 24 Oct 2015 at 13:37, Fabrice Popineau wrote:

[...]

> I find that using headers as in beamer is not pleasant (maybe that is just
> me ?)

Just to help you understand the positive aspect of headlines for
structure in beamer, the use of headlines makes it incredibly easy to
switch columns around, for instance, or to copy/move them from slide to
slide.

With respect to the HTML issue, what if you do not put blank lines
between the different bits?  The blank lines are defining paragraphs, as
far as I understand it.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: Macro question

[Fabrice Popineau]

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

2015-10-24 19:02 GMT+02:00 Eric S Fraga <e.fraga@ucl.ac.uk>:

> On Saturday, 24 Oct 2015 at 13:37, Fabrice Popineau wrote:
>
> [...]
>
> > I find that using headers as in beamer is not pleasant (maybe that is
> just
> > me ?)
>
> Just to help you understand the positive aspect of headlines for
> structure in beamer, the use of headlines makes it incredibly easy to
> switch columns around, for instance, or to copy/move them from slide to
> slide.
>

You are right. This needs to be put forward.
In this case, the parameter that has to be made easily editable
is the width of the column. (Thinking about a common interface for
beamer and reveal)


> With respect to the HTML issue, what if you do not put blank lines
> between the different bits?  The blank lines are defining paragraphs, as
> far as I understand it.
>
>
It is possible to hack the reveal/html exporter.
Knowing that

{{{bFoo}}}
...
{{{eFoo}}}

gets exported to

<p>
<div class="foo">
</p>

<p>
</div>
</p>

The macros could be defined:
#+macro: bFoo @@html:</p><div class="foo"><p>@@
#+macro: eFoo @@html:</p></div><p>@@

and this way you get spurious paragraphs, but valid html
However, I'm not sure I want to follow this path !

Best regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 2380 bytes --]

Re: Macro question

[Eric S Fraga]

On Sunday, 25 Oct 2015 at 10:45, Fabrice Popineau wrote:

[...]

> In this case, the parameter that has to be made easily editable
> is the width of the column. (Thinking about a common interface for
> beamer and reveal)

Column mode is great for editing such things.  However, we would need
(as has been suggested elsewhere) a common set of properties that are
backend agnostic, such as COLUMN_WIDTH instead of BEAMER_col.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33