Re: [RFC] Standardized code block keywords

[Christian Moe <mail@christianmoe.com>]

> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see
> my question about tblname below).

I'll have to change my files, either way. The price one pays for 
inconsistency. But as I've recently learned from Carsten, it should be 
a one-liner in Perl. :-)

For the sake of analogy, I'll cast my vote for SRCNAME, even if SOURCE 
is more aesthetically pleasing.

>
> I agree on [2] "call".

+1

>
> 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)

I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME 
don't?

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.

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.