Writing .el files for org in org?

Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

Hi

I am just getting into the ob-R.el file and am making some changes which
will make it easier to customize the behaviour and possibly mre
transparent how variable transfer and wrapping of graph generation is
done.

But as I am struggling with elisp, I would like to put the ob-R.el file
into an org file which is then tangled into the ob-R.el file. this is
obviously possible, but I think that my comments and insight (from a
non-elisp programmers perspective) might be useful for others as well. I
could obviously put the ob-el.org file on github, but I am wondring if
it would be possible to include it into the org distribution, which then
could be tangled upon compile / installation?

I am sure this would be possible, but would this be feasible? A good
idea? Or would it be better to have an additional directory
(e.g. lisp.org) which contains the corresponding .org files?

For personal usage, I am going to use it, but it might be useful to have
this for all supported languages?

Cheers,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Aaron Ecay]

Hi Rainer,

I have wondered about what you suggest as well, from the point of view
of trying to modify the long pieces of R code which are embedded in
strings in ob-R.el.  I think this would be easier if they could be
tangled from R code blocks in an org file.  So from that point of view
the idea has a +1 from me.

I am not so convinced that having all the elisp code in an org file
would be convenient, since I am worried that would break the interactive
features of elisp programming.  (edebug, find-function, paredit, ...).
But if you are doing the experiment, I would be glad to see what you
come up with: the benefits might turn out to be worth the potential
drawbacks.

--
Aaron Ecay

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Rainer,
>
> I have wondered about what you suggest as well, from the point of view
> of trying to modify the long pieces of R code which are embedded in
> strings in ob-R.el.  I think this would be easier if they could be
> tangled from R code blocks in an org file.  So from that point of view
> the idea has a +1 from me.

That is one aspect am looking at (independent of the org file question)
at the moment, to make the R code more configurable. My approach is to 

a) have it in a emacs string variables which can be customized, or
b) in an R file which is loaded and used instead of the definition in
the variable. If you are interested, please see my org [1] and ess [2]
which, at the moment, have to be used together, as I am "outsourcing"
the loading at the moment to ESS.

Concerning putting them in an org file, I don't see a real advantage
here, unless the ob-R.el is also in an org file.

>
> I am not so convinced that having all the elisp code in an org file
> would be convenient, since I am worried that would break the interactive
> features of elisp programming.  (edebug, find-function, paredit, ...).
> But if you are doing the experiment, I would be glad to see what you
> come up with: the benefits might turn out to be worth the potential
> drawbacks.

I am not thinking about having the org files used for actual running
org, but rather as a tool to write the code. The workflow would be then:

1) in the org file, write the code for ob-R.el including documentation
2) tangle the file to ob-R.el 
3) debug ob-R.el - in R
4) untangle the edits back into the ob-R.org file
5) done

So the tools for debugging would be still working on the .el file.

Rainer

>
> --
> Aaron Ecay


Footnotes: 
[1]  https://github.com/rkrug/orgmode-dev

[2]  https://github.com/rkrug/ess-dev

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Bastien]

Hi Rainer and Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> I am not so convinced that having all the elisp code in an org file
> would be convenient, since I am worried that would break the interactive
> features of elisp programming.

My point of view too.

On top of this, I see two problems:

1. there is the problem of minimizing the distance between what the
   Org repository contains and what goes into the Emacs repository*

2. and the problem of imposing something that might not fit all
   contributors.  Using litterate programming for a few files but not
   all is not a good option, and using litterate programming for all
   files would be too much of a constraint for many...

Best,

* That's also the reason why I'm skeptical about having the manual
  written as org.org instead of org.texi -- I mean, I'd be glad to be
  able to edit the manual as org.org, but having a preliminary export
  step before importing org.texi into Emacs might create problems.

-- 
 Bastien

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

Bastien <bzg@gnu.org> writes:

> Hi Rainer and Aaron,
>
> Aaron Ecay <aaronecay@gmail.com> writes:
>
>> I am not so convinced that having all the elisp code in an org file
>> would be convenient, since I am worried that would break the interactive
>> features of elisp programming.
>
> My point of view too.
>
> On top of this, I see two problems:
>
> 1. there is the problem of minimizing the distance between what the
>    Org repository contains and what goes into the Emacs repository*
>
> 2. and the problem of imposing something that might not fit all
>    contributors.  Using litterate programming for a few files but not
>    all is not a good option, and using litterate programming for all
>    files would be too much of a constraint for many...

I see you point concerning using org files for all files, but the
ob-LANGUAGE.el files are in their own class (LANGUAGE refers to e.g. R,
sh, ...). 

1) Many users of these features will have (at least a little)
programming experience, not unlikely more in LANGUAGE then in emacs-lisp.

2) the functions in these files are the actual interface between the
LANGUAGE and org, and it is more important here that they can be
understood and changes suggested by their users then in the org core
files, as specialist users of a specific LANGUAGE might discover problems, of
which the original author might not be aware of or which have been
introduced by updates in LANGUAGE.

So I would argue that in ob-LANGUAGE.el files the non-elisp-expert is more
likely to look and work then in the core org files wherefore an
a more familiar interface for these changes (literate programming in
org) would provide more advantages then in the org-core files.

Cheers,

Rainer

>
> Best,
>
> * That's also the reason why I'm skeptical about having the manual
>   written as org.org instead of org.texi -- I mean, I'd be glad to be
>   able to edit the manual as org.org, but having a preliminary export
>   step before importing org.texi into Emacs might create problems.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Bastien]

Rainer M Krug <Rainer@krugs.de> writes:

> So I would argue that in ob-LANGUAGE.el files the non-elisp-expert is more
> likely to look and work then in the core org files wherefore an
> a more familiar interface for these changes (literate programming in
> org) would provide more advantages then in the org-core files.

But there is still the first and main problem that Aaron pointed to.

-- 
 Bastien

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Bastien <bzg@gnu.org> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> So I would argue that in ob-LANGUAGE.el files the non-elisp-expert is more
>> likely to look and work then in the core org files wherefore an
>> a more familiar interface for these changes (literate programming in
>> org) would provide more advantages then in the org-core files.
>
> But there is still the first and main problem that Aaron pointed to.

Just to make my point clear: I would not see the .org file as the one
which is used when using org, but as the one which is used to 

1) understand what is going on, i.e. include more detailed explanations
of what the functions are doing, what they are returning, possibly some
callcharts of the functions --- just everything to really understand
what is going on and why these things are done as they are. In other
words: follow the paradigm of literate programming.

2) which is tangled to generate the ob-....el file

3) which then can be debugged as usual

4) and if it is working, detangled into ob-....org

I must stress this comes from somebody not familiar with to much
emacs-lisp, but very familiar with R and Pascal (long time ago) and some
working C knowledge.

So the reason why I think it would be advantageous to have these files
in org does not lie with the programmer familiar with emacs-lisp, but
with somebody familiar with the other side.

Cheers,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Bastien]

Rainer M Krug <Rainer@krugs.de> writes:

> So the reason why I think it would be advantageous to have these files
> in org does not lie with the programmer familiar with emacs-lisp, but
> with somebody familiar with the other side.

Sorry I was too terse in my previous answer: I completely agree with
the goal you describe, but I don't think adding an .org source along
the .el output (say e.g. ob-R.org and ob-R.el) will simplify my life
as a maintainer: each time an ob-*.org file is changed we need to
tangle it again... and this leads to auto-tangling, auto-committing
considerations that I don't even want to start thinking about.

-- 
 Bastien

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Bastien <bzg@gnu.org> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> So the reason why I think it would be advantageous to have these files
>> in org does not lie with the programmer familiar with emacs-lisp, but
>> with somebody familiar with the other side.
>
> Sorry I was too terse in my previous answer: I completely agree with
> the goal you describe, but I don't think adding an .org source along
> the .el output (say e.g. ob-R.org and ob-R.el) will simplify my life
> as a maintainer: each time an ob-*.org file is changed we need to
> tangle it again... and this leads to auto-tangling, auto-committing
> considerations that I don't even want to start thinking about.

I absolutely see your point, and I agree that doing this manually is out
of the question. But I am wondering if it would be possible to automate
this process, i.e. using git post server side hooks? I must admit that I
don't have any experience with this, but it sounds about the thing one
could use to automatically tangle the file.

But as I am not the one who has to maintain it, it is easy for me to
suggest it.

Cheers,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Bastien]

Rainer M Krug <Rainer@krugs.de> writes:

> But as I am not the one who has to maintain it, it is easy for me to
> suggest it.

:)

Even if we find a solution for keeping everything in sync easily,
there is still the problem of enforcing a convention on potentially
many contributors.

Maybe you can publish your ob-R.org file somewhere on gitorious or
github and report how it goes?  This would help convince others.
Once there is a majority asking for all ob-*.el file to be edited
like this, we can think of fixing the other problems.

-- 
 Bastien

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

Bastien <bzg@gnu.org> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> But as I am not the one who has to maintain it, it is easy for me to
>> suggest it.
>
> :)
>
> Even if we find a solution for keeping everything in sync easily,
> there is still the problem of enforcing a convention on potentially
> many contributors.
>
> Maybe you can publish your ob-R.org file somewhere on gitorious or
> github and report how it goes?  This would help convince others.
> Once there is a majority asking for all ob-*.el file to be edited
> like this, we can think of fixing the other problems.

OK - I will probably do this and keep you posted about it.

Thanks a lot,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

What if we created a new directory in the repository called "org" which
contains these kinds of files?  It would be analogous to the "lisp"
directory. I don't think we need to have both ob-R.org and ob-R.el in the
repository.

For example I wrote org-ref.org, and I load it like this in my init file
(the intention here is to only tangle the org file when it is newer than
the el file or if there is no el file. for some reason my memory says that
org-babel-load-file was not doing this but that may be a faulty memory).

(if (or
     (not (file-exists-p "org-ref.el"))
     (< (float-time (nth 5 (file-attributes "org-ref.el")))
    (float-time (nth 5 (file-attributes "org-ref.org")))))
    (progn
      (org-babel-tangle-file (expand-file-name "org-ref.org"
starter-kit-dir))
      (load-file (expand-file-name "org-ref.el" starter-kit-dir)))
  (require 'org-ref))

I could see there being something like the lisp path for finding these
files, so that we could just do:

(org-require 'org-ref)

or the org-babel-load-file could be adapted to have a path to search for
files. This way there is no auto-tangling, committing, etc... just regular
version control on the source of the source.




John

-----------------------------------
John Kitchin
Associate Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu



On Thu, May 22, 2014 at 7:04 AM, Bastien <bzg@gnu.org> wrote:

> Rainer M Krug <Rainer@krugs.de> writes:
>
> > So the reason why I think it would be advantageous to have these files
> > in org does not lie with the programmer familiar with emacs-lisp, but
> > with somebody familiar with the other side.
>
> Sorry I was too terse in my previous answer: I completely agree with
> the goal you describe, but I don't think adding an .org source along
> the .el output (say e.g. ob-R.org and ob-R.el) will simplify my life
> as a maintainer: each time an ob-*.org file is changed we need to
> tangle it again... and this leads to auto-tangling, auto-committing
> considerations that I don't even want to start thinking about.
>
> --
>  Bastien
>
>

[-- Attachment #2: Type: text/html, Size: 3158 bytes --]

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3706 bytes --]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> What if we created a new directory in the repository called "org" which
> contains these kinds of files?  It would be analogous to the "lisp"
> directory. I don't think we need to have both ob-R.org and ob-R.el in the
> repository.

I think that would be a very good idea for certain modules like your
org-ref and ob-R I am working on.


>
> For example I wrote org-ref.org, and I load it like this in my init file
> (the intention here is to only tangle the org file when it is newer than
> the el file or if there is no el file. for some reason my memory says that
> org-babel-load-file was not doing this but that may be a faulty memory).
>
> (if (or
>      (not (file-exists-p "org-ref.el"))
>      (< (float-time (nth 5 (file-attributes "org-ref.el")))
>     (float-time (nth 5 (file-attributes "org-ref.org")))))
>     (progn
>       (org-babel-tangle-file (expand-file-name "org-ref.org"
> starter-kit-dir))
>       (load-file (expand-file-name "org-ref.el" starter-kit-dir)))
>   (require 'org-ref))

Isn't the already existing org-babel-load-file doing exactly that?
It is robust as it is used by many to load emacs.org, and it can also
compile the file.

>
> I could see there being something like the lisp path for finding these
> files, so that we could just do:
>
> (org-require 'org-ref)
>
> or the org-babel-load-file could be adapted to have a path to search for
> files. 

OK - this sounds like a good approach.

Thinking about it, I don't know if it is a good idea to change the
installed files or add new ones, as this might (will?) cause access
right problems. I would rather suggest to tangle the org file into a
temporary file and then load it from there. Therefore, write access is
not required for the installation (which is safer).

So this would mean a rewrite of the org-babel-load-file function, or
just add a third optional argument for the path of the .el and/or .elc
file.

> This way there is no auto-tangling, committing, etc... just regular
> version control on the source of the source.

That would be great, and I would convert the existing ob-R.el immediately.

Cheers,

Rainer

>
>
>
>
> John
>
> -----------------------------------
> John Kitchin
> Associate Professor
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Thu, May 22, 2014 at 7:04 AM, Bastien <bzg@gnu.org> wrote:
>
>> Rainer M Krug <Rainer@krugs.de> writes:
>>
>> > So the reason why I think it would be advantageous to have these files
>> > in org does not lie with the programmer familiar with emacs-lisp, but
>> > with somebody familiar with the other side.
>>
>> Sorry I was too terse in my previous answer: I completely agree with
>> the goal you describe, but I don't think adding an .org source along
>> the .el output (say e.g. ob-R.org and ob-R.el) will simplify my life
>> as a maintainer: each time an ob-*.org file is changed we need to
>> tangle it again... and this leads to auto-tangling, auto-committing
>> considerations that I don't even want to start thinking about.
>>
>> --
>>  Bastien
>>
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Bastien]

Hi John and Rainer,

Rainer M Krug <Rainer@krugs.de> writes:

>> What if we created a new directory in the repository called "org" which
>> contains these kinds of files?  It would be analogous to the "lisp"
>> directory. I don't think we need to have both ob-R.org and ob-R.el in the
>> repository.
>
> I think that would be a very good idea for certain modules like your
> org-ref and ob-R I am working on.

Maybe you could use such a "load-flow" for a while, see if it is
robust enough, and if so, we could move on and have it in the repo?

My gut feeling is that it will bring some issues, so experimenting
before would be nice.

-- 
 Bastien

Re: Writing .el files for org in org?

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

Ok, I am giving it a shot. Here is my setup:

;;;;;;; org path
(defvar org-load-path
  (list (file-name-as-directory
 (expand-file-name "org" starter-kit-dir)))
  "List of directories to find org-files that
  `org-babel-load-file' can load code from")

(defun org-require (feature)
  "Load a FEATURE from an org-file.
FEATURE is a symbol, and it is loaded from an org-file by the name of
FEATURE.org, that is in the `org-load-path'. The FEATURE is loaded from
`org-babel-load-file'."
  (let ((org-file (concat (symbol-name feature) ".org"))
(path))

    ;; find the org-file
    (catch 'result
      (loop for dir in org-load-path do
    (when (file-exists-p
   (setq path
 (expand-file-name
  org-file
  dir)))
      (throw 'result path))))
    (let ((default-directory (file-name-directory path)))
      (org-babel-load-file path))))

(org-require 'org-ref)
(org-require 'doi-utils)
(org-require 'org-show)


In the only directory I define in org-load-path, I put org-show.org,
org-ref.org, and doi-utils.org, and the code above is in an init file. When
I load emacs, for these files, so far, it works great. They are simple
files that only tangle to one .el file so far.



John

-----------------------------------
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu



On Sun, Jul 27, 2014 at 5:50 PM, Bastien <bzg@gnu.org> wrote:

> Hi John and Rainer,
>
> Rainer M Krug <Rainer@krugs.de> writes:
>
> >> What if we created a new directory in the repository called "org" which
> >> contains these kinds of files?  It would be analogous to the "lisp"
> >> directory. I don't think we need to have both ob-R.org and ob-R.el in
> the
> >> repository.
> >
> > I think that would be a very good idea for certain modules like your
> > org-ref and ob-R I am working on.
>
> Maybe you could use such a "load-flow" for a while, see if it is
> robust enough, and if so, we could move on and have it in the repo?
>
> My gut feeling is that it will bring some issues, so experimenting
> before would be nice.
>
> --
>  Bastien
>

[-- Attachment #2: Type: text/html, Size: 3835 bytes --]

Re: Writing .el files for org in org?

[Josh Berry]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Thu, May 22, 2014 at 5:54 AM, Rainer M Krug <Rainer@krugs.de> wrote:

> 4) and if it is working, detangled into ob-....org
>

Apologies for jumping in as a lurker.  When you say "detangled", is there a
process for doing this?  I know that working with cweb files the tangled
output included some markers to indicate where the sections came from.
Having something like that here would be great.  I have not extensively
used this workflow for writing code, but I know I have had times where I
found it easy to try out a few small (or sometimes largish) changes in the
tangled output directly.  Having a procedure to "detangle" would be very
nice.

Thanks!

-josh

[-- Attachment #2: Type: text/html, Size: 1056 bytes --]

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Josh Berry <taeric@gmail.com> writes:

> On Thu, May 22, 2014 at 5:54 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>
>> 4) and if it is working, detangled into ob-....org
>>
>
> Apologies for jumping in as a lurker.  When you say "detangled", is there a
> process for doing this?  I know that working with cweb files the tangled

Yes - org-babel-detangle.

Cheers,

Rainer

> output included some markers to indicate where the sections came from.
> Having something like that here would be great.  I have not extensively
> used this workflow for writing code, but I know I have had times where I
> found it easy to try out a few small (or sometimes largish) changes in the
> tangled output directly.  Having a procedure to "detangle" would be very
> nice.
>
> Thanks!
>
> -josh

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Grant Rettke]

On Wed, May 21, 2014 at 3:21 PM, Rainer M Krug <Rainer@krugs.de> wrote:
> I am sure this would be possible, but would this be feasible? A good
> idea? Or would it be better to have an additional directory
> (e.g. lisp.org) which contains the corresponding .org files?

Great question. Anybody tangling with org-mode has either already
asked themselves this question, or will be soon. When I started out
with org-mode I looked at it as a writing tool, and that was true
until I started using the literate programming feature. Without the
right perspective, I got myself into a lot of trouble. When I started
looking at it as programming, and system management, things started
working out for me again. When you frame your question more as a
systems management question, it gets a little clearer.

What does it take to release your code to production? The simplest
form would be to keep your generated files in Git, tag the release,
and then you are done. That is the official and final version of that
release of the system. Following this approach means that you can
release it easily on MELPA and org and anywhere else that you need
because you know what you generated, how you generated it, and how you
tested it. Simple. The alternative is to release only the source
org-file.

This process is a little more involved. In order to sign off on
allowing people to use the system that is built with that org file,
you need to make sure that they are able to regenerate it using
exactly the environment that you intend. For example, you will tangle
with a particular version of Emacs, on a particular platform, with a
particular set of plugins loaded into Emacs when you do the tangling.
Perhaps you even want to specify down to the operating system, and
more. Whether you intended it or not, the entirety of the system that
you use to do the tangling, is the implicit specification for what
people should use to tangle it themselves. Sure, I am going a bit
overboard here, but generally people don't care about such stuff until
it breaks.

My personal preference is to go with the latter. It forces me to know
what is going on. Doing it by hand is so tedious and often error prone
though, so I'm investing in mastering Vagrant. Vagrant will let you
have a reproducible system so you can specify what you used to build
your release (generate), and let others do that too if they want. The
only difficult is how lock that down for deployed code. Surely most of
the time you may just do the generation on deploy, eg via ELPA or its
kin. It just depends standard you want to, and must, hold yourself
too.

Safe travels.

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 4065 bytes --]

Grant Rettke <gcr@wisdomandwonder.com> writes:

> On Wed, May 21, 2014 at 3:21 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>> I am sure this would be possible, but would this be feasible? A good
>> idea? Or would it be better to have an additional directory
>> (e.g. lisp.org) which contains the corresponding .org files?
>
> Great question. Anybody tangling with org-mode has either already
> asked themselves this question, or will be soon. When I started out
> with org-mode I looked at it as a writing tool, and that was true
> until I started using the literate programming feature. Without the
> right perspective, I got myself into a lot of trouble. When I started
> looking at it as programming, and system management, things started
> working out for me again. When you frame your question more as a
> systems management question, it gets a little clearer.

I started with org the other way around - as a tool for literate
programming and slowly getting into org as tool for organizing.

>
> What does it take to release your code to production? The simplest
> form would be to keep your generated files in Git, tag the release,
> and then you are done. That is the official and final version of that
> release of the system. Following this approach means that you can
> release it easily on MELPA and org and anywhere else that you need
> because you know what you generated, how you generated it, and how you
> tested it. Simple. The alternative is to release only the source
> org-file.
>
> This process is a little more involved. In order to sign off on
> allowing people to use the system that is built with that org file,
> you need to make sure that they are able to regenerate it using
> exactly the environment that you intend. For example, you will tangle
> with a particular version of Emacs, on a particular platform, with a
> particular set of plugins loaded into Emacs when you do the tangling.
> Perhaps you even want to specify down to the operating system, and
> more. Whether you intended it or not, the entirety of the system that
> you use to do the tangling, is the implicit specification for what
> people should use to tangle it themselves. Sure, I am going a bit
> overboard here, but generally people don't care about such stuff until
> it breaks.

How involved this becomes, depends on how much you customize your
tangling. If tangling is done on a highly customized emacs / org
installation, it will be difficult to reproduce. But if tangling is done
using a similar approach to what is done when using emacs.org, I don't
think it would be to difficult to do.

>
> My personal preference is to go with the latter. It forces me to know
> what is going on. Doing it by hand is so tedious and often error prone
> though, so I'm investing in mastering Vagrant. Vagrant will let you
> have a reproducible system so you can specify what you used to build
> your release (generate), and let others do that too if they want. The
> only difficult is how lock that down for deployed code. Surely most of
> the time you may just do the generation on deploy, eg via ELPA or its
> kin. It just depends standard you want to, and must, hold yourself
> too.

If I understand you correctly, you are using Vagrant to develop your code
and to generate the release - that is a good idea. But isn't this an
overkill in the case of the context here? org (and emacs) should be
stable enough to tangle the same .el file from an .org file
(irrespective of whitespace and comments which do not influence the
functional aspects).

Cheers,

Rainer

>
> Safe travels.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Writing .el files for org in org?

[Grant Rettke]

On Thu, May 22, 2014 at 3:30 AM, Rainer M Krug <Rainer@krugs.de> wrote:

> If I understand you correctly, you are using Vagrant to develop your code
> and to generate the release - that is a good idea. But isn't this an
> overkill in the case of the context here? org (and emacs) should be
> stable enough to tangle the same .el file from an .org file
> (irrespective of whitespace and comments which do not influence the
> functional aspects).

Perhaps. The third alternative that for some inexplicable reason that
I failed to include was the generation of a "light weight" .emacs.el
that I use exclusively for tangling. When I configure my .emacs.el I
build two of them, one for doing everything, and one just for
tangling. I had to do so because an unrelated package that I use was
screwing up org's export. Indeed things are probably stable enough, I
just have been burned enough on other software systems that I at least
have to worry about it :).

Re: Writing .el files for org in org?

[Thorsten Jolitz]

Rainer M Krug <Rainer@krugs.de> writes:

Hi Rainer, 

> But as I am struggling with elisp, I would like to put the ob-R.el file
> into an org file which is then tangled into the ob-R.el file.

again, this is the main use case for outshine & outorg. 

They work with old-school and outshine (= outcommented org-mode)
headlines, so you just have to structure ob-R.el with some headlines,
either like this:

,--------------
| ;;; Level 1
| ;;;; Level 2
`--------------

or like this

,---------------
| ;; * Level 1
| ;; ** Level 2
`---------------

(just like you structure an Org file) and then you can switch between
emacs-lisp-mode and org-mode with

,-----------------------------
| M-# M-# (outorg-edit-as-org)
`-----------------------------

and 

,---------------------------------
| M-# (outorg-copy-edits-and-exit)
`---------------------------------

Org-mode and emacs-lisp-mode thus become two different views on the same
(well-structured) file, and you can easily switch between them. 

-- 
cheers,
Thorsten

Re: Writing .el files for org in org?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

Hi Thorsten

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
> Hi Rainer, 
>
>> But as I am struggling with elisp, I would like to put the ob-R.el file
>> into an org file which is then tangled into the ob-R.el file.
>
> again, this is the main use case for outshine & outorg. 
>
> They work with old-school and outshine (= outcommented org-mode)
> headlines, so you just have to structure ob-R.el with some headlines,
> either like this:
>
> ,--------------
> | ;;; Level 1
> | ;;;; Level 2
> `--------------
>
> or like this
>
> ,---------------
> | ;; * Level 1
> | ;; ** Level 2
> `---------------
>
> (just like you structure an Org file) and then you can switch between
> emacs-lisp-mode and org-mode with
>
> ,-----------------------------
> | M-# M-# (outorg-edit-as-org)
> `-----------------------------
>
> and 
>
> ,---------------------------------
> | M-# (outorg-copy-edits-and-exit)
> `---------------------------------
>
> Org-mode and emacs-lisp-mode thus become two different views on the same
> (well-structured) file, and you can easily switch between them. 

I got it working - looks very nice. Definitely an option.

Thanks,

Rainer
-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]