* [new exporter] 2 questions
@ 2013-02-22 18:06 henry atting
2013-02-22 19:04 ` Nicolas Goaziou
0 siblings, 1 reply; 23+ messages in thread
From: henry atting @ 2013-02-22 18:06 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [new exporter] 2 questions 2013-02-22 18:06 [new exporter] 2 questions henry atting @ 2013-02-22 19:04 ` Nicolas Goaziou 2013-02-22 19:38 ` henry atting 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-22 19:04 UTC (permalink / raw) To: henry atting; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 19:04 ` Nicolas Goaziou @ 2013-02-22 19:38 ` henry atting 2013-02-22 19:42 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: henry atting @ 2013-02-22 19:38 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 19:38 ` henry atting @ 2013-02-22 19:42 ` Nicolas Goaziou 2013-02-22 20:13 ` henry atting 2013-02-22 21:39 ` Achim Gratz 0 siblings, 2 replies; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-22 19:42 UTC (permalink / raw) To: henry atting; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 19:42 ` Nicolas Goaziou @ 2013-02-22 20:13 ` henry atting 2013-02-22 20:19 ` Nicolas Goaziou 2013-02-22 21:39 ` Achim Gratz 1 sibling, 1 reply; 23+ messages in thread From: henry atting @ 2013-02-22 20:13 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 20:13 ` henry atting @ 2013-02-22 20:19 ` Nicolas Goaziou 2013-02-22 20:31 ` henry atting 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-22 20:19 UTC (permalink / raw) To: henry atting; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 20:19 ` Nicolas Goaziou @ 2013-02-22 20:31 ` henry atting 2013-02-22 20:33 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: henry atting @ 2013-02-22 20:31 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 20:31 ` henry atting @ 2013-02-22 20:33 ` Nicolas Goaziou 2013-02-22 20:39 ` henry atting 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-22 20:33 UTC (permalink / raw) To: henry atting; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 20:33 ` Nicolas Goaziou @ 2013-02-22 20:39 ` henry atting 0 siblings, 0 replies; 23+ messages in thread From: henry atting @ 2013-02-22 20:39 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 19:42 ` Nicolas Goaziou 2013-02-22 20:13 ` henry atting @ 2013-02-22 21:39 ` Achim Gratz 2013-02-23 8:21 ` Bastien 1 sibling, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-22 21:39 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-22 21:39 ` Achim Gratz @ 2013-02-23 8:21 ` Bastien 2013-02-23 10:52 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: Bastien @ 2013-02-23 8:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 8:21 ` Bastien @ 2013-02-23 10:52 ` Nicolas Goaziou 2013-02-23 12:14 ` Achim Gratz 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-23 10:52 UTC (permalink / raw) To: Bastien; +Cc: Achim Gratz, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 10:52 ` Nicolas Goaziou @ 2013-02-23 12:14 ` Achim Gratz 2013-02-23 12:36 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-23 12:14 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 12:14 ` Achim Gratz @ 2013-02-23 12:36 ` Nicolas Goaziou 2013-02-23 13:04 ` Achim Gratz 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-23 12:36 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 12:36 ` Nicolas Goaziou @ 2013-02-23 13:04 ` Achim Gratz 2013-02-23 13:35 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-23 13:04 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 13:04 ` Achim Gratz @ 2013-02-23 13:35 ` Nicolas Goaziou 2013-02-23 15:21 ` Achim Gratz 2013-02-23 16:35 ` Achim Gratz 0 siblings, 2 replies; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-23 13:35 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 13:35 ` Nicolas Goaziou @ 2013-02-23 15:21 ` Achim Gratz 2013-02-23 15:31 ` Nicolas Goaziou 2013-02-23 16:35 ` Achim Gratz 1 sibling, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-23 15:21 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 15:21 ` Achim Gratz @ 2013-02-23 15:31 ` Nicolas Goaziou 0 siblings, 0 replies; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-23 15:31 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 13:35 ` Nicolas Goaziou 2013-02-23 15:21 ` Achim Gratz @ 2013-02-23 16:35 ` Achim Gratz 2013-02-23 17:39 ` Nicolas Goaziou 1 sibling, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-23 16:35 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 16:35 ` Achim Gratz @ 2013-02-23 17:39 ` Nicolas Goaziou 2013-02-23 18:40 ` Achim Gratz 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-23 17:39 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 17:39 ` Nicolas Goaziou @ 2013-02-23 18:40 ` Achim Gratz 2013-02-24 9:09 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: Achim Gratz @ 2013-02-23 18:40 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-23 18:40 ` Achim Gratz @ 2013-02-24 9:09 ` Nicolas Goaziou 2013-02-24 10:31 ` Achim Gratz 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2013-02-24 9:09 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [new exporter] 2 questions 2013-02-24 9:09 ` Nicolas Goaziou @ 2013-02-24 10:31 ` Achim Gratz 0 siblings, 0 replies; 23+ messages in thread From: Achim Gratz @ 2013-02-24 10:31 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-02-24 10:32 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-22 18:06 [new exporter] 2 questions henry atting 2013-02-22 19:04 ` Nicolas Goaziou 2013-02-22 19:38 ` henry atting 2013-02-22 19:42 ` Nicolas Goaziou 2013-02-22 20:13 ` henry atting 2013-02-22 20:19 ` Nicolas Goaziou 2013-02-22 20:31 ` henry atting 2013-02-22 20:33 ` Nicolas Goaziou 2013-02-22 20:39 ` henry atting 2013-02-22 21:39 ` Achim Gratz 2013-02-23 8:21 ` Bastien 2013-02-23 10:52 ` Nicolas Goaziou 2013-02-23 12:14 ` Achim Gratz 2013-02-23 12:36 ` Nicolas Goaziou 2013-02-23 13:04 ` Achim Gratz 2013-02-23 13:35 ` Nicolas Goaziou 2013-02-23 15:21 ` Achim Gratz 2013-02-23 15:31 ` Nicolas Goaziou 2013-02-23 16:35 ` Achim Gratz 2013-02-23 17:39 ` Nicolas Goaziou 2013-02-23 18:40 ` Achim Gratz 2013-02-24 9:09 ` Nicolas Goaziou 2013-02-24 10:31 ` Achim Gratz
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).