* RFC: inheritance of export attributes
@ 2013-03-19 5:33 Aaron Ecay
2013-03-21 21:51 ` Nicolas Goaziou
0 siblings, 1 reply; 3+ messages in thread
From: Aaron Ecay @ 2013-03-19 5:33 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: inheritance of export attributes
2013-03-19 5:33 RFC: inheritance of export attributes Aaron Ecay
@ 2013-03-21 21:51 ` Nicolas Goaziou
2013-03-31 23:12 ` Aaron Ecay
0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Goaziou @ 2013-03-21 21:51 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: inheritance of export attributes
2013-03-21 21:51 ` Nicolas Goaziou
@ 2013-03-31 23:12 ` Aaron Ecay
0 siblings, 0 replies; 3+ messages in thread
From: Aaron Ecay @ 2013-03-31 23:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-03-31 23:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-19 5:33 RFC: inheritance of export attributes Aaron Ecay
2013-03-21 21:51 ` Nicolas Goaziou
2013-03-31 23:12 ` Aaron Ecay
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).