Re: [O] [PATCH] curly nested latex fragments
Hello, hero...@gentoo.org writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Unfortunately, this is ambiguous with Org macro syntax. For example, it would match: \alpha{{{macro(arg)}}} which is an entity followed by a macro. Err, insert a white space? \alpha {{{macro(arg)}}} Well, it may not be equivalent, depending on the macro. Also, this is not the point. \alpha{{{macro(arg)}}} is valid, so we have to parse it as something. In this case, there are two possible interpretations. I want to avoid it. Or expand the macro before latex-or-entity matching. Macro expansion only happens at the beginning of the export process. The problem you want to solve isn't necessarily tied to the export mechanism. Also, as you mention latex-or-entity, which doesn't exist anymore, you should look at the parsing code in master instead of maint, in particular to `org-element-latex-fragment-parser'. Maybe the mechanism used to find a macro can be improved to match more of them without matching anything else. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] curly nested latex fragments
Hello, hero...@gentoo.org writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I do not mind extending syntax for LaTeX macros a bit if it helps users, but first, I would like a clear definition of what subset of macros should be supported in Org. See, for example, http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments \ce{^{238}U} falls into \NAME POST, doesn't it? Sorry I wasn't clear. I suggested to not use a regexp to describe the syntax, as regular expressions may not be sufficient to describe the object. Try to use something like the link above. Also, bear in mind that a complicated regexp slows down parsing. Ha, I don't even aware of ... syntex as a part of the LaTeX macro; I just copied the regex from org-latex.el. So let's strip it out, and advise the users to use explicit LaTeX block for ... constructs. + (looking-at (concat + \\([a-zA-Z]+\\*?\\) + \\(?:\\[[^][\n]*?\\]\\)* + \\( (org-create-multibrace-regexp { } 3) \\)\\{1,3\\})) Unfortunately, this is ambiguous with Org macro syntax. For example, it would match: \alpha{{{macro(arg)}}} which is an entity followed by a macro. Do you mean this[2] and this[3] threads? I've read them through, and remotely understood the difficulty coming from the ambiguity of the syntax. And as discussed above, the difficulty manifests in the definition of LaTeX fragments, too. There is no ambiguity in LaTeX fragments, as Org is not required to support full raw LaTeX syntax (and never did anyway), as long as we provide markup to insert LaTeX in the buffer anyway. If we can support a bit more without introducing corner cases, that's fine. But, as you say, that's just syntactic sugar, so pure Org syntax goes first. At the same time, these syntax sugar is great. And that's the reason why we prefer org-mode in composing LaTeX to pristine LaTeX. There is a sincere need to compromise the cleanness of the implementation for the sake of an ambiguous-but-human-intuitive syntax. @@l:\ce{^{238}U}@@ is not so bad, nor is {{{ce(^{238)U)}}} with a properly defined macro template. Anyway, let me stress it again: a change to macro syntax is fine if it introduces no ambiguity. Obviously, the same holds for sub/superscript. To resolve this dilemma, we need a formal (mathematically rigorous) org syntex specification, like the rules drafted in http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments together with a set of test suites to demonstrate the spec. There would be a lot of work, but we could start from embedded LaTeX fragments and super(sub)scripts/underline. It might be mentally overwhelming for one single guy to do the spec and the implementation at the same time, because they require different mindsets. The spec is long term and should be stable while the implementation is always being optimized. After all, it is considered good practice to make the two processes independent to each other. I'm not sure what do you mean. org-syntax.html describes, well, the syntax (although it could be better, with, e.g., EBNF, help is welcome), org-element.el implements it, with optimizations, and test-org-element.el tests the implementation. Anyway, let's concentrate on LaTeX macros. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] curly nested latex fragments
Hi Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: hero...@gentoo.org writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I do not mind extending syntax for LaTeX macros a bit if it helps users, but first, I would like a clear definition of what subset of macros should be supported in Org. See, for example, http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments \ce{^{238}U} falls into \NAME POST, doesn't it? Sorry I wasn't clear. I suggested to not use a regexp to describe the syntax, as regular expressions may not be sufficient to describe the object. Try to use something like the link above. Also, bear in mind that a complicated regexp slows down parsing. Wow that's exactly what I was wondering when reading org-element--parse-{elements,objects}. It is a tokenizer in lexical analysis, for which great tools exist for decades. Ha, I don't even aware of ... syntex as a part of the LaTeX macro; I just copied the regex from org-latex.el. So let's strip it out, and advise the users to use explicit LaTeX block for ... constructs. + (looking-at (concat + \\([a-zA-Z]+\\*?\\) + \\(?:\\[[^][\n]*?\\]\\)* + \\( (org-create-multibrace-regexp { } 3) \\)\\{1,3\\})) Unfortunately, this is ambiguous with Org macro syntax. For example, it would match: \alpha{{{macro(arg)}}} which is an entity followed by a macro. Err, insert a white space? \alpha {{{macro(arg)}}} Or expand the macro before latex-or-entity matching. Do you mean this[2] and this[3] threads? I've read them through, and remotely understood the difficulty coming from the ambiguity of the syntax. And as discussed above, the difficulty manifests in the definition of LaTeX fragments, too. There is no ambiguity in LaTeX fragments, as Org is not required to support full raw LaTeX syntax (and never did anyway), as long as we provide markup to insert LaTeX in the buffer anyway. If we can support a bit more without introducing corner cases, that's fine. But, as you say, that's just syntactic sugar, so pure Org syntax goes first. I agree with you on this. At the same time, these syntax sugar is great. And that's the reason why we prefer org-mode in composing LaTeX to pristine LaTeX. There is a sincere need to compromise the cleanness of the implementation for the sake of an ambiguous-but-human-intuitive syntax. @@l:\ce{^{238}U}@@ is not so bad, nor is {{{ce(^{238)U)}}} with a properly defined macro template. Anyway, let me stress it again: a change to macro syntax is fine if it introduces no ambiguity. Obviously, the same holds for sub/superscript. Hmmm, after reflection, my preference of \ce{^{238}U} comes from the syntax of org-mode 7.9. To resolve this dilemma, we need a formal (mathematically rigorous) org syntex specification, like the rules drafted in http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments together with a set of test suites to demonstrate the spec. There would be a lot of work, but we could start from embedded LaTeX fragments and super(sub)scripts/underline. It might be mentally overwhelming for one single guy to do the spec and the implementation at the same time, because they require different mindsets. The spec is long term and should be stable while the implementation is always being optimized. After all, it is considered good practice to make the two processes independent to each other. I'm not sure what do you mean. org-syntax.html describes, well, the syntax (although it could be better, with, e.g., EBNF, help is welcome), org-element.el implements it, with optimizations, and test-org-element.el tests the implementation. Sorry, it's my ignorance. I didn't notice the tests/ dir. So great that the testing framework is already there. Anyway, let's concentrate on LaTeX macros. Okay. Cheers, Benda
Re: [O] [PATCH] curly nested latex fragments
Hello, hero...@gentoo.org writes: Nesting braces is already implemented in the classic org-latex.el[1], and is forward ported into org-element.el. Thanks for your patch. I think you are misunderstanding something. I didn't port this limitation in Org 8. AFAIK it has been there for a long time. See `org-inside-latex-macro-p' for example. The main problem with Org 8 is that every exporter implemented its own parser for the Org buffer. As you can see, org-latex.el was in contradiction with org.el. Would you like to take a look at the attached patch? Thanks. I do not mind extending syntax for LaTeX macros a bit if it helps users, but first, I would like a clear definition of what subset of macros should be supported in Org. See, for example, http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments Also, I do not want to add constructs like \\(?:[^\n]*\\)* in this definition, as this isn't supported even in `TeX-find-macro-end-helper' (from auctex), which I consider as a reference for macro syntax (i.e. we shouldn't support more than what is supports). Eventually, please note that this imply to change not only org-element.el, but also org.el and possibly other parts where the limitation is encoded. But first, we need to agree on what exactly a valid a LaTeX macro is in Org. If \ce{^2H} works as above, it is not a problem for me. Although make it configurable is more user-friendly; ^:{} is already there afterall, adding another style feels natural. It's not about adding another style. ^:{} allows less (without changing syntax, because the limitation is done at the export level), you want to allow more, which implies to change syntax. I don't want the latter to be configurable. I explained in this thread why it wasn't possible, for the time being, to allow a blank character before sub or superscript. This was discussed on this ML, you may want to search archives. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] curly nested latex fragments
Hi Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, hero...@gentoo.org writes: Nesting braces is already implemented in the classic org-latex.el[1], and is forward ported into org-element.el. Thanks for your patch. I think you are misunderstanding something. I didn't port this limitation in Org 8. AFAIK it has been there for a long time. See `org-inside-latex-macro-p' for example. The main problem with Org 8 is that every exporter implemented its own parser for the Org buffer. As you can see, org-latex.el was in contradiction with org.el. I see, the regex used for latex protection (in org-latex.el) and footnote guarding (org-footnotes.el org.el) are different. Would you like to take a look at the attached patch? Thanks. I do not mind extending syntax for LaTeX macros a bit if it helps users, but first, I would like a clear definition of what subset of macros should be supported in Org. See, for example, http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments \ce{^{238}U} falls into \NAME POST, doesn't it? Also, I do not want to add constructs like \\(?:[^\n]*\\)* in this definition, as this isn't supported even in `TeX-find-macro-end-helper' (from auctex), which I consider as a reference for macro syntax (i.e. we shouldn't support more than what is supports). Ha, I don't even aware of ... syntex as a part of the LaTeX macro; I just copied the regex from org-latex.el. So let's strip it out, and advise the users to use explicit LaTeX block for ... constructs. + (looking-at (concat + \\([a-zA-Z]+\\*?\\) + \\(?:\\[[^][\n]*?\\]\\)* + \\( (org-create-multibrace-regexp { } 3) \\)\\{1,3\\})) Eventually, please note that this imply to change not only org-element.el, but also org.el and possibly other parts where the limitation is encoded. But first, we need to agree on what exactly a valid a LaTeX macro is in Org. `org-inside-latex-macro-p' for example? Yeah, definitely. If \ce{^2H} works as above, it is not a problem for me. Although make it configurable is more user-friendly; ^:{} is already there afterall, adding another style feels natural. It's not about adding another style. ^:{} allows less (without changing syntax, because the limitation is done at the export level), you want to allow more, which implies to change syntax. I don't want the latter to be configurable. I explained in this thread why it wasn't possible, for the time being, to allow a blank character before sub or superscript. This was discussed on this ML, you may want to search archives. Do you mean this[2] and this[3] threads? I've read them through, and remotely understood the difficulty coming from the ambiguity of the syntax. And as discussed above, the difficulty manifests in the definition of LaTeX fragments, too. It is frustrating to deal with these corner cases, making a well-designed parser framework unnecessary complex. At the same time, these syntax sugar is great. And that's the reason why we prefer org-mode in composing LaTeX to pristine LaTeX. There is a sincere need to compromise the cleanness of the implementation for the sake of an ambiguous-but-human-intuitive syntax. To resolve this dilemma, we need a formal (mathematically rigorous) org syntex specification, like the rules drafted in http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments together with a set of test suites to demonstrate the spec. There would be a lot of work, but we could start from embedded LaTeX fragments and super(sub)scripts/underline. It might be mentally overwhelming for one single guy to do the spec and the implementation at the same time, because they require different mindsets. The spec is long term and should be stable while the implementation is always being optimized. After all, it is considered good practice to make the two processes independent to each other. What do you think? Yours, Benda 1. http://orgmode.org/w/?p=org-mode.git;a=commit;h=88cf58802cc35dee2bc8ff8633b5c842fa7a23b3 2. http://thread.gmane.org/gmane.emacs.orgmode/79735 3. http://thread.gmane.org/gmane.emacs.orgmode/85902