Exzessive newlines in org-element item interpreter?

Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

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?

PS
and checkbox is ignored, no matter if I give 'on, 'off and 'trans as
symbols or strings.

-- 
cheers,
Thorsten

Re: Exzessive newlines in org-element item interpreter?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Nicolas Goaziou <mail@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: Exzessive newlines in org-element item interpreter?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Nicolas Goaziou]

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

Hello,

> Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Nicolas Goaziou]

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Thorsten Jolitz <tjolitz@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

Re: Exzessive newlines in org-element item interpreter?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Nick Dokos]

Thorsten Jolitz <tjolitz@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: Exzessive newlines in org-element item interpreter?

[Thorsten Jolitz]

Nick Dokos <ndokos@gmail.com> writes:

> Thorsten Jolitz <tjolitz@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