Am Sonntag 23 Oktober 2011, 18:09:01 schrieben Sie:
> Daniel Bausch <DanielBausch@gmx.de> writes:
> > Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> >> Eric Schulte <schulte.eric@gmail.com> 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