[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [RFC] Standardized code block keywords
From: |
Daniel Bausch |
Subject: |
Re: [O] [RFC] Standardized code block keywords |
Date: |
Mon, 24 Oct 2011 07:49:59 +0200 |
User-agent: |
KMail/1.13.7 (Linux/2.6.39-gentoo-r3; KDE/4.6.5; i686; ; ) |
Am Sonntag 23 Oktober 2011, 18:09:01 schrieben Sie:
> Daniel Bausch <address@hidden> writes:
> > Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> >> Eric Schulte <address@hidden> writes:
> >> >>> I'm confused by [3] so I will say nothing for now, except to ask
> >> >>> some questions: are we talking about what a human would use to
> >> >>> label a piece of data for consumption by a block (including perhaps
> >> >>> the future possibilities of lists and paragraphs that Tom brought
> >> >>> up)? what babel would use to label a results block (possibly so
> >> >>> that it could be consumed by another block in a chain)? both? would
> >> >>> that mean that #+tblname would go the way of the dodo and that
> >> >>> tables would be labelled with #+data (or #+object or whatever else
> >> >>> we come up with)?
> >> >>
> >> >> +1 (Confused, too)
> >> >
> >> > well, I guess it is good that this discussion has begun if only to
> >> > clear up this lingering uncertainty.
> >> >
> >> >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and
> >> >> SRCNAME don't?
> >> >
> >> > from the prospective of code blocks it is exactly synonymous with
> >> > tblname. Srcname is different in that it labels code blocks.
> >> >
> >> >> A reason to keep TBLNAME is that it's also used by the spreadsheet
> >> >> remote references. If Babel looked for DATA instead, a table that is
> >> >> both a remote reference for another spreadsheet and a data source for
> >> >> a src block would need both TBLNAME and DATA, which seems redundant.
> >> >
> >> > agreed, I'm thinking that tblname will at least remain an option no
> >> > matter what decision is made.
> >> >
> >> >> As for labeling lists and paragraphs, I recall from the list that
> >> >> Nicolas Goaziou is working on a generalized way to set captions,
> >> >> labels and attributes for various kinds of Org block, as is possible
> >> >> now for tables and images. I thought that sounded promising. I don't
> >> >> know if he planned for block names, too (currently we have tblname
> >> >> but no imgname), but that could make sense. In which case it might
> >> >> be a good idea to coordinate.
> >> >
> >> > Agreed, I was not aware of this work. Thanks for sharing. In this
> >> > vein I would like to voice my desire to be able to add captions to
> >> > code blocks, the lack of this feature has bitten me in the past.
> >>
> >> Hi Eric,
> >>
> >> For LaTeX export, the listings package has support for code block
> >> captions.
> >
> > Not in org AFAIK, org only supports these for my use cases not very
> > useful "function name = " exports. I patched org to produce real
> > captions instead, but my changes are not that well tested and required
> > some changes in the central export logic. If there is interest I could
> > share what I have so far. The code quality is a mess, as I do not really
> > know elisp.
> >
> > Daniel
>
> Yes, source code block captions currently have to be handled outside the
> usual Org-mode mechanism. If you use org-special-blocks and the
> listings package, then the following template will give you floating
> code block listings with captions in LaTeX export.
>
> : #+BEGIN_listing
> :
> : <source block>
> :
> : #+LATEX: \caption[The short caption]{The long caption.}\ref{fig:src_blk}
> : #+END_listing
>
> This doesn't do anything for export to other formats, but it works well
> for LaTeX export. There is even \listoflistings command to produce a
> list of source code listings in the front matter.
>
> All the best,
> Tom
Thank you for this hint, but with my patches, I'm able to write
#+caption: A Code Snippet
#+label: lst:xyz
#+begin_src lang
#+end_src
What I'd like to add, is that the listings implementation in org has a bug,
which I also fixed. If you mix #+begin_src and #+begin_example blocks in one
document, then the #+begin_example blocks are syntax highlighted analog to the
previous #+begin_src block because the language is selected by \lstset.
In my patches I'm using the 'language' attribute of \begin{lstlisting}, which
does not affect following blocks that do not have this attribute.
I have attached my patch. I suspect that there might be a bug in it, that
disables that tables that have #+attr_latex can be used by babel using
#+tblname, because I observed such a behavior recently. It is possible that
this second defect might origin from somewhere else, too.
Daniel
org-exp_caption.patch
Description: Text Data
- Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines, (continued)
- Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines, Nick Dokos, 2011/10/20
- Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines, Sebastien Vauban, 2011/10/20
- [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/20
- Re: [O] [RFC] Standardized code block keywords, Thomas S. Dye, 2011/10/20
- Re: [O] [RFC] Standardized code block keywords, Nick Dokos, 2011/10/20
- Re: [O] [RFC] Standardized code block keywords, Christian Moe, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Thomas S. Dye, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Daniel Bausch, 2011/10/23
- Re: [O] [RFC] Standardized code block keywords, Thomas S. Dye, 2011/10/23
- Re: [O] [RFC] Standardized code block keywords,
Daniel Bausch <=
- Re: [O] [RFC] Standardized code block keywords, Sebastien Vauban, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Sebastien Vauban, 2011/10/21
- Message not available
- Re: [O] [RFC] Standardized code block keywords, Rainer M Krug, 2011/10/25
- Re: [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Thomas S. Dye, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Eric Schulte, 2011/10/22
- Re: [O] [RFC] Standardized code block keywords, Torsten Wagner, 2011/10/21
- Re: [O] [RFC] Standardized code block keywords, Sebastien Vauban, 2011/10/21