[new exporter] 2 questions

[new exporter] 2 questions

[henry atting]

I'm checking out the new exporter. After some configuration and file
changes it works now, could be worse.

http://article.gmane.org/gmane.emacs.orgmode/65574 says:

> The `org-special-blocks.el' library, which has been moved to “contrib/”,
>  is obsolete since its features are included in the new export
>  framework.

The features are included, does this mean special block should work
``out of the box''? If so something like this 

#+begin_multicols {2}
#+end_multicols

should work in LaTeX export (as it did flawlessly with the previous
exporter); - but it fails.


How do I invoke org-info.js now? `#+INFOJS_OPT:' does not work as
expected so it must be obsolete, no?


-- 
henry, web: http://literaturlatenight.de

Re: [new exporter] 2 questions

[Nicolas Goaziou]

Hello,

henry atting <snd@online.de> writes:

> The features are included, does this mean special block should work
> ``out of the box''? If so something like this 
>
> #+begin_multicols {2}
> #+end_multicols
>
> should work in LaTeX export (as it did flawlessly with the previous
> exporter); - but it fails.

Try:

  #+attr_latex: :options "{2}"
  #+begin_multicols
  ...
  #+end_multicols

> How do I invoke org-info.js now? `#+INFOJS_OPT:' does not work as
> expected so it must be obsolete, no?

Be sure to (require 'ox-infojs)

There should be some completion for #+INFOJS_OPT keyword with M-TAB.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[henry atting]

Hi Nicolas,

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

> Hello,
>
> henry atting <snd@online.de> writes:
>
>> The features are included, does this mean special block should work
>> ``out of the box''? If so something like this 
>>
>> #+begin_multicols {2}
>> #+end_multicols
>>
>> should work in LaTeX export (as it did flawlessly with the previous
>> exporter); - but it fails.
>
> Try:
>
>   #+attr_latex: :options "{2}"
>   #+begin_multicols
>   ...
>   #+end_multicols

It creates this command in the .tex file:

\#+begin$_\mathrm{multicols}$

>> How do I invoke org-info.js now? `#+INFOJS_OPT:' does not work as
>> expected so it must be obsolete, no?
>
> Be sure to (require 'ox-infojs)
>

This works fine but the correct spelling is (require 'ox-jsinfo) 

> There should be some completion for #+INFOJS_OPT keyword with M-TAB.
>
>
> Regards,

Thanks,

-- 
henry atts, web: http://literaturlatenight.de

Re: [new exporter] 2 questions

[Nicolas Goaziou]

henry atting <snd@online.de> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> Try:
>>
>>   #+attr_latex: :options "{2}"
>>   #+begin_multicols
>>   ...
>>   #+end_multicols
>
> It creates this command in the .tex file:
>
> \#+begin$_\mathrm{multicols}$

It works here. Difficult to say what is wrong in your buffer without
more context.

>> Be sure to (require 'ox-infojs)
>>
>
> This works fine but the correct spelling is (require 'ox-jsinfo) 

Actually, library "ox-jsinfo.el" provides both symbols.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[henry atting]

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

> henry atting <snd@online.de> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>> Try:
>>>
>>>   #+attr_latex: :options "{2}"
>>>   #+begin_multicols
>>>   ...
>>>   #+end_multicols
>>
>> It creates this command in the .tex file:
>>
>> \#+begin$_\mathrm{multicols}$
>
> It works here. Difficult to say what is wrong in your buffer without
> more context.

Here is a minimal example. I use lualatex as tex engine.

--8<---------------cut here---------------start------------->8---
#+TITLE: lorem ipsum
#+LANGUAGE: de
#+LaTeX_CLASS: scrartcl
#+LaTeX_CLASS_OPTIONS: [DIV=8,a4paper]
#+LaTeX_HEADER: \usepackage{fontspec}

#+attr_latex: :options "{2}" 
#+begin_multicols

* Lorem ipsum

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam
lectus. Sed sit amet ipsum mauris. Maecenas congue ligula ac quam
viverra nec consectetur ante hendrerit. Donec et mollis dolor.
Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam
tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut
libero sed arcu vehicula ultricies a non tortor.
begreift.

#+end_multicols

--8<---------------cut here---------------end--------------->8---

>
>>> Be sure to (require 'ox-infojs)
>>>
>>
>> This works fine but the correct spelling is (require 'ox-jsinfo) 
>
> Actually, library "ox-jsinfo.el" provides both symbols.
>
>
> Regards,

Thanks,

-- 
henry atts, web: http://literaturlatenight.de

Re: [new exporter] 2 questions

[Nicolas Goaziou]

henry atting <snd@online.de> writes:

> Here is a minimal example. I use lualatex as tex engine.
>
> #+TITLE: lorem ipsum
> #+LANGUAGE: de
> #+LaTeX_CLASS: scrartcl
> #+LaTeX_CLASS_OPTIONS: [DIV=8,a4paper]
> #+LaTeX_HEADER: \usepackage{fontspec}
>
> #+attr_latex: :options "{2}" 
> #+begin_multicols
>
> * Lorem ipsum

[...]

You can't have a headline within a block.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[henry atting]

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

> henry atting <snd@online.de> writes:
>
>> Here is a minimal example. I use lualatex as tex engine.
>>
>> #+TITLE: lorem ipsum
>> #+LANGUAGE: de
>> #+LaTeX_CLASS: scrartcl
>> #+LaTeX_CLASS_OPTIONS: [DIV=8,a4paper]
>> #+LaTeX_HEADER: \usepackage{fontspec}
>>
>> #+attr_latex: :options "{2}" 
>> #+begin_multicols
>>
>> * Lorem ipsum
>
> [...]
>
> You can't have a headline within a block.
>
>
> Regards,

Thanks.
Then the consequence is that I have to edit the .tex file manually which
I did not have to do with the previous exporter.


-- 
henry atts, web: http://literaturlatenight.de

Re: [new exporter] 2 questions

[Nicolas Goaziou]

henry atting <snd@online.de> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> henry atting <snd@online.de> writes:
>>
>>> Here is a minimal example. I use lualatex as tex engine.
>>>
>>> #+TITLE: lorem ipsum
>>> #+LANGUAGE: de
>>> #+LaTeX_CLASS: scrartcl
>>> #+LaTeX_CLASS_OPTIONS: [DIV=8,a4paper]
>>> #+LaTeX_HEADER: \usepackage{fontspec}
>>>
>>> #+attr_latex: :options "{2}" 
>>> #+begin_multicols
>>>
>>> * Lorem ipsum
>>
>> [...]
>>
>> You can't have a headline within a block.
>>
>>
>> Regards,
>
> Thanks.
> Then the consequence is that I have to edit the .tex file manually which
> I did not have to do with the previous exporter.

Or you may use:

  #+latex: \begin{multicols}{2}

  * Headline

  #+latex: \end{multicols}


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[henry atting]

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

> henry atting <snd@online.de> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>> henry atting <snd@online.de> writes:
>>>
>>>> Here is a minimal example. I use lualatex as tex engine.
>>>>
>>>> #+TITLE: lorem ipsum
>>>> #+LANGUAGE: de
>>>> #+LaTeX_CLASS: scrartcl
>>>> #+LaTeX_CLASS_OPTIONS: [DIV=8,a4paper]
>>>> #+LaTeX_HEADER: \usepackage{fontspec}
>>>>
>>>> #+attr_latex: :options "{2}" 
>>>> #+begin_multicols
>>>>
>>>> * Lorem ipsum
>>>
>>> [...]
>>>
>>> You can't have a headline within a block.
>>>
>>>
>>> Regards,
>>
>> Thanks.
>> Then the consequence is that I have to edit the .tex file manually which
>> I did not have to do with the previous exporter.
>
> Or you may use:
>
>   #+latex: \begin{multicols}{2}
>
>   * Headline
>
>   #+latex: \end{multicols}
>
>
> Regards,

Great! Thanks again.

-- 
henry atts, web: http://literaturlatenight.de

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
>> It creates this command in the .tex file:
>>
>> \#+begin$_\mathrm{multicols}$
>
> It works here. Difficult to say what is wrong in your buffer without
> more context.

That result looks exactly like my problem with multiline \[...\],
i.e. the parser found something it considers an element inside the
multicols block and that made the block itself look like random text
that needs to be escaped.



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] 2 questions

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>>> It creates this command in the .tex file:
>>>
>>> \#+begin$_\mathrm{multicols}$
>>
>> It works here. Difficult to say what is wrong in your buffer without
>> more context.
>
> That result looks exactly like my problem with multiline \[...\],
> i.e. the parser found something it considers an element inside the
> multicols block and that made the block itself look like random text
> that needs to be escaped.

Yes, that's a problem.

I don't think \[ .. \] constructs and arbitrary blocks should allow
comma-escaping, that would be unreadable.  But their content should
not be parsed further as Org syntactic elements.

Nicolas, how hard would it be to let the parser DTRT here in both
cases?

-- 
 Bastien

Re: [new exporter] 2 questions

[Nicolas Goaziou]

Bastien <bzg@altern.org> writes:

> Hi Achim,
>
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Nicolas Goaziou writes:
>>>> It creates this command in the .tex file:
>>>>
>>>> \#+begin$_\mathrm{multicols}$
>>>
>>> It works here. Difficult to say what is wrong in your buffer without
>>> more context.
>>
>> That result looks exactly like my problem with multiline \[...\],
>> i.e. the parser found something it considers an element inside the
>> multicols block and that made the block itself look like random text
>> that needs to be escaped.
>
> Yes, that's a problem.
>
> I don't think \[ .. \] constructs and arbitrary blocks should allow
> comma-escaping, that would be unreadable.  But their content should
> not be parsed further as Org syntactic elements.
>
> Nicolas, how hard would it be to let the parser DTRT here in both
> cases?

IMO the parser already DTRT. In which case do you think it doesn't?


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> IMO the parser already DTRT. In which case do you think it doesn't?

DTRT is what you define as DTRT, so yes it does that already.  At the
very least it would be nice if the parser warned when it finds stray
syntax pieces that are missing their match (it took me quite a while to
see what was going on).  If I look at the buffer I see things
differently than the parser, so some way to ask what the parser thinks
I'm looking at would be nice (maybe that exists already, I don't know).
And in all these cases where something inside an object or an element
looks like it might be another element or greater element, we do need a
way of quoting, I'd say. 


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] 2 questions

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> IMO the parser already DTRT. In which case do you think it doesn't?

> DTRT is what you define as DTRT, so yes it does that already. At the
> very least it would be nice if the parser warned when it finds stray
> syntax pieces that are missing their match (it took me quite a while
> to see what was going on). If I look at the buffer I see things
> differently than the parser, 

The parser parses Org syntax. If you see something else, unless there is
an obvious bug, then you are expecting the Org syntax to be different
from what it is. It's even the goal of the parser: to define the way to
read Org syntax.

Actually it is very simple to understand: elements have precedence over
objects. So in the following case:

--8<---------------cut here---------------start------------->8---
xxxx xxxx x x xxxxxxxxxxxx xxxxx xxxx xxxxxxxxxxxxxxx xxxx xxxxxxxx xxxx
x xxxx xx xx xx xxxxxxxxx xxxx xxxx x xx x x xx 
- item 1
- item 2
--8<---------------cut here---------------end--------------->8---

there's a paragraph followed by a plain list, no matter what is found
within the paragraph.

And it's still the case when we replace "x" with tricky contents like:

--8<---------------cut here---------------start------------->8---

Some paragraph, something that looks like a link start [[#eisetu][and
something that looks like a math snippet \(2 + 3
- item 1
- item 2
--8<---------------cut here---------------end--------------->8---

> so some way to ask what the parser thinks I'm looking at would be nice
> (maybe that exists already, I don't know).

Usually fontification is a good indicator. Unfortunately, Org
fontification doesn't rely on the parser at the moment, so there are
some discrepancies.

Also, you're thinking backwards here: the parser doesn't have to think
about what you're looking at, as it knows it. Alas it can't know what
you're thinking you're looking at.

Anyway you can use (org-element-context) to know where point currently
is.

> And in all these cases where something inside an object or an element
> looks like it might be another element or greater element, we do need
> a way of quoting, I'd say.

No element can be found within an object.

So far, I don't see a need for quoting. In your previous example, you
know (or should know) that "- " as the first non-white string in a line
defines an item. You keep wanting to see a mathematical operation,
probably because you're focused on the LaTeX snippet you're writing, but
you're wrong wrt Org syntax.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> The parser parses Org syntax. If you see something else, unless there is
> an obvious bug, then you are expecting the Org syntax to be different
> from what it is. It's even the goal of the parser: to define the way to
> read Org syntax.

That's what I said.  You also defined "The Way Things Are"(TM) to make
the job of parsing easier and faster.  I can also understand that.  But
I (sometimes at least) also simply use Org and I run into things that
should have a solution, other than "Don't do that!".

> Some paragraph, something that looks like a link start [[#eisetu][and
> something that looks like a math snippet \(2 + 3
> - item 1
> - item 2

The example was slightly different and I think that matters for the
discussion.  Note that those terms span the better part of a line and
I'm usually using at least 130 chars wide lines.

--8<---------------cut here---------------start------------->8---
Some paragraph, something that looks like a link start [[#eisetu][and
something that looks like a math snippet
#
\[
R = term1
- term2
+ term3
\]
#
end of the paragraph started above.
--8<---------------cut here---------------end--------------->8---

Org sees that as a paragraph with some wierd ending, a list with two
items and another paragraph with a wierd beginning.  The user doesn't
even start to think about it in this way until the exporter stops with a
LaTeX error.

> Also, you're thinking backwards here: the parser doesn't have to think
> about what you're looking at, as it knows it. Alas it can't know what
> you're thinking you're looking at.

The question is if that simplification in parsing is worth the
unintuitive result.  The main reason for this is that the paragraph
parsing doesn't consider objects in the paragraph at all during parsing.
If the objects would be parsed directly when they are encountered, it
would be clear that the two extra terms are not a list.

> Anyway you can use (org-element-context) to know where point currently
> is.

Thanks.

>> And in all these cases where something inside an object or an element
>> looks like it might be another element or greater element, we do need
>> a way of quoting, I'd say.
>
> No element can be found within an object.

A list was found inside what the user intended to be a LaTeX fragment.
It also made two paragraphs out of what should have been a single one.
The user found out only after trying to export the document.

> So far, I don't see a need for quoting. In your previous example, you
> know (or should know) that "- " as the first non-white string in a line
> defines an item. You keep wanting to see a mathematical operation,
> probably because you're focused on the LaTeX snippet you're writing, but
> you're wrong wrt Org syntax.

Or maybe the Org syntax is wrong w.r.t. usability and robustness.  The
same issue is encountered often enough with blocks (you've answered
quite a number of those questions): they are suggestive to the user of
being self contained, but Org syntax says they aren't.  I call that a
trap for the unwary.


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] 2 questions

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> The parser parses Org syntax. If you see something else, unless there is
>> an obvious bug, then you are expecting the Org syntax to be different
>> from what it is. It's even the goal of the parser: to define the way to
>> read Org syntax.
>
> That's what I said.  You also defined "The Way Things Are"(TM) to make
> the job of parsing easier and faster.  I can also understand that.  But
> I (sometimes at least) also simply use Org and I run into things that
> should have a solution, other than "Don't do that!".

I gave you a solution since the beginning of this thread: use a latex
environment.

>> Some paragraph, something that looks like a link start [[#eisetu][and
>> something that looks like a math snippet \(2 + 3
>> - item 1
>> - item 2
>
> The example was slightly different and I think that matters for the
> discussion.  Note that those terms span the better part of a line and
> I'm usually using at least 130 chars wide lines.
>
> Some paragraph, something that looks like a link start [[#eisetu][and
> something that looks like a math snippet
> #
> \[
> R = term1
> - term2
> + term3
> \]
> #
> end of the paragraph started above.
>
> Org sees that as a paragraph with some wierd ending, 

It would be interesting to know what Org judges as weird.

> a list with two items and another paragraph with a wierd beginning.
> The user doesn't even start to think about it in this way until the
> exporter stops with a LaTeX error.

Fontification helps (or should help) here. Anyway, this problem is
unrelated to the LaTeX exporter, since it only exports what parser
parses.

> The question is if that simplification in parsing is worth the
> unintuitive result. The main reason for this is that the paragraph
> parsing doesn't consider objects in the paragraph at all during
> parsing. If the objects would be parsed directly when they are
> encountered, it would be clear that the two extra terms are not
> a list.

It /is/ intuitive and quite simple actually. "*" at column 0 starts
a headline, "- " at the beginning of a line starts a list[fn:1]... Very
often, you know what you're writing just by looking at the beginning of
the line.

On the other hand, if you allow the first object to start to have
precedence over what comes next, you're in big trouble. In fact, you may
have to look dozens of lines above only to discover you had started an
object before the one you were expecting to write.

--8<---------------cut here---------------start------------->8---
~lorem....
...
a dozen of lines
...
\[
R = term 1
- term 2
+ term 3
\]
end of paragraph or so I think~
--8<---------------cut here---------------end--------------->8---

Here you didn't write a math snippet. Sure, you can add a hack and
arbitrary say "Objects are never longer than 3 lines". Then, in this
case, you didn't write a math snippet either.

Also, if there's no order in which syntactical elements are parsed, the
following could as well be a math snippet instead of an headline:

--8<---------------cut here---------------start------------->8---
\(
* 2
\)
--8<---------------cut here---------------end--------------->8---

Sorry, but it has never been the case in Org. Org has always implied
classification in syntax. And that's a quite sane behaviour. Otherwise,
you can never be sure about what you're writing without memorizing the
complete buffer.

Again, the current syntax is very regular. It can lead to surprises,
I understand that, but far less than with what you expect.

> A list was found inside what the user intended to be a LaTeX fragment.
> It also made two paragraphs out of what should have been a single one.

I disagree with that part. There shouldn't have been a single paragraph,
and there isn't. Not in Org syntax, at least.

> Or maybe the Org syntax is wrong w.r.t. usability and robustness.  The
> same issue is encountered often enough with blocks (you've answered
> quite a number of those questions): they are suggestive to the user of
> being self contained, but Org syntax says they aren't.  I call that a
> trap for the unwary.

I just suggest to learn Org syntax. Any help to upgrade the
documentation accordingly and make this task easier is welcome.


Regards,

[fn:1] Ok, this one has exceptions, like in src blocks, but there's also
an explanation.

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> I gave you a solution since the beginning of this thread: use a latex
> environment.

It is not a solution because it does not export to HTML.  If I need to
write the document mostly in LaTeX I can start with LaTeX and and then
use some LaTeX to HTML translation.


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] 2 questions

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

>> I gave you a solution since the beginning of this thread: use a latex
>> environment.
>
> It is not a solution because it does not export to HTML.

Of course it does. Try:

--8<---------------cut here---------------start------------->8---
Some latex

\begin{equation*}
2 + 2
\end{equation*}
--8<---------------cut here---------------end--------------->8---

and export to HTML.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> I gave you a solution since the beginning of this thread: use a latex
> environment.

After a bit of searching: the answer was in another thread, not in
answer to my original question and I read that answer as "LaTeX blocks
are equivalent to LaTeX environments".  I see now that they are not.

There is one remaining difference to a display equation or LaTeX
fragment: the LaTeX environment will apparently always end the
paragraph, something that LaTeX does or does not do depending on whether
you surround an environment with whitespace.


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] 2 questions

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> There is one remaining difference to a display equation or LaTeX
> fragment: the LaTeX environment will apparently always end the
> paragraph,

Indeed. A LaTeX environment has got the same syntactical value as
a paragraph (both are elements): they cannot be nested.

> something that LaTeX does or does not do depending on whether
> you surround an environment with whitespace.

True, that's why there's also inline \[...\]. But you have to accept
paragraph limitations (no empty line, do not start a line with list
markers...).

Another difference is that LaTeX environments can be given a name and
a caption, allowing them to be cross-referenced.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> True, that's why there's also inline \[...\]. But you have to accept
> paragraph limitations (no empty line, do not start a line with list
> markers...).

Now, given that difference and the fact that these things can span over
multiple lines and thus include the beginning of line (which creates the
contention between different tiers of org-element's parsing hierarchy),
let me ask one more time if it would be possible to escape the beginning
of line (most likely and the obvious choices given Org's history would
be ":" or ",") in a general fashion and remove it only when the
(greater) elements have been parsed already and the content is about to
be used.  In fact if I put one of those two characters there (or
anything else really that doesn't create spurious syntax) it almost
works correctly already, only the stripping of the escape characters is
missing.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [new exporter] 2 questions

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> True, that's why there's also inline \[...\]. But you have to accept
>> paragraph limitations (no empty line, do not start a line with list
>> markers...).
>
> Now, given that difference and the fact that these things can span
> over multiple lines and thus include the beginning of line (which
> creates the contention between different tiers of org-element's
> parsing hierarchy),

Note that filling/auto-filling will never put you in this situation,
since Org has a protection mechanism. IOW, if you end up with a list
marker at the beginning of a line, it's your fault.

> let me ask one more time if it would be possible to escape the beginning
> of line (most likely and the obvious choices given Org's history would
> be ":" or ",") in a general fashion

Be careful here. ": " at a beginning of a line defines a fixed-width
area. It is an element and, therefore, would have precedence over your
math snippet. In this case, fontification will warn you.

Adding comma escaping in an object would be complicated because of
filling. It would also add even more problems. So, no, there needn't be
a protection mechanism in inline math snippets.

Also, let me remind you that, LaTeX-wise, "-2" is equivalent to "- 2".
So, you can avoid that list marker problem pretty easily.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] 2 questions

[Achim Gratz]

Nicolas Goaziou writes:
> Note that filling/auto-filling will never put you in this situation,
> since Org has a protection mechanism. IOW, if you end up with a list
> marker at the beginning of a line, it's your fault.

I don't use auto-fill in formulas.  And yes, I take responsibility for
my faults and try to correct them.

> Also, let me remind you that, LaTeX-wise, "-2" is equivalent to "- 2".
> So, you can avoid that list marker problem pretty easily.

I know there are many such workarounds, I've already used one before I
even asked the original question.  I was asking if it was possible to
solve the problem at its root with a general mechanism that can be used
in all cases and not just a specific one.  I failed to convince you that
this would be a useful thing to have and you failed to convince me that
there is no problem. Let's leave it at that, OK?


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