Re: [O] Exzessive newlines in org-element item interpreter?
Hello, Thorsten Jolitz tjol...@gmail.com writes: ,[ C-h f yes-or-no-p RET ] | yes-or-no-p is an alias for `y-or-n-p'. | | (yes-or-no-p PROMPT) | | Ask user a y or n question. ` = nil The interpreter produces _normalized_ syntax. It ignores indentation, capitalization on keywords and, obviously, specific bullets (which might not be allowed in the target environment). This is a feature. Regards, -- Nicolas Goaziou
Re: [O] Exzessive newlines in org-element item interpreter?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: ,[ C-h f yes-or-no-p RET ] | yes-or-no-p is an alias for `y-or-n-p'. | | (yes-or-no-p PROMPT) | | Ask user a y or n question. ` = nil The interpreter produces _normalized_ syntax. It ignores indentation, capitalization on keywords and, obviously, specific bullets (which might not be allowed in the target environment). This is a feature. Thanks for the answer. I did not mean to point fingers, I just wanted to know if it _can_ be done and I have to investigate further to find out how, or if I can save me the time and effort. PS Your interpretation of 'obvious' seems (obviously?) be a bit overly optimistic sometimes. -- cheers, Thorsten
Re: [O] Exzessive newlines in org-element item interpreter?
Thorsten Jolitz tjol...@gmail.com writes: Your interpretation of 'obvious' seems (obviously?) be a bit overly optimistic sometimes. Probably apocryphal but ... http://mystatpage.wordpress.com/tag/g-h-hardy/ -- Nick
Re: [O] Exzessive newlines in org-element item interpreter?
Nick Dokos ndo...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: Your interpretation of 'obvious' seems (obviously?) be a bit overly optimistic sometimes. Probably apocryphal but ... http://mystatpage.wordpress.com/tag/g-h-hardy/ Nice. Whats really obvious is that spelling errors in Mail Subjects become kind of embarrassing when repeated so often ... -- cheers, Thorsten
Re: [O] Exzessive newlines in org-element item interpreter?
Hello, Thorsten Jolitz tjol...@gmail.com writes: Hi List, evaluating this #+BEGIN_SRC emacs-lisp (org-element-interpret-data '(item (:bullet 1 :tag hello :checkbox trans :counter 2) (section nil world))) #+END_SRC #+results: : 1. [@2] hello :: :world the content is always placed on a newline, which looks strange in my eyes. Is that intended? It is. You include a `section' in an `item', which is syntactically wrong. Only headlines can contain sections. PS and checkbox is ignored, no matter if I give 'on, 'off and 'trans as symbols or strings. You should not provide 'on, 'off or 'trans, and even less strings, but on, off or trans since your expression is already quoted. Regards, -- Nicolas Goaziou
Re: [O] Exzessive newlines in org-element item interpreter?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: Hi List, evaluating this #+BEGIN_SRC emacs-lisp (org-element-interpret-data '(item (:bullet 1 :tag hello :checkbox trans :counter 2) (section nil world))) #+END_SRC #+results: : 1. [@2] hello :: :world the content is always placed on a newline, which looks strange in my eyes. Is that intended? It is. You include a `section' in an `item', which is syntactically wrong. Only headlines can contain sections. I see. So when creating an element with interpreted content (that is given as plain string), I use - headlines :: (section nil foo) - others :: (paragraph nil foo) or should it rather be - headlines :: (section nil (paragraph nil foo)) ? PS and checkbox is ignored, no matter if I give 'on, 'off and 'trans as symbols or strings. You should not provide 'on, 'off or 'trans, and even less strings, but on, off or trans since your expression is already quoted. ups ... of course. One more question: the :tag property of items is parsed as list (of sec. string(s)) - is it sufficient for interpreting to give it a plain string: tag: foo instead of tag: (foo)? It seems to work ... -- cheers, Thorsten
Re: [O] Exzessive newlines in org-element item interpreter?
Thorsten Jolitz tjol...@gmail.com writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: [...] You should not provide 'on, 'off or 'trans, and even less strings, but on, off or trans since your expression is already quoted. One more question: bullet strings are parsed 'as-is', but the interpreter seems to have its own logic that is a bit difficult to grok (or are there syntax errors too?): #+BEGIN_SRC emacs-lisp (org-element-interpret-data '(item (:bullet - :tag hello :checkbox trans :counter 2) (paragraph nil world))) #+END_SRC #+results: : - [@2] [-] hello :: world #+BEGIN_SRC emacs-lisp (org-element-interpret-data '(item (:bullet + :tag hello :checkbox trans :counter 2) (paragraph nil world))) #+END_SRC #+results: : - [@2] [-] hello :: world #+BEGIN_SRC emacs-lisp (setq org-list-allow-alphabetical t) (when (featurep 'org-element) (load org-element t t)) (org-element-interpret-data '(item (:bullet a :tag hello :checkbox trans :counter 2) (paragraph nil world))) #+END_SRC #+results: : 1. [@2] [-] hello :: world -- cheers, Thorsten
Re: [O] Exzessive newlines in org-element item interpreter?
Hello, Thorsten Jolitz tjol...@gmail.com writes: One more question: bullet strings are parsed 'as-is', but the interpreter seems to have its own logic that is a bit difficult to grok (or are there syntax errors too?): This is simple: ordered lists bullets are always X., where X is a number and unordered lists are always -. Regards, -- Nicolas Goaziou
Re: [O] Exzessive newlines in org-element item interpreter?
Thorsten Jolitz tjol...@gmail.com writes: So when creating an element with interpreted content (that is given as plain string), I use - headlines :: (section nil foo) - others :: (paragraph nil foo) If contents are already interpreted, - anything :: foo is sufficient, I think. However, when anything is either item or footnote-definition, and contents start with a paragraph, - anything :: (paragraph nil foo) is better due to special handling of the first line. One more question: the :tag property of items is parsed as list (of sec. string(s)) - is it sufficient for interpreting to give it a plain string: tag: foo instead of tag: (foo)? It seems to work ... (foo) is equivalent to foo. (foo) allows to insert objects, e.g. (foo (bold nil bar)) Regards,
Re: [O] Exzessive newlines in org-element item interpreter?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: One more question: bullet strings are parsed 'as-is', but the interpreter seems to have its own logic that is a bit difficult to grok (or are there syntax errors too?): This is simple: ordered lists bullets are always X., where X is a number and unordered lists are always -. Thx for you answers (to my other post too). Just to get it straight: The conclusion of your answer above is that the item-interpreter cannot produce the complete org-mode syntax for plain-lists that is recognized by the parser and described in the manual? -- cheers, Thorsten
Re: [O] Exzessive newlines in org-element item interpreter?
Thorsten Jolitz tjol...@gmail.com writes: The conclusion of your answer above is that the item-interpreter cannot produce the complete org-mode syntax for plain-lists that is recognized by the parser and described in the manual? This question is too tricky (and closed) for me to answer. Regards,
Re: [O] Exzessive newlines in org-element item interpreter?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Thorsten Jolitz tjol...@gmail.com writes: The conclusion of your answer above is that the item-interpreter cannot produce the complete org-mode syntax for plain-lists that is recognized by the parser and described in the manual? This question is too tricky (and closed) for me to answer. ,[ C-h f yes-or-no-p RET ] | yes-or-no-p is an alias for `y-or-n-p'. | | (yes-or-no-p PROMPT) | | Ask user a y or n question. ` -- cheers, Thorsten
