From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: [ANN] Org-babel integrated into Org-mode Date: Thu, 01 Jul 2010 18:14:38 -0400 Message-ID: <12363.1278022478@alphaville.usa.hp.com> References: <87wrtp78rg.fsf@gmail.com> <874oglofzs.fsf@fastmail.fm> <87sk4432t8.fsf@gmail.com> <87zkyc4fql.fsf@gmail.com> <24591.1278000684@gamaville.dokosmarshall.org> <87r5jnj6hm.fsf@mundaneum.com> Reply-To: nicholas.dokos@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=36035 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUS21-0008Eb-4D for emacs-orgmode@gnu.org; Thu, 01 Jul 2010 18:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUS1p-0005kz-9k for emacs-orgmode@gnu.org; Thu, 01 Jul 2010 18:14:46 -0400 Received: from g6t0186.atlanta.hp.com ([15.193.32.63]:10973) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUS1p-0005kq-4W for emacs-orgmode@gnu.org; Thu, 01 Jul 2010 18:14:41 -0400 In-Reply-To: Message from =?us-ascii?Q?=3D=3Futf-8=3FQ=3FS=3DC3=3DA9bastie?= =?us-ascii?Q?n=5FVauban=3F=3D?= of "Thu\, 01 Jul 2010 22\:24\:05 +0200." <87r5jnj6hm.fsf@mundaneum.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FS=3DC3=3DA9bastien=5FVauban=3F=3D?= Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org S=C3=A9bastien Vauban wrote: > Nick Dokos wrote: > > Carsten Dominik wrote: > >>=20 > >> :-) Actually, in this specific area I had been thinking to removing or= at > >> least deprecating shell and elisp links, because the Org-babel way is = much > >> better and clearer to have that code in a block, rather than hiding it= in > >> the invisible part of of a link. > > > > Here is an early vote [1] for *not* removing shell and elisp links. > > Deprecation/documentation/scary warnings is fine with me, but I do use = these > > kinds of links and I'd like to be able to continue using them. >=20 > For my own understanding of what more I could do that I don't even think = of > right now, *if not indiscreet/private*, could you give a couple of > applications of such links? >=20 Hi Seb, it's nothing spectacular: on the contrary, it's all the mundane things that I have various scripts for (either shell or elisp), e.g. munge with my jottings of the week and prepare a weekly report that is mailed to my manager and also exported to HTML for posterity - that's an elisp link. It's particularly things that I don't do often enough so I tend to forget what they are called, what arguments they take, etc. The links provide just enough documentation to jog my memory and a convenient way to launch the thing. I have a lot of these in many files: they tend to be very specific and so after a while the details slip away (e.g. the org file that describes all I know about a particular bug, might have a link to the bugzilla entry for the bug (an html link), email links, file links to data and a link to start a test run - this last is generally a shell link). Before org, for shell scripts, I would list my ~/bin directory and try to discern which of the many hundreds of scripts in there is the one that I need, and assuming that I would find it, I would then read the script to find what arguments it would need. Now, I visit an org file (one of a handful, organized by topic), read the link description and activate it. IOW, it could all be done in org-babel, but I started these a long time ago and I have accumulated so many of them, that converting would be a pain. In addition, they are spread out all over the place, so I would have to convert them one by one as I need them and there are so many possible places for Murphy's law to intrude, that losing the capability would be cause for serious concern for me. Hence the preemptive vote :-) Cheers, Nick