From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Bausch <DanielBausch@gmx.de>
Subject: Re: [RFC] Standardized code block keywords
Date: Tue, 25 Oct 2011 09:14:28 +0200
Message-ID: <201110250914.29233.DanielBausch@gmx.de>
References: <87pqhrih3s.fsf@gmail.com> <80obx6vniu.fsf@somewhere.org>
	<87vcrdyfhy.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([140.186.70.92]:51840)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <DanielBausch@gmx.de>) id 1RIbDX-0004YJ-Ub
	for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:14:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <DanielBausch@gmx.de>) id 1RIbDW-00029F-9Q
	for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:14:35 -0400
Received: from mailout-de.gmx.net ([213.165.64.23]:34225)
	by eggs.gnu.org with smtp (Exim 4.71)
	(envelope-from <DanielBausch@gmx.de>) id 1RIbDV-000291-TM
	for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:14:34 -0400
In-Reply-To: <87vcrdyfhy.fsf@gmail.com>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: emacs-orgmode@gnu.org
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>

Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte:
> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
> > Hi Daniel,
> > 
> > Daniel Bausch wrote:
> >>>          named code blocks [1] -- "source" "srcname" "function"
> >>> 
> >>> calling external functions [2] -- "call" "lob"
> >>> 
> >>>                 named data [3] -- "tblname" "resname" "results" "data"
> >> 
> >> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
> >> 
> >> That a table or list contains data is obvious.  The only thing, the
> >> additional line is for, is to "name" it.
> > 
> > As Eric showed us, this is not always to name it... If the table is the
> > results of an unamed block, you will have #+name: followed by no name!
> > 
> > #+name:
> > | line 1 | data1 |
> > | line 2 | data2 |
> > 
> > what I also find quite disturbing.
> 
> I also find this to be disconcerting. -- Eric
> 
> > Best regards,
> > 
> >   Seb

Then maybe #+results for (anonymous) results only, but #+name for anything 
else from [1] and [3].  Wasn't there a concept of linking a results block to 
its originiating source block by some id and we need a place to put the 
checksum in.  So I see some arguments for treating results special.  But for 
the others I do not see pressing arguments against a common "name" at the 
moment.  However, I'd like to ask, what happens, if one refers to a name of a 
source block where data is expected, does it then refer to the results 
produced by that source block?  How are such situations handeled at the 
moment?  In other words: is there any type checking?  Type checking could be 
facilitated by using different words, although I think that is not neccessary, 
because there are other means to distinguish the type of a block (look at the 
next line in the buffer).

Daniel