From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Babel, Python and UTF-8 Date: Mon, 06 Dec 2010 18:23:59 +0000 Message-ID: <87sjyaep4w.fsf@gmail.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> <9CDC3D4C-6C60-49C7-B7AB-205511BFC8C1@tsdye.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=35675 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPfjO-0002b8-W2 for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 13:24:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPfjN-00045c-3J for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 13:24:10 -0500 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:49792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPfjM-00045P-Px for emacs-orgmode@gnu.org; Mon, 06 Dec 2010 13:24:09 -0500 In-Reply-To: <9CDC3D4C-6C60-49C7-B7AB-205511BFC8C1@tsdye.com> (Thomas S. Dye's message of "Mon, 6 Dec 2010 06:42:55 -1000") 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: "Thomas S. Dye" Cc: Vincent Beffara , emacs-orgmode@gnu.org "Thomas S. Dye" writes: > Hi Dan, > > Emacs configuration is one of the highest barriers to entry for > potential adopters of Org-mode, IMO. The idea of context-sensitive > configuration is potentially terrific. It gets the user to work more > quickly than would otherwise be the case. The problem I've run into > is that exiting a buffer doesn't change the configuration back to some > initial, or base, state. I'm on to the next task but still configured > to do the last thing. Hi Tom, I think someone else suggested using buffer-local variables to address this problem, and I think that's the correct suggestion. One of the examples below shows how to set a buffer-local value: [...] > #+source: document-config >> #+begin_src emacs-lisp >> (set (make-local-variable 'org-edit-src-content-indentation) 0) >> #+end_src As it happens, for that particular setting to be useful requires a patch that is pending review, but, in general, I think this is the way to do what you're describing. Dan >> >> #+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- >>>> line it >>>> is a bit heavy to write, with lots of \n and preamble .=3D "lskjd", >>>> 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- >>>> body my-preamble) :return s >>>> s =3D "=C3=A9" >>>> #+end_src >>>> >>>> There is org-babel-get-src-block-info but it looks at the block >>>> around >>>> (point), not by name ... so I guess it would not be too hard to >>>> write >>>> the extraction method, but it might be somewhere in the code >>>> already. >>>> >>> >>> Yes, the following uses an internal Babel function, but is probably >>> much >>> simpler >>> >>> #+results: my-preamble >>> : # -*- coding: utf-8 -*- >>> : import os,sys,whatever >>> >>> #+begin_src python :preamble (org-babel-ref-resolve "my- >>> 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 >>>>>> and >>>>>> evaluation ? One would think that a natural way for evaluation >>>>>> would be >>>>>> to tangle the current block (plus included noweb stuff etc) into a >>>>>> temporary file and eval that file ... and that would enable >>>>>> shebang for >>>>>> evaluation as well. There must be something I am missing here. >>>>> >>>>> Tangling works for *any* programming language, even those which >>>>> have yet >>>>> to be created and have no explicit Emacs or Org-mode support, >>>>> 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 >>>> 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 >>>> wrapping >>>> around the tangled output - and obviously the wrapping would have >>>> 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 >>> of any >>> language specific features and thus works for any arbitrary language. >>> >>> That shebang and preamble should remain separate for the other >>> 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 > > > _______________________________________________ > 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