We can generalize `org-babel-expand-src-block' and `org-babel-expand-src-block-maybe'. I am not sure about killing. We need to ask if other users are interested in such functionality. -- Ihor Radchen
Sure, uniformity in "expansion" is the ideal case. I use LOB pretty extensively, so this hack allows such uniformity along the "kill-expanded-SRC". Would you consider a patch to org-babel-expand-src
Fair point. I thought that the differences are less significant. Sure. Why not :3 Nobody guaranteed that my code is free of errors. Thanks! You are probably right. Even though killed buffer objects m
Hi Ihor, Thanks for the review. Except for one line expressions, GHCi inputs and haskell modules are two different things. I doubt there will be much to share; that's why I've focused from the start
Do I understand correctly that you are trying to get #+calls to LOB blocks expanded as usual via org-babel-expand-src-block? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org
Thanks for the update! I can see that you limited the tests scope to :session blocks. Would it be possible to extend the existing tests to :compile yes case? behaviour should be similar with or witho
Hi orgmode, I thought it would be nice share a little excursion into babel's code expansion; nothing groundbreaking, and nobody asked, but it may address a more comprehensive tangling, or maybe just
Not each of these. AFAIU, :cmd header property in ob-screen defines which shell to use. Knowing shell name, you can deduce the function name to be used for variable assignments. See how it is done in
Then, I suggest to not actually write things on the disk. Instead, we can augment `org-edit-src-save' to write on disk depending on some customization (with values t, nil, and 'ask). That customizati
Fixed on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1966a7a8a8a2934443f24ca9c968a4eba09c3650 I documented ":eval yes". strip-export value is actually used, but I feel that
Hello Charles & William, You are correct, my R skills are _very_ rusty. I did not know of org-babel-expand-src-block, thanks for the pointer. Very useful. Thanks William, that got me going in the rig
[snip] [snip] data.frame($data) is not valid R syntax. If you are new to R doing some tutorials will help. I suggest you use C-c C-v C-v (org-babel-expand-src-block) to see what the R code is and de
Thanks for the information! That was really helpful. I retrieved some information from that post and wrote the following function.I would really appreciate if someone could give me some feedback on t
Hi, I have been using org-mode for almost three years and I loved it so much that I started working on a literate programming tool based on it. One particular technique that I use is having multiple
I'm not sure about this one. - I often have multiple src blocks which make up one final script once tangled. When editing these blocks, I don't want a shebang line for each of them. - Would this work
Well, why exactly Racket people decided to introduce the #lang directive in such a way that it looks like a shell comment or a shebang line seems to elude my understanding. (declare :lang 'whatever),
Hi Vladimir, I have encountered similar issues with wanting to have a racket exactly which #lang it is working with. I haven't found a good solution. One issue with embedding the shebang when editing
So, my point is the following. A shebang is an almost universally accepted way to specify which interpreter should be used for code evaluation. In the ob-core.el, at line 787, the function called org