[O] comments and attributes

[Jambunathan K]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Jambunathan K kjambunat...@gmail.com writes:

 Does the existing behaviour as captured in [[Side-by-Side images laid
 out by hand]] be preserved with new export driver?

 I'm not sure to get the syntax right, but in the new exporter, you can
 see what is the next or previous element, along with its
 properties. Thus, you can detect when two paragraphs are back to back,
 if they have appropriate :attr_latex properties and if they are enclosed
 in a parent center-block element.

 The check could be done at the paragraph level, and, if positive,
 org-odt-paragraph could return the draw:fram
 draw:style.../draw:frame string.

 Am I missing something?

On a related note,

--8---cut here---start-8---
* Example

This 
is 
a
single
# some comment
paragraph.


This 
is 
another
#+attr_odt: t
paragraph.
--8---cut here---end---8---

if I parse the above buffer, I get

#+begin_src emacs-lisp
  (paragraph
   (:begin 412 :end 431 :contents-begin 412 :contents-end 430 :post-blank 0)
   This \nis \na\nsingle)
  (comment
   (:begin 431 :end 446 :value # some comment\n :post-blank 0))
  (paragraph
   (:begin 446 :end 459 :contents-begin 446 :contents-end 456 :post-blank 2)
   paragraph.)
  (paragraph
   (:begin 459 :end 477 :contents-begin 459 :contents-end 476 :post-blank 0)
   This \nis \nanother)
  (paragraph
   (:begin 477 :end 502 :contents-begin 491 :contents-end 501 :post-blank 0 
:attr_odt
  (t))
   paragraph.)
#+end_src

I see that the new export engine treats comment and control lines as par
breakers. The backends that are in production treats the first paragraph
as but a single paragraph.

There is already a way by which parbreaks can be introduced. Do you
think there could be some useful behaviour achieved - side by side
export of images came up in this thread - by not having commented
elements introduce parbreaks.

I am only brainstorming here. I hope the examples and use-case taken up
here help steer our discussion in a meaningful manner.

 Regards,

Re: [O] comments and attributes

[Nicolas Goaziou]

Hello,

Jambunathan K kjambunat...@gmail.com writes:

 On a related note,

 * Example

 This 
 is 
 a
 single
 # some comment
 paragraph.


 This 
 is 
 another
 #+attr_odt: t
 paragraph.

 if I parse the above buffer, I get

 #+begin_src emacs-lisp
   (paragraph
(:begin 412 :end 431 :contents-begin 412 :contents-end 430 :post-blank 0)
This \nis \na\nsingle)
   (comment
(:begin 431 :end 446 :value # some comment\n :post-blank 0))
   (paragraph
(:begin 446 :end 459 :contents-begin 446 :contents-end 456 :post-blank 2)
paragraph.)
   (paragraph
(:begin 459 :end 477 :contents-begin 459 :contents-end 476 :post-blank 0)
This \nis \nanother)
   (paragraph
(:begin 477 :end 502 :contents-begin 491 :contents-end 501 :post-blank 0 
 :attr_odt
   (t))
paragraph.)
 #+end_src

 I see that the new export engine treats comment and control lines as par
 breakers. The backends that are in production treats the first paragraph
 as but a single paragraph.

Not the export engine, but the parser. Comment is an element type, as is
Paragraph. Beginning an element ends the previous one.

This has always been true in Org. For example, you may look at
`paragraph-start' and `paragraph-separate' values in an Org buffer:
comments (and many other things) are clearly separating and ending
paragraphs.

Also, it is consistent with other elements. Indeed, consider the
following example:

--8---cut here---start-8---
: fixed-width line 1
# Commented line
: fixed-width line 2
--8---cut here---end---8---

If you use C-c ' on the first fixed-width line, you won't be offered to
edit also the second one.

Though, you're right, current exporter indeed ignores that Org feature.

 There is already a way by which parbreaks can be introduced. Do you
 think there could be some useful behaviour achieved - side by side
 export of images came up in this thread - by not having commented
 elements introduce parbreaks.

I think that it's a mistake to rely on comments to define semantics.

Anyway, I suggested something already about the problem of side by side
paragraphs. What was wrong with it? If it wasn't clear, I'll try to
provide an example. If it was flawed, we may try to improve it.


Regards,

-- 
Nicolas Goaziou