From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas S. Dye" Subject: Re: Re: Babel, Python and UTF-8 Date: Mon, 6 Dec 2010 06:42:55 -1000 Message-ID: <9CDC3D4C-6C60-49C7-B7AB-205511BFC8C1@tsdye.com> References: <87fwuhas6t.fsf@gmail.com> <80bp54a693.fsf@missioncriticalit.com> <87hbew7yvi.fsf@gmail.com> <80k4jsszq4.fsf@missioncriticalit.com> <8739qf2ade.fsf@gmail.com> <87mxokz176.fsf@gmail.com> <87d3pfjkyl.fsf@gmail.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=51204 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPe9a-0003KV-EV for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 11:43:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPe9Y-00013i-S8 for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 11:43:06 -0500 Received: from cpoproxy1-pub.bluehost.com ([69.89.21.11]:57181) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PPe9Y-000135-GZ for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 11:43:04 -0500 In-Reply-To: <87d3pfjkyl.fsf@gmail.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: Dan Davison Cc: Vincent Beffara , emacs-orgmode@gnu.org Hi Dan, Emacs configuration is one of the highest barriers to entry for =20 potential adopters of Org-mode, IMO. The idea of context-sensitive =20 configuration is potentially terrific. It gets the user to work more =20= quickly than would otherwise be the case. The problem I've run into =20 is that exiting a buffer doesn't change the configuration back to some =20= initial, or base, state. I'm on to the next task but still configured =20= to do the last thing. I'm not a software engineer, so this idea might be wacky, but it seems =20= to me that some code to restore the user's start-up settings would be =20= a useful, standard part of an Org-mode file, something like the export =20= template that many (most?) org-mode files use. I think it would be =20 handy to be able to stick something simple in my Org-mode file so that =20= I was confident I knew exactly how Emacs was configured while I was =20 using that file. Tom On Dec 5, 2010, at 11:42 PM, Dan Davison wrote: > "Eric Schulte" writes: > >> Vincent Beffara writes: >> >>> Hi, >>> >>>>> (and it would be excellent to allow for a code block as a =20 >>>>> preamble, >>>>> instead of a string in the header or as an alternative, because >>>>> preambles once they are allowed tend to grow uncontrollably ;->) >>>> >>>> This is currently possible using the `sbe' function. Arbitrary =20 >>>> emacs >>>> lisp can be placed inside of header arguments, and the `sbe' take =20= >>>> the >>>> name of a code block and returns its result. > > This makes me think of another good use of the sbe ("src block eval") > function. I'm often seeing Org documents with a src block like this, > > #+source: essential-document-config > #+begin_src emacs-lisp > ;; some essential document-specific configuration > #+end_src > > and some instructions saying something like "To use this document, =20 > first > evaluate this code block". > > This can be automated by using sbe in a local variables line at the =20= > end > of the Org file: > > # Local variables: > # eval:(sbe "essential-document-config") > # End: > > When the file is first opened, Emacs will evaluate the set-up blocks > (after asking for confirmation). > > This isn't restricted to configuration of Emacs variables with > emacs-lisp blocks; eval lines could reference blocks in any language, > for example to start an ESS session and run some preparatory code, =20 > etc, > e.g. > > #+source: document-config > #+begin_src emacs-lisp > (set (make-local-variable 'org-edit-src-content-indentation) 0) > #+end_src > > #+source: start-ess > #+begin_src R :session *R session* > a <- 1 > #+end_src > > # Local variables: > # eval:(sbe "document-config") > # eval:(sbe "start-ess") > # End: > > > Dan > >>> >>> Very cool ! That does all I want, thanks for the info. For multi-=20 >>> line it >>> is a bit heavy to write, with lots of \n and preamble .=3D "lskjd", =20= >>> but I >>> can live with that. Unless there is a way already to write something >>> like this ? >>> >>> #+source: my-preamble >>> #+begin_src python :return preamble >>> # -*- coding: utf-8 -*-" >>> import os,sys,whatever >>> #+end_src >>> >>> #+begin_src python :preamble (org-babel-get-and-expand-source-code-=20= >>> body my-preamble) :return s >>> s =3D "=E9" >>> #+end_src >>> >>> There is org-babel-get-src-block-info but it looks at the block =20 >>> around >>> (point), not by name ... so I guess it would not be too hard to =20 >>> write >>> the extraction method, but it might be somewhere in the code =20 >>> already. >>> >> >> Yes, the following uses an internal Babel function, but is probably =20= >> much >> simpler >> >> #+results: my-preamble >> : # -*- coding: utf-8 -*- >> : import os,sys,whatever >> >> #+begin_src python :preamble (org-babel-ref-resolve "my-=20 >> preamble") :return s >> s =3D "" >> #+end_src >> >> Note that as written this will return the following python error >> >> Traceback (most recent call last): >> File "", line 2, in >> ImportError: No module named whatever >> >>> >>>>> One naive question : why is the code path different for tangling =20= >>>>> and >>>>> evaluation ? One would think that a natural way for evaluation =20 >>>>> would be >>>>> to tangle the current block (plus included noweb stuff etc) into a >>>>> temporary file and eval that file ... and that would enable =20 >>>>> shebang for >>>>> evaluation as well. There must be something I am missing here. >>>> >>>> Tangling works for *any* programming language, even those which =20 >>>> have yet >>>> to be created and have no explicit Emacs or Org-mode support, =20 >>>> this is >>>> because on tangling the code block is simply treated as text. >>> >>> As far as I understood from testing, tangling does adapt to the =20 >>> language >>> (at least to implement :var in a suitable way), so I was under the >>> impression that evaluating could be implemented as some kind of =20 >>> wrapping >>> around the tangled output - and obviously the wrapping would have =20= >>> to be >>> language-specific even if for the most part the tanglong is not. >>> >> >> Yes, some language specific features (e.g. variable expansion) can be >> used by the tangling mechanisms if such features are defined for the >> language in question, however tangling can be done in the absence =20 >> of any >> language specific features and thus works for any arbitrary language. >> >> That shebang and preamble should remain separate for the other =20 >> reasons >> mentioned in my previous email. >> >>> >>> I am just discovering all of this, sorry if I have horrible >>> misconceptions about the thing ... >>> >> >> No problem, it is a fairly (but I don't think overly) complex system. >> >>> >>> Regards, >>> >>> /v >>> >>> >>> _______________________________________________ >>> Emacs-orgmode mailing list >>> Please use `Reply All' to send replies to the list. >>> Emacs-orgmode@gnu.org >>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Please use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode