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), at least to me, seems much more lispy, and even (read) able by a standard reader (which could later be switched to a different mode).
>because the shebang line will not actually be included when executing the code How so? I never had problems using shebangs in my code. They seem to be prepended to the autogenerated files in /tmp/org-* just fine (in some other function). >due to the addition of a prologue section When does this happen? :prologue seems to be already included in the 'expanded variable. >It also becomes necessary to remove the shebang line from the edit buffer C-c C-v C-v does not make an edit buffer. It expands the buffer for a preview. I never suggested to prepend a shebang to the C-' buffer. In fact, saving the C-c C-v C-v buffer is the only reasonable thing you can do to it. Editing it makes no direct sense, because expansion is a many-to-one process, and you cannot "unexpand" the buffer (without evil diff trickery at least). >the need to keep what will be run by org babel in line This actually _is_ about keeping the two things in line. When evaluating a noweb-enabled block, and in fact, any block, org already prepends the :shebang value. I'm just suggesting to make the preview consistent On Thu, 10 Sep 2020 at 15:11, Tom Gillespie <tgb...@gmail.com> wrote: > > 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 > > -- Yours sincerely, Vladimir Nikishkin
