* org-babel feature request
@ 2009-10-11 1:23 Maurizio Vitale
2009-10-11 2:45 ` Dan Davison
0 siblings, 1 reply; 5+ messages in thread
From: Maurizio Vitale @ 2009-10-11 1:23 UTC (permalink / raw)
To: emacs-orgmode
Thanks for the work on org-babel.
I'm not sure the following is even mature enough in my mind to qualify
it as a feature request. Maybe in the end it might be replaced by some
other functionality that subsume it.
But here's the scenario: I'd like to use org-babel for documenting the
configuration and setup of my computing infrastructure. Up to now I've
done it w/ plain org-mode, but having the documents being executable
would be very nice.
As a manner of example, let's take a fragment from my backup
infrastructure:
#+srcname: amanda_config_info
#+begin_src sh
for v in CLIENT_LOGIN CONFIG_DIR AMANDA_DBGDIR libexecdir listed_incr_dir; do
echo -n $v
sudo -u backup /usr/local/amanda/sbin/amadmin xx version|perl -ne "s,^.*\b$v=\"([^\"]+)\".*$, \1,g && print"
done
#+end_src
#+resname: amanda_config_info
| "CLIENT_LOGIN" | "backup" |
| "CONFIG_DIR" | "/usr/local/amanda/etc/amanda" |
| "AMANDA_DBGDIR" | "/tmp/amanda" |
| "libexecdir" | "/usr/local/amanda/libexec" |
| "listed_incr_dir" | "/usr/local/amanda/var/amanda/gnutar-lists" |
It would be nice if it was possible to have multiple result
sections. This way I could embed in the document the result that was
obtained when writing the documentation, while still allowing the person
following the recipe to evaluate again the shell script and get the
results on his machine.
The first section should be read-only (not necessarily physically
read-only, but skipped by C-c C-c). The others may be re-evaluated over
and over until the end user has a valid configuration.
I'm not sure whether there's something more general than this, like
attaching tags (that could be even elisp function) to result sections
that do different things, one of which being enabling the section to
receive results.
Ok, I'm just bouncing ideas in case others see something useful. I've
just started using org-babel and maybe I'll see different ways for
achieving this.
Thanks again for org-babel,
Maurizio
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: org-babel feature request
2009-10-11 1:23 org-babel feature request Maurizio Vitale
@ 2009-10-11 2:45 ` Dan Davison
2009-10-11 3:01 ` Maurizio Vitale
0 siblings, 1 reply; 5+ messages in thread
From: Dan Davison @ 2009-10-11 2:45 UTC (permalink / raw)
To: maurizio.vitale; +Cc: emacs-orgmode
Maurizio Vitale
<mav@cuma.i-did-not-set--mail-host-address--so-tickle-me> writes:
[...]
> It would be nice if it was possible to have multiple result
> sections. This way I could embed in the document the result that was
> obtained when writing the documentation, while still allowing the person
> following the recipe to evaluate again the shell script and get the
> results on his machine.
>
> The first section should be read-only (not necessarily physically
> read-only, but skipped by C-c C-c). The others may be re-evaluated over
> and over until the end user has a valid configuration.
Hi Maurizio,
Once I've obtained the results that I want to "freeze", I would manually
alter (or even delete) the #+resname tag, so that the source block no
longer overwrites it. Is that simple solution appropriate? I'm not yet
seeing the advantage of the more complex possibilities.
Dan
>
> I'm not sure whether there's something more general than this, like
> attaching tags (that could be even elisp function) to result sections
> that do different things, one of which being enabling the section to
> receive results.
>
> Ok, I'm just bouncing ideas in case others see something useful. I've
> just started using org-babel and maybe I'll see different ways for
> achieving this.
>
> Thanks again for org-babel,
>
> Maurizio
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: org-babel feature request
2009-10-11 2:45 ` Dan Davison
@ 2009-10-11 3:01 ` Maurizio Vitale
2009-10-11 4:32 ` Dan Davison
0 siblings, 1 reply; 5+ messages in thread
From: Maurizio Vitale @ 2009-10-11 3:01 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
Dan> Maurizio Vitale
Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
Dan> writes:
Dan> [...]
>> It would be nice if it was possible to have multiple result
>> sections. This way I could embed in the document the result that
>> was obtained when writing the documentation, while still allowing
>> the person following the recipe to evaluate again the shell
>> script and get the results on his machine.
>>
>> The first section should be read-only (not necessarily physically
>> read-only, but skipped by C-c C-c). The others may be
>> re-evaluated over and over until the end user has a valid
>> configuration.
Dan> Hi Maurizio,
Dan> Once I've obtained the results that I want to "freeze", I would
Dan> manually alter (or even delete) the #+resname tag, so that the
Dan> source block no longer overwrites it. Is that simple solution
Dan> appropriate? I'm not yet seeing the advantage of the more
Dan> complex possibilities.
That is the obvious possibility, but at times you may want to
re-evaluate those: either the configuration has changed, or the software
you're documenting has changed or the script you're using is buggy.
Yes you could reintroduce the #+resname tag when needed, but I'm hoping
to get more automation than M-x shell-command-on-region.
I've just started using org-babel in this way, so I'm not sure at all of
what features I'll feel in the end needed. This seems one right now.
Best regards,
Maurizio
--
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: org-babel feature request
2009-10-11 3:01 ` Maurizio Vitale
@ 2009-10-11 4:32 ` Dan Davison
2009-10-11 14:05 ` Maurizio Vitale
0 siblings, 1 reply; 5+ messages in thread
From: Dan Davison @ 2009-10-11 4:32 UTC (permalink / raw)
To: Maurizio Vitale; +Cc: emacs-orgmode
Maurizio Vitale <maurizio.vitale@polymath-solutions.com> writes:
>>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
>
> Dan> Maurizio Vitale
> Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
> Dan> writes:
>
> Dan> [...]
>
> >> It would be nice if it was possible to have multiple result
> >> sections. This way I could embed in the document the result that
> >> was obtained when writing the documentation, while still allowing
> >> the person following the recipe to evaluate again the shell
> >> script and get the results on his machine.
> >>
> >> The first section should be read-only (not necessarily physically
> >> read-only, but skipped by C-c C-c). The others may be
> >> re-evaluated over and over until the end user has a valid
> >> configuration.
>
> Dan> Hi Maurizio,
>
> Dan> Once I've obtained the results that I want to "freeze", I would
> Dan> manually alter (or even delete) the #+resname tag, so that the
> Dan> source block no longer overwrites it. Is that simple solution
> Dan> appropriate? I'm not yet seeing the advantage of the more
> Dan> complex possibilities.
>
> That is the obvious possibility, but at times you may want to
> re-evaluate those: either the configuration has changed, or the software
> you're documenting has changed or the script you're using is buggy.
>
> Yes you could reintroduce the #+resname tag when needed, but I'm hoping
> to get more automation than M-x shell-command-on-region.
The other, perhaps nicer, thing you can do is change the #+srcname of
the block which has the effect of changing the results block. You can do
that now. But maybe we could allow the user to over-ride the default way
in which the #+resname tag is set? E.g. by adding a :resname header
argument.
Something like this:
--8<---------------cut here---------------start------------->8---
#+srcname: test2
#+begin_src sh :resname test2-redirected
expr 2 + 3
#+end_src
#+resname: test2
: 4
#+resname: test2-redirected
: 5
--8<---------------cut here---------------end--------------->8---
Do you think that would be worthwhile?
Dan
>
> I've just started using org-babel in this way, so I'm not sure at all of
> what features I'll feel in the end needed. This seems one right now.
>
> Best regards,
>
> Maurizio
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: org-babel feature request
2009-10-11 4:32 ` Dan Davison
@ 2009-10-11 14:05 ` Maurizio Vitale
0 siblings, 0 replies; 5+ messages in thread
From: Maurizio Vitale @ 2009-10-11 14:05 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
Dan> Maurizio Vitale <maurizio.vitale@polymath-solutions.com>
Dan> writes:
>>>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
>>
Dan> Maurizio Vitale
Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
Dan> writes:
>>
Dan> [...]
>>
>> >> It would be nice if it was possible to have multiple result >>
>> sections. This way I could embed in the document the result that
>> >> was obtained when writing the documentation, while still
>> allowing >> the person following the recipe to evaluate again the
>> shell >> script and get the results on his machine.
>> >>
>> >> The first section should be read-only (not necessarily
>> physically >> read-only, but skipped by C-c C-c). The others may
>> be >> re-evaluated over and over until the end user has a valid
>> >> configuration.
>>
Dan> Hi Maurizio,
>>
Dan> Once I've obtained the results that I want to "freeze", I would
Dan> manually alter (or even delete) the #+resname tag, so that the
Dan> source block no longer overwrites it. Is that simple solution
Dan> appropriate? I'm not yet seeing the advantage of the more
Dan> complex possibilities.
>>
>> That is the obvious possibility, but at times you may want to
>> re-evaluate those: either the configuration has changed, or the
>> software you're documenting has changed or the script you're
>> using is buggy.
>>
>> Yes you could reintroduce the #+resname tag when needed, but I'm
>> hoping to get more automation than M-x shell-command-on-region.
Dan> The other, perhaps nicer, thing you can do is change the
Dan> #+srcname of the block which has the effect of changing the
Dan> results block. You can do that now. But maybe we could allow
Dan> the user to over-ride the default way in which the #+resname
Dan> tag is set? E.g. by adding a :resname header argument.
Dan> Something like this:
Dan> #+srcname: test2 #+begin_src sh :resname test2-redirected expr
Dan> 2 + 3 #+end_src
Dan> #+resname: test2 : 4
Dan> #+resname: test2-redirected : 5
Dan> Do you think that would be worthwhile?
Too early for me to say. First reaction is that I don't see particular
advantages in the :resname method over the changing the src name to
justify the additional implementation effort.
What I think would be useful is a way to switch all results/srcnames in
a file by adding a prefix/suffix. So:
#+srcname test
would cause results to go to #+resname: test if
org-mode-babel-source-prefix is nil, but would go to
#+resname: example-test if
org-mode-babel-source-prefix is "example-"
and then org-mode-babel-source-prefix could be set somewhere in the
headers.
Maybe the #+resname which is updated could be marked with a '*' so that
if somebody does C-c C-c and doesn't see an update he's reminded that
the result block is not active because of a prefix.
Thanks for the suggestion of changing the source block name: it goes a
long way towards what I need.
>>
>> I've just started using org-babel in this way, so I'm not sure at
>> all of what features I'll feel in the end needed. This seems one
>> right now.
>>
>> Best regards,
>>
>> Maurizio
--
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-10-11 14:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-11 1:23 org-babel feature request Maurizio Vitale
2009-10-11 2:45 ` Dan Davison
2009-10-11 3:01 ` Maurizio Vitale
2009-10-11 4:32 ` Dan Davison
2009-10-11 14:05 ` Maurizio Vitale
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).