Skip to content
This repository has been archived by the owner on Sep 17, 2022. It is now read-only.

Classic tangle/weave support a la org/babel-mode #119

Open
7v0lk0v opened this issue Oct 23, 2021 · 2 comments
Open

Classic tangle/weave support a la org/babel-mode #119

7v0lk0v opened this issue Oct 23, 2021 · 2 comments

Comments

@7v0lk0v
Copy link

7v0lk0v commented Oct 23, 2021

Hello, I'd like to write something like my-app.html.pm and produce main.c and util.c for example, as well as my-app.html - I'm sure this is possible but to my surprise have not been able to find any mention of this on the web (I'm not happy with having to write main.poly.pm and utils.poly.pm, etc).

If anyone's done this I'd be delighted to see the implementation or if anyone can offer me a head start.

Something like ◊code[#:tangle "main.c"]{int main () {return 0;}} - extracting these is the easy part but I'm not sure what is the correct place to add the racket code to extract them and write the output files - template.html? Or perhaps add a root tag function to pollen.rkt? I guess either would work but I'm sure there's a 'right' way to achieve this.

In any case the above approach raises the concern that the pollen server will be oblivious to these side-effect files - but it would be nice if they appeared as per usual in the web listing (and what file generated them).

Thank you for this awesome project!

@mbutterick
Copy link
Owner

I’m not clear why you’re ruling out separate source files. I would make main.c.pp, utils.c.pp etc. and have them extract the appropriate code tags from my-app.html.pm (or wherever). Then it works well with the project server, and raco pollen render, and make, etc.

@7v0lk0v
Copy link
Author

7v0lk0v commented Oct 24, 2021

I see it as a step backwards or sideways - you wouldn't write object file templates by hand for every source file you may have; this is similar.

It's also less flexible and forces you to maintain two ends of the same process. Additionally I intend to inject the same, or slightly modified, code and comments into multiple output files - which means I would have to change the html.pm file and then also each c.pp that may be affected - it's the beginnings of a maintenance nightmare.

I foresee many more issues, but ultimately that's just not the way I want to do things, or how my brain works, and feels like a big handicap in my pursuit of literate programming nirvana.

But your suggestion, which I was blind to, is at least better than using poly files - an idea I hated because it forces my documentation to take on an unnatural form dictated by the code organisation.

Perhaps I can generate those .c.pp files from .html.pm - I think I've seen someone here asking about generating/splitting multiple .pm files from one? Seems reasonable/doable.

If that's possible then I guess it would solve everything and works the way the server expects. I could then use the pdf example to trigger compilation of those artifact .c.pp files whenever the .html.pm is compiled - or am I dreaming?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants