Hi Vladimir, I have encountered similar issues with wanting to have a racket #lang line included in a tangled block while also allowing org to know exactly which #lang it is working with. I haven't found a good solution. One issue with embedding the shebang when editing a buffer is that it is very likely to cause confusion because the shebang line will not actually be included when executing the code, or if it was included then there is a reasonable possibility that in some cases it would not be included as the first line due to the addition of a prologue section. It also becomes necessary to remove the shebang line from the edit buffer, which means you have to know which shebang lines were added automatically and which were not. Further, the need to keep what will be run by org babel in line with what is shown via these various views makes it seem unlikely that this should be implemented as default behavior. I have a long email that touches on these issues in the works for after the 9.4 release, so thank you for providing an excellent example. It seems like one possible solution for your workflow would be to advise org-babel-expand-src-block to insert the shebang. Best, Tom
On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin <lockyw...@gmail.com> wrote: > > 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-babel-expand-src-block makes a buffer out of the noweb-expanded > code. > (I am working with org 20200907) > > The sexp is looking like this: > > (org-edit-src-code > expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) > > I suggest replacing this sexp with > > (org-edit-src-code > (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " > ]*")) > > This way the expanded buffer would respect the shebang, and the > resulting buffer would be saveable as a runnable file. > > I suspect that the second branch of the (if) should be left as it is, > because non-interactive usage probably means that the code will be > used later as a part of something, and therefore does not need a > shebang. > > Vlad > > On Sat, 5 Sep 2020 at 15:13, Bastien <b...@gnu.org> wrote: > > > > Vladimir Nikishkin <lockyw...@gmail.com> writes: > > > > > I'll try to do one this week, but I can't submit a patch officially > > > because of my employer being staunchly against signing the copyright > > > disclaimer. > > > > :/ > > > > So please just give directions on what to modify and how, and that'd > > be enough for someone (probably me) to get started. > > > > Thanks! > > > > -- > > Bastien > > > > -- > Yours sincerely, Vladimir Nikishkin >
