"Thomas S. Dye" <t...@tsdye.com> 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 .= "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 = "é" >>>> #+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 = "" >>> #+end_src >>> >>> Note that as written this will return the following python error >>> >>> Traceback (most recent call last): >>> File "<stdin>", line 2, in <module> >>> 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 _______________________________________________ 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
