Hi, I am wondering why the default value of header argument :tangle is 'no' rather than 'yes'. Back to google-calendar.org as an example. Is it normal that whomever wants to use the embedded elisp file needs to edit the source and e.g. insert a '#+PROPERTY: tangle yes'? It is clear that this file will need to be tangled by every single person that wants to use the embedded code, so should the default not allow for tangling without having the edit the input file? There are probably some very valid reasons why the default is 'no' rather than 'yes'. Please enlighten me. Respectfully, Guido -- The older I grow, the more I distrust the familiar doctrine that age brings wisdom. -- H. L. Mencken
Guido Van Hoecke writes: > I am wondering why the default value of header argument :tangle is 'no' > rather than 'yes'. FWIW, the default makes sense to me. A document might contain lots of little code blocks for one purpose or another (testing, little utilities, version archive, etc.) that you don't want included in the tangled product. > Back to google-calendar.org as an example. > > Is it normal that whomever wants to use the embedded elisp file needs > to edit the source and e.g. insert a '#+PROPERTY: tangle yes'? > > It is clear that this file will need to be tangled by every single > person that wants to use the embedded code, so should the default not > allow for tangling without having the edit the input file? Well, if you're distributing code for others to use in the form of source blocks in Org documents, it may be a courtesy to set `:tangle yes'. But that doesn't necessarily give users the tangled result where they want it on their system, with the filename they want, so they will often have to edit it anyway. Yours, Christian
Christian Moe wrote:
> Guido Van Hoecke writes:
>> I am wondering why the default value of header argument :tangle is 'no'
>> rather than 'yes'.
>
> FWIW, the default makes sense to me. A document might contain lots of
> little code blocks for one purpose or another (testing, little
> utilities, version archive, etc.) that you don't want included in the
> tangled product.
>
>> Back to google-calendar.org as an example.
>>
>> Is it normal that whomever wants to use the embedded elisp file needs
>> to edit the source and e.g. insert a '#+PROPERTY: tangle yes'?
>>
>> It is clear that this file will need to be tangled by every single
>> person that wants to use the embedded code, so should the default not
>> allow for tangling without having the edit the input file?
>
> Well, if you're distributing code for others to use in the form of
> source blocks in Org documents, it may be a courtesy to set `:tangle
> yes'.
>
> But that doesn't necessarily give users the tangled result where they
> want it on their system, with the filename they want, so they will often
> have to edit it anyway.
And you can change the default for your Org installation, by changing the
default of the "tangle" header argument in your .emacs file:
#+begin_src emacs-lisp
;; add default arguments
(add-to-list 'org-babel-default-header-args
'(:tangle . "yes"))
#+end_src
Best regards,
Seb
--
Sebastien Vauban
"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes: > Christian Moe wrote: >> Guido Van Hoecke writes: >>> I am wondering why the default value of header argument :tangle is 'no' >>> rather than 'yes'. >> >> FWIW, the default makes sense to me. A document might contain lots of >> little code blocks for one purpose or another (testing, little >> utilities, version archive, etc.) that you don't want included in the >> tangled product. I see, that's a very valid point. >>> Back to google-calendar.org as an example. >>> >>> Is it normal that whomever wants to use the embedded elisp file needs >>> to edit the source and e.g. insert a '#+PROPERTY: tangle yes'? >>> >>> It is clear that this file will need to be tangled by every single >>> person that wants to use the embedded code, so should the default not >>> allow for tangling without having the edit the input file? >> >> Well, if you're distributing code for others to use in the form of >> source blocks in Org documents, it may be a courtesy to set `:tangle >> yes'. >> >> But that doesn't necessarily give users the tangled result where they >> want it on their system, with the filename they want, so they will often >> have to edit it anyway. > > And you can change the default for your Org installation, by changing the > default of the "tangle" header argument in your .emacs file: > > #+begin_src emacs-lisp > ;; add default arguments > (add-to-list 'org-babel-default-header-args > '(:tangle . "yes")) > #+end_src I should have known that this is configurable :) Thank you guys, Guido -- Regardless of whether a mission expands or contracts, administrative overhead continues to grow at a steady rate.