Hello, I have noticed a difficulty with :results table drawer babel blocks. It isn’t possible to put ATTR_LATEX keywords on the table in that case. If they are placed outside of the drawer, they apply to the drawer and not the table. If they are placed inside it, they will be deleted when the block is reevaluated. (Drawer results are preferable to raw ones: I have found, under rare conditions, org can get confused about where the boundary of the result is and not replace it properly when reevaluating. Using a drawer avoids this case.) Would it be possible for ATTR_FOO attributes to be inherited by child elements, so that this case would work? It would solve this problem, and also allow things like: #+ATTR_LATEX: :width 200px :DRAWER: # several images, all of which should be 200 px wide :END: I thought I would ask for comments, since this might break other things in ways I’m not thinking of. Thanks, -- Aaron Ecay
Hello, Aaron Ecay <aaronecay@gmail.com> writes: > I have noticed a difficulty with :results table drawer babel blocks. It > isn’t possible to put ATTR_LATEX keywords on the table in that case. If > they are placed outside of the drawer, they apply to the drawer and not > the table. If they are placed inside it, they will be deleted when the > block is reevaluated. What about evaluating it, inserting the attr_latex keyword, and then disabling evaluation for that block? > Would it be possible for ATTR_FOO attributes to be inherited by child > elements, so that this case would work? It would solve this problem, > and also allow things like: > > #+ATTR_LATEX: :width 200px > :DRAWER: > # several images, all of which should be 200 px wide > :END: > > I thought I would ask for comments, since this might break other things > in ways I’m not thinking of. I understand the interest for the problem at hand, but, generally speaking, I tend to think it could lead to confusion. Attributes inheritance is but a hack used to parametrize inline images, until we agree on a proper link syntax including its own attributes. Another way to solve the problem would be to let Babel generate attributes from source code with a specific keyword, e.g.: #+begin_src :results table :attr-latex ":align lll" ... #+end_src Regards, -- Nicolas Goaziou
Hi Nicolas, 2013ko martxoak 21an, Nicolas Goaziou-ek idatzi zuen: > Aaron Ecay <aaronecay@gmail.com> writes: > >> I have noticed a difficulty with :results table drawer babel blocks. It >> isn’t possible to put ATTR_LATEX keywords on the table in that case. If >> they are placed outside of the drawer, they apply to the drawer and not >> the table. If they are placed inside it, they will be deleted when the >> block is reevaluated. > > What about evaluating it, inserting the attr_latex keyword, and then > disabling evaluation for that block? This isn’t a solution, generally speaking. I may be working on a graph in R; I know that I want it to be inserted in the LaTeX output with width 6in, even as I go through several iterations of changing the graph. So, each time I do, either I have to manually re-enter the width, or be resigned to the LaTeX export being “broken” until I am done. (and the same goes for a table, of course) > I understand the interest for the problem at hand, but, generally > speaking, I tend to think it could lead to confusion. > > Attributes inheritance is but a hack used to parametrize inline images, > until we agree on a proper link syntax including its own attributes. Well, this is one specific current use. But the fact that it is a hack doesn’t mean the inheritance approach is inherently hackish. > > Another way to solve the problem would be to let Babel generate > attributes from source code with a specific keyword, e.g.: > > #+begin_src :results table :attr-latex ":align lll" > ... > #+end_src This would lead to long begin_src lines, especially if one wants to export to multiple backends. I think it is much more pleasant to be able to edit several lines: #+ATTR_LaTeX: foo #+ATTR_HTML: bar rather than packing them all into one begin_src line. (But I think I could live with this as a solution, if I had to.) What if attribute inheritance was only implemented for RESULTS drawers? I guess that would look more like a “hack,” but it would avoid interfering with other areas where attribute inheritance might cause confusion. Thanks, -- Aaron Ecay