Immanuel,
my take
> - Not possible to tangle all code going to a specified file
i'm not sure what this means.
> - Not possible to add line directives without major surgery
yes, that would be a problem (... if i were programming in,
e.g., C, etc., so *is* for other people).
> - Not all
I think the org way of tangling just doesn't work well for compiled languages.
Here are some reasons:
- Not possible to tangle all code going to a specified file
- Not possible to add line directives without major surgery
- Not all language modes do the correct thing
- No way to prevent
TRS-80 writes:
> Therefore, any stuff I plan on releasing publicly, I do not do in
> literate style (JMHO). However if you are dead set on doing literate
> paradigm, then maybe my experience is invalid for your use-case.
My experience is that literate style works very well for tutorials, but
On 2020-10-15 14:11, Greg Minshall wrote:
if anyone has any techniques they've used, liked (or hated), i'd
love to hear.
I am someone who keeps my Emacs config in a literate style in blocks
within an Orgmode outline. And I enjoy it!
However I somewhat recently came across a project that was
Tom,
thanks very much for your very detailed analysis and explanation of the
issues you've had. it's taken me this long to read through it
carefully.
the issues with python source blocks [C-c C-c] versus [C-c C-v C-t] are
in fact unfortunate, as it does make it hard to develop without lots of
Hi Greg,
Great question. This came out a bit longer than I anticipated since I
wrote up a couple of relevant workflows. Sync between org source
blocks and tangled code is something that I think needs improvement. I
have covered the difference in semantics between tangled code and
babel evaluated
Hi Greg,
Just one little thing that occurs to me, for accepting PRs if you
add
the header arg (globally would probably be best) :comments link
That with M-x org-babel-detangle should help with accepting PRs.
Hope that helps,
Timothy.
Greg Minshall writes:
hi. i apologize if this has
Hi Greg,
What I do with my Elvish modules (https://github.com/zzamboni/elvish-modules
, https://github.com/zzamboni/elvish-completions) is to just include the
Org files together with the tangled .elv files.
--Diego
On Thu, Oct 15, 2020 at 8:28 PM Greg Minshall wrote:
> hi. i apologize if
On Thursday, 15 Oct 2020 at 21:11, Greg Minshall wrote:
> i can "build" whatever files are needed to release the package. but,
> it's nice to be able to let people look at the sources, maybe submit
> 'pull requests', etc.
I have recently done this with a Julia project which I make available at
There is no great answer I am aware of. However, I will sometimes
generate a markdown version of the source so that at least non-emacs
users have a slightly better chance of being able to view the source in
a more format friendly manner than a 'raw' org file. However, pull
requests and the like
hi. i apologize if this has been asked before (especially if by me).
but, since i had a question recently about Org Src... buffers, this came
up.
i'm wondering what people do who want to release a non-emacs'y package
(an R package, say, or ...), and who did their development "from within"
a .org
11 matches
Mail list logo
