emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rainer M Krug <r.m.krug@gmail.com>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Standardized code block keywords
Date: Tue, 25 Oct 2011 08:59:37 +0200	[thread overview]
Message-ID: <CAGhLh6GW3jRJzEKLwXLVLxR8Cvvo_3jdpXt_dZNsj3JuN05QYQ@mail.gmail.com> (raw)
In-Reply-To: <CAGhLh6GXg6nMZ-xdu-EP=YRx7Pznrme2Yq1S0vdc6Yq0tPMxFg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7269 bytes --]

On Tue, Oct 25, 2011 at 8:52 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Sebastien Vauban <
> wxhgmqzgwmuf@spammotel.com> wrote:
>
>> Hi Eric,
>>
>> Eric Schulte wrote:
>> >> Now, between "srcname" and "source": I'm used to whatever my Yasnippet
>> is
>> >> entering for me. That's currently "srcname". I don't have a strong
>> opinion,
>> >> though, to choose one over the other, except that I like Nick's
>> argument with
>> >> the table analogy.
>> >>
>> >>> I agree on [2] "call".
>> >>
>> >> I clearly agree on "call" as well.
>> >
>> > noted, thanks
>>
>> I think you'll get unanimity on that one.
>>
>> >> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's
>> a
>> >> call, absolutely similar to "call". Is there a technical reason to be
>> forced
>> >> to differentiate both?  If no, can we use "call" as well instead of
>> "sbe"?
>> >
>> > The only difference is that sbe is a function name, and to name a
>> > function call (a function which will take up that term in the entire
>> > Emacs-lisp namespace across all applications) seems somewhat pushy.
>>
>> OK. Point understood. May I suggest to try to find a better name, still?
>>  Once
>> we're at it, modifying one extra line in the documentation won't hurt.
>>
>> I don't know what others find, but I've never understood what it meant.
>> OK,
>> now (since yesterday, in fact), I know it means "source block evaluation",
>> but
>> that's not really intuitive.
>>
>> I'd opt for "ob-call" (package name + "call") or something like that, if I
>> could choose.
>>
>> >>> 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)?
>> >>
>> >> For point 3, Eric, I guess that whichever term is chosen, that does not
>> mean
>> >> that "results" will change (I mean: when it's a result of a block
>> execution)?
>>
>> I was expecting you'd always keep "results" for auto-inserted results
>> (after a
>> code block evaluation). But it makes sense to prefer the one term that
>> will
>> win.
>>
>
> I would definitely keep #+results as this marks it as an *output* which can
> change during the next evaluation, and not an input, which has to be
> modified by hand. I would actually go so far and say that #+results *can be*
> src or object (using these terms), but is in itself *not* identifying
> anything, apart from "this is the result of an evaluation". So:
>
> #+results
> #+object_begin
>  .
>  .
>  .
> #+end
>
> would be the result of an evaluation.
>
> One could even, for clarities sake, say that
>
> #+object
>
> if no #+results is in the line before,
>
> is a synonym for
>
> #+input (or #+constant)
> #+object_begin
>  .
>  .
>  .
> #+end
>
> Cheers,
>
> Rainer
>
>
>> > I would be happy for results to change to data or tblname (if a table)
>> > or whatever else is selected.
>>
>> OK, clear.
>>
>> >> In other words, if we choose for "object", we still will have the
>> possibility
>> >> to use "results" (automatically generated) and "object" to refer to
>> something
>> >> we want to use in another call?
>> >>
>> >>>>>                 named data [3] -- "tblname" "resname" "results"
>> "data"
>> >>
>> >> I don't specifically like "resname".
>> >>
>> >> I would keep "results" for automatically generated "results".
>> >>
>> >> I do like "data", but can learn to like "object" as a more generic
>> term,
>> >> future-proof for coming extensions.
>> >
>> > I'll mark you down as undecided for this term. :)
>>
>> Yep!  I'm open to any suggestion you'll make.
>>
>> >> Last remark: we could get one step further and wonder if it wouldn't be
>> good
>> >> to impose a single way to pass variables? We currently have two
>> different
>> >> mechanisms:
>> >>
>> >>     #+srcname: convert-date-to-French-format
>> >>     #+begin_src sql :var column=""
>> >>     CONVERT(varchar(10), $column, 103) AS $column
>> >>     #+end_src
>> >>
>> >> and
>> >>
>> >>     #+srcname: convert-date-to-French-format(column="")
>> >>     #+begin_src sql
>> >>     CONVERT(varchar(10), $column, 103) AS $column
>> >>     #+end_src
>> >>
>> >> I guess that the first one is easier if we want to construct complex
>> variable
>> >> values (which call Emacs Lisp code or such), but...
>> >
>> > I don't feel that this example causes as much confusion, but if I'm
>> > wrong I am open to change on this front.  Although the only possible
>> > change here would be to remove the second option as the first method of
>> > specifying variables is central to code block management.
>>
>> Just that I remember both syntaxes weren't handled the same way for error
>> reporting (remember, when there is no default value: in one case, you can
>> get
>> the name of the faulty block; in the other, not), and that makes me think
>> is
>> not as simple as an alias. Hence, your Babel code is or can become
>> different
>> just because there are different alternatives to write certain things
>> down.
>>
>> Then, as a user, I always wonder what's the best one?  "For a good error
>> reporting (with the name of the code block being outputted), which one do
>> I
>> have to use?" and such questions...
>>
>> If we only have one way, we can be sure everybody experiences the same
>> things
>> with the same semantical input.
>>
>> Another point, that may or may not have much to do with this, is that I
>> don't
>> have anymore the source name exported in HTML -- dunno when it
>> disappeared,
>> though. I remember that, at some point, it was due to having, or not, a
>> default value (at the time, having no default value was still allowed),
>> but
>> now, even with the default values for every var, I miss those names in the
>> HTML (for literate programming support, it is quite useful to be able to
>> see
>> the name of the block along with the code).
>>
>> I repeat myself, but thanks, once again, for tackling this naming
>> "problem".
>>
>> Best regards,
>>  Seb
>>
>> --
>> Sebastien Vauban
>>
>>
>>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax (F):       +33 - (0)9 58 10 27 44
>
> Fax (D):    +49 - (0)3 21 21 25 22 44
>
> email:      Rainer@krugs.de
>
> Skype:      RMkrug
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 9790 bytes --]

  parent reply	other threads:[~2011-10-25  6:59 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-20 19:43 [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Eric Schulte
2011-10-20 20:06 ` Nick Dokos
2011-10-20 20:12   ` Eric Schulte
2011-10-20 20:51     ` Nick Dokos
2011-10-20 21:04       ` Sebastien Vauban
2011-10-20 21:50         ` [RFC] Standardized code block keywords Eric Schulte
2011-10-21  1:52           ` Thomas S. Dye
2011-10-21  2:57             ` Nick Dokos
2011-10-21  7:26               ` Christian Moe
2011-10-21 16:12                 ` Eric Schulte
2011-10-21 19:10                   ` Thomas S. Dye
2011-10-23 12:20                     ` Daniel Bausch
2011-10-23 16:09                       ` Thomas S. Dye
2011-10-24  5:49                         ` Daniel Bausch
2011-10-21  8:17               ` Sebastien Vauban
2011-10-21 16:17                 ` Eric Schulte
2011-10-21 17:37                   ` Sebastien Vauban
     [not found]                     ` <CAGhLh6GXg6nMZ-xdu-EP=YRx7Pznrme2Yq1S0vdc6Yq0tPMxFg@mail.gmail.com>
2011-10-25  6:59                       ` Rainer M Krug [this message]
2011-10-21 16:08               ` Eric Schulte
2011-10-21 16:05             ` Eric Schulte
2011-10-21 18:02               ` Thomas S. Dye
2011-10-22 15:19                 ` Eric Schulte
2011-10-21  7:43           ` Torsten Wagner
2011-10-21  8:27             ` Sebastien Vauban
2011-10-21 16:25               ` Eric Schulte
2011-10-21 16:24             ` Eric Schulte
2011-10-21 17:41               ` Sebastien Vauban
2011-10-24  1:06                 ` Torsten Wagner
2011-10-25  6:44               ` Rainer M Krug
2011-10-25  7:24                 ` Jambunathan K
2011-10-25  8:21                 ` Sebastien Vauban
2011-10-21 12:22           ` Nicolas Goaziou
2011-10-21 16:27             ` Eric Schulte
2011-10-21 17:48               ` Eric Schulte
2011-10-21 19:24                 ` Viktor Rosenfeld
2011-10-23 12:42                 ` Daniel Bausch
2011-10-24  7:37                   ` Eric S Fraga
2011-10-24 14:39                     ` Darlan Cavalcante Moreira
2011-10-24  7:47                   ` Sebastien Vauban
2011-10-25  1:30                     ` Eric Schulte
2011-10-25  7:14                       ` Daniel Bausch
2011-10-25  8:14                         ` Sebastien Vauban
2011-10-25 14:44                           ` Eric Schulte
2011-10-25 15:38                             ` Christian Moe
2011-10-25 15:42                             ` Nick Dokos
2011-10-25 16:28                               ` Martyn Jago
2011-10-25 16:49                                 ` Eric Schulte
2011-10-25 17:21                                   ` Nick Dokos
2011-10-26  5:58                                     ` Daniel Bausch
2011-10-26 13:10                               ` Giovanni Ridolfi
2011-10-26 14:41                                 ` Daniel Bausch
2011-10-26 15:04                                   ` Nick Dokos
2011-10-27  5:25                                     ` Daniel Bausch
2011-10-28 16:49                                       ` Eric Schulte
2011-10-28 18:31                                         ` Eric Schulte
2011-10-28 18:40                                           ` Nick Dokos
2011-10-28 18:52                                             ` Eric Schulte
2011-10-28 23:22                                               ` Nick Dokos
2011-10-28 23:39                                                 ` Thomas S. Dye
2011-10-29  2:18                                                   ` Nick Dokos
2011-10-31  7:25                                               ` Daniel Bausch
2011-10-31 19:01                                                 ` Eric Schulte
2011-11-01  6:34                                                   ` C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords) Daniel Bausch
2011-10-25 14:17                         ` [RFC] Standardized code block keywords Eric Schulte
2011-10-26  5:41                           ` Daniel Bausch
2011-10-26  6:17                             ` Thomas S. Dye
2011-10-26 12:16                             ` Eric Schulte
2011-10-21 18:14           ` Thorsten
2011-10-20 21:34       ` [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Eric Schulte
2011-10-20 21:44         ` suvayu ali
2011-10-20 21:52           ` Eric Schulte
2011-10-20 22:23             ` Suvayu Ali
2011-10-20 21:47         ` Sebastien Vauban
2011-10-20 21:54           ` Eric Schulte
2011-10-20 21:57           ` Nick Dokos
2011-10-20 21:48         ` Nick Dokos
2011-10-20 21:57           ` Eric Schulte
2011-10-20 22:08             ` Nick Dokos
2011-10-20 22:18               ` Eric Schulte
2011-10-21  7:28                 ` Sebastien Vauban
2011-10-21  8:14                   ` Christian Moe
2011-10-21  9:12                     ` Rainer M Krug
2011-10-21 10:47                       ` Christian Moe
2011-10-21 10:59                         ` Rainer M Krug
2011-10-21 11:17                           ` Christian Moe
2011-10-21 11:18                             ` Rainer M Krug
2011-10-21 17:37                     ` Eric Schulte
2011-10-21 18:09                       ` Nick Dokos
2011-10-22 15:25                         ` Eric Schulte
2011-10-21 18:35                       ` Rainer M Krug
2011-10-21 18:40                         ` Rainer M Krug
2011-10-22  7:58                           ` Christian Moe
2011-10-24  9:44                             ` Rainer M Krug
2011-10-22 15:52                           ` Eric Schulte
2011-10-22 19:07                             ` Christian Moe
2011-10-24 10:10                               ` Rainer M Krug
2011-10-24 11:37                                 ` Christian Moe
2011-10-24 12:11                                   ` Sebastien Vauban
2011-10-24 12:38                                     ` Christian Moe
2011-10-24 15:07                                       ` Nicolas Goaziou
2011-10-24  9:50                             ` Rainer M Krug
2011-10-25  9:35                             ` Sebastien Vauban
2011-10-25 10:06                               ` Rainer M Krug
2011-10-25 10:31                                 ` Sebastien Vauban
2011-10-25 11:47                                   ` Rainer M Krug
2011-10-25 14:13                               ` Eric Schulte
2011-10-26 14:00                                 ` Sebastien Vauban
2011-10-26 15:20                                   ` Eric Schulte
2011-10-22 15:26                         ` Eric Schulte
2011-10-21 20:24                       ` Christian Moe
2011-10-21 21:05                         ` Darlan Cavalcante Moreira
2011-10-22  7:08                           ` Sebastien Vauban
2011-10-22 15:53                           ` Eric Schulte
2011-10-24 18:07                             ` Darlan Cavalcante Moreira
2011-10-31 18:53                               ` Eric Schulte
2011-10-31 20:18                                 ` Samuel Wales
     [not found]                                   ` <87obwwkia5.fsf@gmail.com>
     [not found]                                     ` <CAJcAo8scJXx=3s0f_FDAJXFKW2uh5gFTHwgDRbM6xXohr5ZPzQ@mail.gmail.com>
2011-10-31 22:22                                       ` Samuel Wales
2011-11-01  1:28                                         ` Eric Schulte
2011-11-01 14:26                                           ` Nick Dokos
2011-11-01 15:02                                             ` Nick Dokos
2011-11-01 15:17                                               ` Eric Schulte
2011-11-02 11:12                                                 ` Rainer M Krug
2011-11-02 12:18                                                   ` Nicolas Goaziou
2011-11-02 14:16                                                     ` Rainer M Krug
2011-11-03 18:40                                                   ` Eric Schulte
2011-11-03 18:51                                                     ` Jambunathan K
2011-11-04  9:15                                                       ` Rainer M Krug
2011-11-02 12:57                                                 ` Brian Wightman
2011-11-02 14:18                                                   ` Rainer M Krug
2011-11-03  1:29                                                   ` Bastien
2011-10-20 21:27     ` Christian Moe
2011-10-20 21:32       ` Nick Dokos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGhLh6GW3jRJzEKLwXLVLxR8Cvvo_3jdpXt_dZNsj3JuN05QYQ@mail.gmail.com \
    --to=r.m.krug@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).