Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>>> -  b c d e
>>> +  b4 c d e
>>
>> Is there any specific reason for this change?
>
> This is to ensure that the notes use the correct duration in 
> arrange-mode. 4 is the default duration and is carried over until 
> a new value is added, in this case c1. 1 is then carried over 
> making all subsequent "e"s have a value of 1, which is incorrect.

I see.
For future, please make sure to document every change in the commit
message. Or future readers might be confused about the purpose.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Dr. Arne Babenhauserheide]

Jonathan Gregory  writes:

> On 20 Aug 2023, Ihor Radchenko wrote:
>
>> Jonathan Gregory  writes:
>>
>>> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>>>
>>> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2
>>
>>> -  b c d e
>>> +  b4 c d e
>>
>> Is there any specific reason for this change?
>
> This is to ensure that the notes use the correct duration in 
> arrange-mode. 4 is the default duration and is carried over until 
> a new value is added, in this case c1. 1 is then carried over 
> making all subsequent "e"s have a value of 1, which is incorrect.

This looks safe to me. Omitting the duration in the next line is a
mistake I made a few times, so I think it’s a good change to have.

Could you add a comment before the prologue-line
#+PROPERTY: header-args:lilypond :prologue (org-babel-ref-resolve "settings[]")
that this uses the source-block named settings?

Calling org-babel-ref-resolve directly there is something I have not
seen before so I think it won’t be obvious from the documentation.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 20 Aug 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


ob-doc-lilypond.html looks good, but I changed lilypond.org in:

https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2



-  b c d e
+  b4 c d e


Is there any specific reason for this change?


This is to ensure that the notes use the correct duration in 
arrange-mode. 4 is the default duration and is carried over until 
a new value is added, in this case c1. 1 is then carried over 
making all subsequent "e"s have a value of 1, which is incorrect.


#+begin_src lilypond
{
 b c c c c1
}
#+end_src

#+begin_src lilypond
{
 e e e e f1
}
#+end_src

In basic-mode it makes no difference, but that's assuming the 
default value never changes. BTW I prefer inline-mode over 
basic-mode, but I'll leave that for a future time.


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>
> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2

> -  b c d e
> +  b4 c d e

Is there any specific reason for this change?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 11 Aug 2023, Ihor Radchenko wrote:

And do I understand correctly that no changes in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
are needed?


ob-doc-lilypond.html looks good, but I changed lilypond.org in:

https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2

--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Ok. Would you mind adding a commit message, as described in 
>> https://orgmode.org/worg/org-contribute.html#first-patch?
>
> Patch attached. I also attached a test file.

Thanks!
Applied, onto main.
Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f78a3c2bd

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor,

On 11 Aug 2023, Ihor Radchenko wrote:

Ok. Would you mind adding a commit message, as described in 
https://orgmode.org/worg/org-contribute.html#first-patch?


Patch attached. I also attached a test file.

And do I understand correctly that no changes in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
are needed?


Probably not, but I'll check.

--
Jonathan
commit 8916c9ebbefb1b1d448e0e39998f9b9a3b054680
Author: Jonathan Gregory 
Date:   Wed Aug 16 09:47:09 2023 -0300

lisp/ob-lilypond.el: Prevent full page results in basic-mode

* ob-lilypond.el (org-babel-lilypond-paper-settings): New variable.
Link: https://list.orgmode.org/87a5w15jur.fsf@localhost/

TINYCHANGE

diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 9693b89e2..ad8371c5f 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -175,31 +175,51 @@ specific arguments to =org-babel-tangle=."
   (if (org-babel-tangle nil "yes" "lilypond")
   (org-babel-lilypond-execute-tangled-ly) nil))
 
+;; https://lilypond.org/doc/v2.24/Documentation/usage/other-programs
+(defvar org-babel-lilypond-paper-settings
+  "#(if (ly:get-option 'use-paper-size-for-page)
+(begin (ly:set-option 'use-paper-size-for-page #f)
+   (ly:set-option 'tall-page-formats '%s)))
+\\paper {
+  indent=0\\mm
+  tagline=\"\"
+  oddFooterMarkup=##f
+  oddHeaderMarkup=##f
+  bookTitleMarkup=##f
+  scoreTitleMarkup=##f
+}\n"
+  "The paper settings required to generate music fragments.
+They are needed for mixing music and text in basic-mode.")
+
 (defun org-babel-lilypond-process-basic (body params)
   "Execute a lilypond block in basic mode."
   (let* ((out-file (cdr (assq :file params)))
+ (file-type (file-name-extension out-file))
 	 (cmdline (or (cdr (assq :cmdline params))
 		  ""))
 	 (in-file (org-babel-temp-file "lilypond-")))
 
 (with-temp-file in-file
-  (insert (org-babel-expand-body:generic body params)))
+  (insert
+   (format org-babel-lilypond-paper-settings file-type)
+   (org-babel-expand-body:generic body params)))
 (org-babel-eval
  (concat
   org-babel-lilypond-ly-command
   " -dbackend=eps "
   "-dno-gs-load-fonts "
   "-dinclude-eps-fonts "
-  (or (cdr (assoc (file-name-extension out-file)
-		  '(("pdf" . "--pdf ")
-			("ps" . "--ps ")
-			("png" . "--png "
+  (or (assoc-default file-type
+ '(("pdf" . "--pdf ")
+			   ("eps" . "--eps ")))
 	  "--png ")
   "--output="
   (file-name-sans-extension out-file)
   " "
   cmdline
-  in-file) "")) nil)
+  in-file)
+ ""))
+  nil)
 
 (defun org-babel-prep-session:lilypond (_session _params)
   "Return an error because LilyPond exporter does not support sessions."
#+title: Test
#+PROPERTY: header-args:lilypond :noweb yes :exports results
#+PROPERTY: header-args:lilypond :prologue (org-babel-ref-resolve "settings[]")

Some text.

#+begin_src lilypond :file myfile.pdf
\score {
  \new Staff \relative c' {
\tempo 4 = 160
c4 e g b
c4 b d c
\tempo 4 = 96
d,4 fis a cis
d4 cis e d
  }
  \layout { }
  \midi { }
}
#+end_src

#+results:
[[file:myfile.pdf]]

Click [[file:myfile.midi][here]] to listen to the MIDI output.

#+name: settings
#+begin_src lilypond :exports none
\version "2.24.1"
% More lilypond settings here...
#+end_src

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Henrik Frisk  writes:

>> ob-lilypond is distributed together with Org mode
> ...
> I know it is and I didn't know it was maintained so I've kept using this
> old version updating it myself. In that case you can probably safely ignore
> what I wrote below. Great to know it's part of org...

It is a bit of exaggeration to say that it is maintained, unfortunately.
The file does not currently have a dedicated maintainer and regular Org
contributors are not very familiar with lilypond...
So, we mostly fix the Elisp side bugs, keeping things in working state
(hopefully).

Luckily, we do not have many bug reports related to ob-lilypond.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

On Tue, Aug 15, 2023, 12:41 PM Ihor Radchenko  wrote:

> Henrik Frisk  writes:
>
> > Sorry for being late in this discussion. As a user of ob-lilypond I'm
> very
> > happy about these changes. On my last install, as well as my current I
> have
> > had to change the following:
> >
> > (org-babel-get-header params :var) which appears to be outdated, to:
> >
> > (org-babel--get-vars params)
>
> There is no such function `org-babel-get-header'.
>
> > in the version of ob-lilypond.el from here:
> > https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el.
> Which
> > version of the file are you patching now?
>
> ob-lilypond is distributed together with Org mode
> (
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-lilypond.el
> ).
> And you are looking at 12 years old early version of the library.
>

I know it is and I didn't know it was maintained so I've kept using this
old version updating it myself. In that case you can probably safely ignore
what I wrote below. Great to know it's part of org...

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Henrik Frisk  writes:

> Sorry for being late in this discussion. As a user of ob-lilypond I'm very
> happy about these changes. On my last install, as well as my current I have
> had to change the following:
>
> (org-babel-get-header params :var) which appears to be outdated, to:
>
> (org-babel--get-vars params)

There is no such function `org-babel-get-header'.

> in the version of ob-lilypond.el from here:
> https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el. Which
> version of the file are you patching now?

ob-lilypond is distributed together with Org mode
(https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-lilypond.el).
And you are looking at 12 years old early version of the library.

> Another request would be to have the variables ly-XXX-pdf-path and
> ly-XXX-midi-path settable, or, perhaps, read from the lilypond settings of
> corresponding variables. I'm not an elisp programmer but I could look into
> that if it's of interest.

Sorry, but I am not sure what you are talking about. May you elaborate?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den fre 11 aug. 2023 kl 09:04 skrev Ihor Radchenko :

> Jonathan Gregory  writes:
>
> >> Jonathan, do you think that your original patch is still what
> >> you want to get merged?
> >
> > Yes, the one I sent on 20 Jul 2023. I haven't had any issues with
> > it so far.
>
> Ok. Would you mind adding a commit message, as described in
> https://orgmode.org/worg/org-contribute.html#first-patch?
>
> And do I understand correctly that no changes in
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
> are needed?
>
> Sorry for being late in this discussion. As a user of ob-lilypond I'm very
happy about these changes. On my last install, as well as my current I have
had to change the following:

(org-babel-get-header params :var) which appears to be outdated, to:

(org-babel--get-vars params)

in the version of ob-lilypond.el from here:
https://github.com/mjago/ob-lilypond/blob/master/lisp/ob-lilypond.el. Which
version of the file are you patching now?

Another request would be to have the variables ly-XXX-pdf-path and
ly-XXX-midi-path settable, or, perhaps, read from the lilypond settings of
corresponding variables. I'm not an elisp programmer but I could look into
that if it's of interest.

/Henrik

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Jonathan, do you think that your original patch is still what 
>> you want to get merged?
>
> Yes, the one I sent on 20 Jul 2023. I haven't had any issues with 
> it so far.

Ok. Would you mind adding a commit message, as described in
https://orgmode.org/worg/org-contribute.html#first-patch?

And do I understand correctly that no changes in
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
are needed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor,

On 08 Aug 2023, Ihor Radchenko wrote:

Jonathan, do you think that your original patch is still what 
you want to get merged?


Yes, the one I sent on 20 Jul 2023. I haven't had any issues with 
it so far.



--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> On 31 Jul 2023, Ihor Radchenko wrote:
>
>> May it be possible to mix multiple \version commands? So that we 
>> declare \version for \paper and user can declare other \version 
>> for the code block body.
>
> Probably not. Wouldn't that confuse the compiler? In any case, the 
> \version number is relative to the lilypond version for which the 
> input file was written, so it's up to the user to provide that 
> information.

Jonathan, do you think that your original patch is still what you want
to get merged? Or do you want to update it?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 31 Jul 2023, Ihor Radchenko wrote:

May it be possible to mix multiple \version commands? So that we 
declare \version for \paper and user can declare other \version 
for the code block body.


Probably not. Wouldn't that confuse the compiler? In any case, the 
\version number is relative to the lilypond version for which the 
input file was written, so it's up to the user to provide that 
information.



--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> For example, python2/3 or MathJax4,4- were breaking and some 
>> people were relying on legacy code. So, we had to provide some 
>> extra versions checks and toggles on Org side as well.
>
> We're talking about different things here. Lilypond needs the 
> \version to upgrade the syntax. IIUC this makes it possible for a 
> future version to compile input code correctly, even if it was 
> written in a previous version (which may have used some different 
> syntax), as long as the \version is included in the main file. 
> There's even a `convert-ly` command to make upgrades based on the 
> \version, so I'd suggest moving only \paper settings to the 
> ob-lilypond file and keeping the \version in the source file.

May it be possible to mix multiple \version commands?
So that we declare \version for \paper and user can declare other
\version for the code block body.

>> #+begin_src emacs-lisp :prologue (org-babel-ref-resolve 
>> "test[]")
>> (+ 1 2)
>> #+end_src
>>
>> It think that it will be logical to add reference resolution to 
>> :prologue/:epilogue. I will see what I can do. (I may need to 
>> look through which header args are resolved and which are not - 
>> there seems to be no consistency)
>
> What do you mean by reference resolution?

#+begin_src emacs-lisp :prologue test[]

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 29 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:

The basic-mode term is not very helpful. Perhaps 
[inline/cropped/embedded]-mode would have been more descriptive 
in terms of what it does.


Sounds reasonable. I like "inline-mode", although no strong 
opinion.


I like it too.

... Anyway, hard-coding paper settings would simplify things a 
bit, but I'm not sure that hard-coding the version is a good 
idea and may produce errors with older installations.


Do people have reasons to use older versions even when they 
could use the newest?


Probably not.

For example, python2/3 or MathJax4,4- were breaking and some 
people were relying on legacy code. So, we had to provide some 
extra versions checks and toggles on Org side as well.


We're talking about different things here. Lilypond needs the 
\version to upgrade the syntax. IIUC this makes it possible for a 
future version to compile input code correctly, even if it was 
written in a previous version (which may have used some different 
syntax), as long as the \version is included in the main file. 
There's even a `convert-ly` command to make upgrades based on the 
\version, so I'd suggest moving only \paper settings to the 
ob-lilypond file and keeping the \version in the source file.



#+name: test
#+begin_src emacs-lisp
(message "This is test")
#+end_src

#+begin_src emacs-lisp :prologue (org-sbe test)
(+ 1 2)
#+end_src


Correction: `org-sbe' will execute src block. So, my example is 
not completely accurate. Getting src block body is still doable, 
but a tiny bit more tricky:


#+begin_src emacs-lisp :prologue (org-babel-ref-resolve 
"test[]")

(+ 1 2)
#+end_src

It think that it will be logical to add reference resolution to 
:prologue/:epilogue. I will see what I can do. (I may need to 
look through which header args are resolved and which are not - 
there seems to be no consistency)


What do you mean by reference resolution? FWIW :prologue 
(org-babel-ref-resolve "test[]") works even if "test" is a 
lilypond source block. This is good. Again, no need to add 
<> to all lilypond blocks.


Interesting. I didn't know about org-sbe. Looks useful. I'll 
look into it when I find time. In the meantime, we can use:


#+PROPERTY: header-args:lilypond :noweb yes :exports results 
:prologue (org-sbe version-and-paper)


(This will work because ob-org, by accident, produces body as 
result of evaluation, with default header args)


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> The basic-mode term is not very helpful. Perhaps 
> [inline/cropped/embedded]-mode would have been more descriptive in 
> terms of what it does.

Sounds reasonable. I like "inline-mode", although no strong opinion.

> ... Anyway, hard-coding paper settings would 
> simplify things a bit, but I'm not sure that hard-coding the 
> version is a good idea and may produce errors with older 
> installations.

Do people have reasons to use older versions even when they could use
the newest?

For example, python2/3 or MathJax4,4- were breaking and some people were
relying on legacy code. So, we had to provide some extra versions checks
and toggles on Org side as well.

>> #+name: test
>> #+begin_src emacs-lisp
>> (message "This is test")
>> #+end_src
>>
>> #+begin_src emacs-lisp :prologue (org-sbe test)
>> (+ 1 2)
>> #+end_src

Correction: `org-sbe' will execute src block. So, my example is not
completely accurate. Getting src block body is still doable, but a tiny
bit more tricky:

#+begin_src emacs-lisp :prologue (org-babel-ref-resolve "test[]")
(+ 1 2)
#+end_src

It think that it will be logical to add reference resolution to
:prologue/:epilogue. I will see what I can do.
(I may need to look through which header args are resolved and which are
not - there seems to be no consistency)

> Interesting. I didn't know about org-sbe. Looks useful. I'll look 
> into it when I find time. In the meantime, we can use:
>
> #+PROPERTY: header-args:lilypond :noweb yes :exports results 
>  :prologue (org-sbe version-and-paper)

(This will work because ob-org, by accident, produces body as result of
evaluation, with default header args)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 28 Jul 2023, Ihor Radchenko wrote:

I am slightly confused because there seems to be a need to 
define some page settings manually to get "embedded" images. In 
the examples in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org2c29903, 
there is no mention that we need to define page geometry. Yet, 
the section is claiming that base mode "can embed LilyPond 
snippets into an Org-mode file".


It is confusing, I agree, and I'm still learning as we move 
forward. I guess the question is should basic mode *always* 
generate cropped images? If the answer is yes, and it looks like 
it is, then maybe we should include paper settings in the 
ob-lilypond file.


The basic-mode term is not very helpful. Perhaps 
[inline/cropped/embedded]-mode would have been more descriptive in 
terms of what it does. Anyway, hard-coding paper settings would 
simplify things a bit, but I'm not sure that hard-coding the 
version is a good idea and may produce errors with older 
installations.


Noweb and babel references are not allowed in header args. And 
ob-emacs-lisp also does not support :prologue.


I see, so there's no built-in way to auto-insert a boilerplate 
without using the <<>> reference *inside* source blocks. 
Anyway, let's not worry about this for now.


There is, but you will have to use direct Elisp to get :prologue 
string:


#+name: test
#+begin_src emacs-lisp

(message "This is test")
#+end_src

#+begin_src emacs-lisp :prologue (org-sbe test)
(+ 1 2)
#+end_src


Interesting. I didn't know about org-sbe. Looks useful. I'll look 
into it when I find time. In the meantime, we can use:


#+PROPERTY: header-args:lilypond :noweb yes :exports results 
:prologue (org-sbe version-and-paper)


if we replace "lilypond" with "org" in the version-and-paper 
block. Prologue is useful also for those of us who keep their 
settings in a separate file:


#+PROPERTY: header-args:lilypond :exports results :prologue 
"\\include \"settings.ly\""


Thanks!

--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> May your please explain what is "basic mode".
>
> Basic mode is explained in 
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html. 
> In summary:
>
> With basic-mode you can embed LilyPond snippets into an Org-mode 
> file, compile and export them using typical Org-mode commands 
> (such as C-c C-e l p for PDF export). This is useful if you want 
> to mix blocks of LilyPond-generated score with text, and perhaps 
> other images to export to LaTeX, Docbook, PDF, or HTML.

I am slightly confused because there seems to be a need to define some
page settings manually to get "embedded" images. In the examples in
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org2c29903,
there is no mention that we need to define page geometry. Yet, the
section is claiming that base mode "can embed LilyPond snippets into an
Org-mode file".

What am I missing?

>> And what about users who do want a full page?
>
> In that case the user would use "arrange mode", which is also 
> explained in the ob-doc-lilypond.html page.

Thanks for the clarification!

>> Noweb and babel references are not allowed in header args. And 
>> ob-emacs-lisp also does not support :prologue.
>
> I see, so there's no built-in way to auto-insert a boilerplate 
> without using the <<>> reference *inside* source blocks. Anyway, 
> let's not worry about this for now.

There is, but you will have to use direct Elisp to get :prologue string:

#+name: test
#+begin_src emacs-lisp
(message "This is test")
#+end_src

#+begin_src emacs-lisp :prologue (org-sbe test)
(+ 1 2)
#+end_src

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 27 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:

Ok. That fix has been already installed. 
https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


To the extent of the lilypond.org file, yes, but only if the 
output is a PDF. My suggestion is to revert that commit and 
incorporate the changes into ob-lilypond.


Then, may you elaborate what purpose the changes are going to 
serve? Automatic page sizing? Automatic page settings?


Bug fix.

The purpose of the patch was to fix the problem described in 
https://masto.ai/@rfc1149/110674961710491363. I wasn't trying 
to introduce anything new.


If we want to add boilerplate code to ob-lilypond, it does sound 
like introducing something new. Again, I feel confused. Please, 
explain in more details what you want to archive in terms of 
functionality.


No, the patch is a bug fix. There are no changes for the user. 
Prior to the bug, we were able generate a "cropped" image when 
running:


#+begin_src lilypond :file myfile.pdf
\version "2.20"
\paper { tagline="" }
{
 c' e' g' e'
}
#+end_src

This is no longer the case, hence the patch.

No, the ob-lilypond patch is needed. It allows users to 
generate music fragments (as opposed to a full page) in basic 
mode using pdf, eps, and png.


May your please explain what is "basic mode".


Basic mode is explained in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html. 
In summary:


With basic-mode you can embed LilyPond snippets into an Org-mode 
file, compile and export them using typical Org-mode commands 
(such as C-c C-e l p for PDF export). This is useful if you want 
to mix blocks of LilyPond-generated score with text, and perhaps 
other images to export to LaTeX, Docbook, PDF, or HTML.



And what about users who do want a full page?


In that case the user would use "arrange mode", which is also 
explained in the ob-doc-lilypond.html page. Try running the source 
block example above with arrange-mode enabled using M-x 
org-babel-lilypond-toggle-arrange-mode. To quote from that page:


With arrange-mode you can develop complete pieces of score whilst 
organizing sections of the piece using typical literate 
programming techniques. This allows you to assemble scores 
programatically by using tables to store information among other 
methods.


Noweb and babel references are not allowed in header args. And 
ob-emacs-lisp also does not support :prologue.


I see, so there's no built-in way to auto-insert a boilerplate 
without using the <<>> reference *inside* source blocks. Anyway, 
let's not worry about this for now.



--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Ok. That fix has been already installed. 
>> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92
>
> To the extent of the lilypond.org file, yes, but only if the 
> output is a PDF. My suggestion is to revert that commit and 
> incorporate the changes into ob-lilypond.

Then, may you elaborate what purpose the changes are going to serve?
Automatic page sizing? Automatic page settings?

> The purpose of the patch was to fix the problem described in 
> https://masto.ai/@rfc1149/110674961710491363. I wasn't trying to 
> introduce anything new.

If we want to add boilerplate code to ob-lilypond, it does sound like
introducing something new. Again, I feel confused. Please, explain in
more details what you want to archive in terms of functionality.

> No, the ob-lilypond patch is needed. It allows users to generate 
> music fragments (as opposed to a full page) in basic mode using 
> pdf, eps, and png.

May your please explain what is "basic mode".
And what about users who do want a full page?

>> There is :prologue standard header argument. However, it is 
>> currently not supported by ob-lilypond. (which is a bug)
>
> Can you show me how that's done in elisp? I would expect the last 
> block to output "foobar".
>
> #+begin_src elisp :noweb-ref test
> (setq x "foo" y "bar")
> #+end_src
>
> #+begin_src elisp :prologue <> :noweb yes
> (concat x y)
> #+end_src

Noweb and babel references are not allowed in header args.
And ob-emacs-lisp also does not support :prologue.

You can try

#+begin_src gnuplot :prologue set xrange [0:1]
plot x
#+end_src

or

#+begin_src gnuplot :prologue (format "set xrange [0:%d]" 11)
plot x
#+end_src

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 26 Jul 2023, Ihor Radchenko wrote:

Ok. That fix has been already installed. 
https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


To the extent of the lilypond.org file, yes, but only if the 
output is a PDF. My suggestion is to revert that commit and 
incorporate the changes into ob-lilypond.


The other patch for ob-lilypond itself does not appear to be 
necessary. I though that you are trying to extend ob-lilypond in 
that patch. If not, I still do not understand its purpose. I 
assume that it should be ignored.


No, the ob-lilypond patch is needed. It allows users to generate 
music fragments (as opposed to a full page) in basic mode using 
pdf, eps, and png.


Anyway, I can add version and paper settings as well, but those 
are user settings and I'm not sure that hard-coding them is a 
good idea. What I don't like is having to repeat 
<> everywhere. Is there a way of telling 
org-mode to insert a noweb reference from the header? Something 
like:


#+PROPERTY: header-args:lilypond :prepend <>


There is :prologue standard header argument. However, it is 
currently not supported by ob-lilypond. (which is a bug)


Can you show me how that's done in elisp? I would expect the last 
block to output "foobar".


#+begin_src elisp :noweb-ref test
(setq x "foo" y "bar")
#+end_src

#+begin_src elisp :prologue <> :noweb yes
(concat x y)
#+end_src


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> On 22 Jul 2023, Ihor Radchenko wrote:
>
>> I guess I do not fully understand what your patch is trying to 
>> achieve. I thought that the patch would make it not necessary to 
>> write some extra boilerplate code, like \version or specifying 
>> the page size.
>
> The purpose of the patch was to fix the problem described in 
> https://masto.ai/@rfc1149/110674961710491363. I wasn't trying to 
> introduce anything new.

Ok. That fix has been already installed.
https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92

The other patch for ob-lilypond itself does not appear to be necessary.
I though that you are trying to extend ob-lilypond in that patch. If
not, I still do not understand its purpose. I assume that it should be
ignored.

> Anyway, I can add version and paper settings as well, but those 
> are user settings and I'm not sure that hard-coding them is a good 
> idea. What I don't like is having to repeat <> 
> everywhere. Is there a way of telling org-mode to insert a noweb 
> reference from the header? Something like:
>
> #+PROPERTY: header-args:lilypond :prepend <>

There is :prologue standard header argument. However, it is currently
not supported by ob-lilypond. (which is a bug)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den tis 25 juli 2023 kl 19:26 skrev Jonathan Gregory :

> Hi Henrik,
>
> On 25 Jul 2023, Henrik Frisk wrote:
>
> > Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk
> > :
>
> > My bad, putting :file ionian.cropped.png only results in
> > ionian.cropped.cropped.png (as expected). Unclear why it worked
> > the first couple of times.
> >
> > /Henrik
>
> No need to crop the output. If you need png, you should use:
>
> #(ly:set-option 'tall-page-formats 'png)
>
> Makes sense, but I have to admit that I find this a bit confusing. I was
under the impression that the 'crop' option was the preferred way to
accomplish this.

Thanks for resolving this anyway!

/Henrik

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 22 Jul 2023, Ihor Radchenko wrote:

I guess I do not fully understand what your patch is trying to 
achieve. I thought that the patch would make it not necessary to 
write some extra boilerplate code, like \version or specifying 
the page size.


The purpose of the patch was to fix the problem described in 
https://masto.ai/@rfc1149/110674961710491363. I wasn't trying to 
introduce anything new.


Anyway, I can add version and paper settings as well, but those 
are user settings and I'm not sure that hard-coding them is a good 
idea. What I don't like is having to repeat <> 
everywhere. Is there a way of telling org-mode to insert a noweb 
reference from the header? Something like:


#+PROPERTY: header-args:lilypond :prepend <>


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Henrik,

On 25 Jul 2023, Henrik Frisk wrote:

Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk 
:


My bad, putting :file ionian.cropped.png only results in 
ionian.cropped.cropped.png (as expected). Unclear why it worked 
the first couple of times.


/Henrik


No need to crop the output. If you need png, you should use:

#(ly:set-option 'tall-page-formats 'png)


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk :

> Hi,
>
> I have been struggling with the same issues to but have completely missed
> this thread. I haven't tried the patch of ob-lilypond but testing the file
> https://git.sr.ht/~bzg/worg/tree/6f69d212f41bc372426dc9b4df286638fe8f2a92/item/org-contrib/babel/examples/lilypond.org
> I'm getting cropped output with pdf, but not png (generates full page).
> Also, omitting the paper stuff I still get the same cropped output wit pdf:
>
> #+begin_src lilypond :file ionian.png
>  \version "2.24.1"
> \relative c' {
>   c d e f
>   g a b c
>   b a g f
>   e d c d
>   e f g a
>   b c b a
>   g f e d
>   c1
> }
> #+end_src
>
> Adding  #(ly:set-option 'crop #t) to the file gives a cropped output in
> the file 'ionian.cropped.png' but the ionian.png is still fullpage. I was
> looking in ob-lilypond to change the outputfile name but the easy solution
> is to just give the cropped name as the :file argument:
>
> :file ionian.cropped.png
>
> Then the file is shown inline in the #+RESULT: block. This works for other
> file formats two, like pdf and eps.
>
> Here's a short version:
>
> #+begin_src lilypond :file ionian.cropped.png
>   \Version "2.24.1"
> #(ly:set-option 'crop #t)
> \relative c' {
>   c d e f
> }
> #+end_src
>
> My bad, putting :file ionian.cropped.png only results in
ionian.cropped.cropped.png (as expected). Unclear why it worked the first
couple of times.

/Henrik

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Hi,

I have been struggling with the same issues to but have completely missed
this thread. I haven't tried the patch of ob-lilypond but testing the file
https://git.sr.ht/~bzg/worg/tree/6f69d212f41bc372426dc9b4df286638fe8f2a92/item/org-contrib/babel/examples/lilypond.org
I'm getting cropped output with pdf, but not png (generates full page).
Also, omitting the paper stuff I still get the same cropped output wit pdf:

#+begin_src lilypond :file ionian.png
 \version "2.24.1"
\relative c' {
  c d e f
  g a b c
  b a g f
  e d c d
  e f g a
  b c b a
  g f e d
  c1
}
#+end_src

Adding  #(ly:set-option 'crop #t) to the file gives a cropped output in the
file 'ionian.cropped.png' but the ionian.png is still fullpage. I was
looking in ob-lilypond to change the outputfile name but the easy solution
is to just give the cropped name as the :file argument:

:file ionian.cropped.png

Then the file is shown inline in the #+RESULT: block. This works for other
file formats two, like pdf and eps.

Here's a short version:

#+begin_src lilypond :file ionian.cropped.png
  \Version "2.24.1"
#(ly:set-option 'crop #t)
\relative c' {
  c d e f
}
#+end_src

/Henrik


Den lör 22 juli 2023 kl 10:13 skrev Ihor Radchenko :

> Jonathan Gregory  writes:
>
> > On 21 Jul 2023, Ihor Radchenko wrote:
> >
> >> The png is still a full page on my side.
> >
> > That's not what I get. You're probably missing the paper settings:
> >
> > #+begin_src lilypond :exports none
> > \version "2.20"
> > \paper {
> >   indent=0\mm
> >   tagline=""
> >   line-width=170\mm
> >   oddFooterMarkup=##f
> >   oddHeaderMarkup=##f
> >   bookTitleMarkup=##f
> >   scoreTitleMarkup=##f
> > }
> > #+end_src
>
> I feel confused. Isn't you patch aiming for auto-sizing the resulting
> page to fit the music fragment?
>
> >> Also, I am getting
> >>
> >> Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
> >> Parsing...
> >> /tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version
> >> statement found, please add
> >>
> >> \version "2.24.0"
> >>
> >> which does not look necessary.
> >
> > What is not necessary? The warning is expected. Other than that
> > everything looks fine.
>
> I guess I do not fully understand what your patch is trying to achieve.
> I thought that the patch would make it not necessary to write some extra
> boilerplate code, like \version or specifying the page size.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> On 21 Jul 2023, Ihor Radchenko wrote:
>
>> The png is still a full page on my side.
>
> That's not what I get. You're probably missing the paper settings:
>
> #+begin_src lilypond :exports none
> \version "2.20"
> \paper {
>   indent=0\mm
>   tagline=""
>   line-width=170\mm
>   oddFooterMarkup=##f
>   oddHeaderMarkup=##f
>   bookTitleMarkup=##f
>   scoreTitleMarkup=##f
> }
> #+end_src

I feel confused. Isn't you patch aiming for auto-sizing the resulting
page to fit the music fragment?

>> Also, I am getting
>>
>> Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
>> Parsing...
>> /tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version 
>> statement found, please add
>>
>> \version "2.24.0"
>>
>> which does not look necessary.
>
> What is not necessary? The warning is expected. Other than that 
> everything looks fine.

I guess I do not fully understand what your patch is trying to achieve.
I thought that the patch would make it not necessary to write some extra
boilerplate code, like \version or specifying the page size.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 21 Jul 2023, Ihor Radchenko wrote:


The png is still a full page on my side.


That's not what I get. You're probably missing the paper settings:

#+begin_src lilypond :exports none
\version "2.20"
\paper {
 indent=0\mm
 tagline=""
 line-width=170\mm
 oddFooterMarkup=##f
 oddHeaderMarkup=##f
 bookTitleMarkup=##f
 scoreTitleMarkup=##f
}
#+end_src


Also, I am getting

Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
Parsing...
/tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version 
statement found, please add


\version "2.24.0"

for future compatibility
Interpreting music...[8]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `ionian2.eps'...
Converting to PNG...
Success: compilation successfully completed
[ Babel evaluation exited with code 0 ]

which does not look necessary.


What is not necessary? The warning is expected. Other than that 
everything looks fine.



--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> On 20 Jul 2023, Ihor Radchenko wrote:
>
>> With your patch, I cannot produce png output. The file is just 
>> not created: [...]
>
> You're right. Thanks for the feedback.
>
> I've made some changes and was able to produce the correct results 
> using pdf, eps, and png (tested with 2.20.0 and 2.24.1). I think 
> this gets us closer to the old behaviour, assuming there are no 
> other issues, of course.

The png is still a full page on my side.
Also, I am getting

Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
Parsing...
/tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version statement found, 
please add

\version "2.24.0"

for future compatibility
Interpreting music...[8]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `ionian2.eps'...
Converting to PNG...
Success: compilation successfully completed
[ Babel evaluation exited with code 0 ]

which does not look necessary.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 20 Jul 2023, Ihor Radchenko wrote:

With your patch, I cannot produce png output. The file is just 
not created: [...]


You're right. Thanks for the feedback.

I've made some changes and was able to produce the correct results 
using pdf, eps, and png (tested with 2.20.0 and 2.24.1). I think 
this gets us closer to the old behaviour, assuming there are no 
other issues, of course.



--
Jonathan
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 9693b89e2..8533cd8c7 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -178,28 +178,39 @@ specific arguments to =org-babel-tangle=."
 (defun org-babel-lilypond-process-basic (body params)
   "Execute a lilypond block in basic mode."
   (let* ((out-file (cdr (assq :file params)))
+ (file-type (file-name-extension out-file))
 	 (cmdline (or (cdr (assq :cmdline params))
 		  ""))
 	 (in-file (org-babel-temp-file "lilypond-")))
 
 (with-temp-file in-file
-  (insert (org-babel-expand-body:generic body params)))
+  ;; To create music fragments suitable for mixing music and text,
+  ;; newer versions of lilypond require setting at least the
+  ;; following two variables introduced in version 2.22. See:
+  ;; https://lilypond.org/doc/v2.24/Documentation/usage/other-programs
+  (insert
+   (format "#(if (ly:get-option 'use-paper-size-for-page)
+ (begin (ly:set-option 'use-paper-size-for-page #f)
+(ly:set-option 'tall-page-formats '%s)))\n"
+   file-type)
+   (org-babel-expand-body:generic body params)))
 (org-babel-eval
  (concat
   org-babel-lilypond-ly-command
   " -dbackend=eps "
   "-dno-gs-load-fonts "
   "-dinclude-eps-fonts "
-  (or (cdr (assoc (file-name-extension out-file)
-		  '(("pdf" . "--pdf ")
-			("ps" . "--ps ")
-			("png" . "--png "
+  (or (assoc-default file-type
+ '(("pdf" . "--pdf ")
+			   ("eps" . "--eps ")))
 	  "--png ")
   "--output="
   (file-name-sans-extension out-file)
   " "
   cmdline
-  in-file) "")) nil)
+  in-file)
+ ""))
+  nil)
 
 (defun org-babel-prep-session:lilypond (_session _params)
   "Return an error because LilyPond exporter does not support sessions."

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> I do not mind. But remember that we are talking just about an 
>> example file. What you are suggesting appears to be closer to 
>> what we might do in ob-lilypond itself, when calculating default 
>> layout.
>
> That would be even better, I agree.
>
> Can you test my patch?

With your patch, I cannot produce png output. The file is just not
created:

#+begin_src lilypond :file ionian.png
\relative c' {
  c d e f
  g a b c
  b a g f
  e d c d
  e f g a
  b c b a
  g f e d
  c1
}
#+end_src

> Command-line options are normally added to 
> `org-babel-lilypond-ly-command`, but since we're trying to set 
> variables conditionally to accommodate different versions, I don't 
> see how we can do this without using scheme. WDYT?

Your approach seems fine.
It is not uncommon for babel backends to add extra code to the src block body.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 18 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:

I also checked what will happen with future versions, and it 
looks like \version "2.24.1" actually means >=.


That's good to know.

I know version 2.20.0 works without the update, so perhaps we 
could set those variables conditionally, WDYT?


\version "2.20"
#(if (ly:get-option 'use-paper-size-for-page)
 (begin (ly:set-option 'use-paper-size-for-page #f)
(ly:set-option 'tall-page-formats 'pdf)))


I do not mind. But remember that we are talking just about an 
example file. What you are suggesting appears to be closer to 
what we might do in ob-lilypond itself, when calculating default 
layout.


That would be even better, I agree.

Can you test my patch?

Command-line options are normally added to 
`org-babel-lilypond-ly-command`, but since we're trying to set 
variables conditionally to accommodate different versions, I don't 
see how we can do this without using scheme. WDYT?


Side note: ob-lilypond even has 
`org-babel-lilypond-toggle-midi-play' that plays sound 
corresponding to the lilypond source. Pretty cool, especially in 
the context of the discussion about non-textual output types in 
babel. 
https://list.orgmode.org/orgmode/87ttu95xst.fsf@localhost/


Sure, I'll think about adding a MIDI example as well.


--
Jonathan
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 9693b89e2..3cbdd2b27 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -183,6 +183,12 @@ specific arguments to =org-babel-tangle=."
 	 (in-file (org-babel-temp-file "lilypond-")))
 
 (with-temp-file in-file
+  ;; To create music fragments suitable for mixing music and text,
+  ;; newer versions of lilypond require setting at least the
+  ;; following two variables introduced in version 2.22.
+  (insert "#(if (ly:get-option 'use-paper-size-for-page)
+(begin (ly:set-option 'use-paper-size-for-page #f)
+(ly:set-option 'tall-page-formats 'pdf)))\n")
   (insert (org-babel-expand-body:generic body params)))
 (org-babel-eval
  (concat
@@ -199,7 +205,9 @@ specific arguments to =org-babel-tangle=."
   (file-name-sans-extension out-file)
   " "
   cmdline
-  in-file) "")) nil)
+  in-file)
+ ""))
+  nil)
 
 (defun org-babel-prep-session:lilypond (_session _params)
   "Return an error because LilyPond exporter does not support sessions."

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> I also checked what will happen with future versions, and it 
>> looks like \version "2.24.1" actually means >=.
>
> That's good to know.
>
> I know version 2.20.0 works without the update, so perhaps we 
> could set those variables conditionally, WDYT?
>
> \version "2.20"
> #(if (ly:get-option 'use-paper-size-for-page)
>  (begin (ly:set-option 'use-paper-size-for-page #f)
> (ly:set-option 'tall-page-formats 'pdf)))

I do not mind.
But remember that we are talking just about an example file.
What you are suggesting appears to be closer to what we might do in
ob-lilypond itself, when calculating default layout.

Side note: ob-lilypond even has `org-babel-lilypond-toggle-midi-play'
that plays sound corresponding to the lilypond source. Pretty cool,
especially in the context of the discussion about non-textual output
types in babel. https://list.orgmode.org/orgmode/87ttu95xst.fsf@localhost/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor,

On 14 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


Looks like this on my side as well.


Given the feedback, I went ahead and changed the lilypond.org 
file:


https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


Thanks! It would be even nicer if we allowed 
https://packages.debian.org/buster/lilypond (2.19.81) or at 
least https://packages.ubuntu.com/focal/lilypond (2.20.0).


I also checked what will happen with future versions, and it 
looks like \version "2.24.1" actually means >=.


That's good to know.

I know version 2.20.0 works without the update, so perhaps we 
could set those variables conditionally, WDYT?


\version "2.20"
#(if (ly:get-option 'use-paper-size-for-page)
(begin (ly:set-option 'use-paper-size-for-page #f)
   (ly:set-option 'tall-page-formats 'pdf)))


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Looks like this on my side as well.
>
> Given the feedback, I went ahead and changed the lilypond.org 
> file:
>
> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92

Thanks!
It would be even nicer if we allowed
https://packages.debian.org/buster/lilypond (2.19.81) or at least
https://packages.ubuntu.com/focal/lilypond (2.20.0).

I also checked what will happen with future versions, and it looks like
\version "2.24.1" actually means >=.

Fixed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> -#+begin_src org :exports none
> +#+begin_src lilypond :exports none
>
> That’s strange — what was the reason for using org as source before?

Could be just a typo.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Dr. Arne Babenhauserheide]

Jonathan Gregory  writes:

> Given the feedback, I went ahead and changed the lilypond.org file:
>
> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92

-#+begin_src org :exports none
+#+begin_src lilypond :exports none

That’s strange — what was the reason for using org as source before?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi

On 13 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


Can you check if adding:

\version "2.24.1"
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)

to the version-and-paper block fixes the issue.


Yes, except that I have lilypond 2.24.0, which failed until I 
changed the version to fit my lilypond version.


Do you happen to know the minimal required version needed for 
your change to work? And do we need that \version line at all?



Also, I believe tagline = "" is now the only variable needed.


Looks like this on my side as well.


Given the feedback, I went ahead and changed the lilypond.org 
file:


https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi

On 13 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


Can you check if adding:

\version "2.24.1"
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)

to the version-and-paper block fixes the issue.


Yes, except that I have lilypond 2.24.0, which failed until I 
changed the version to fit my lilypond version.


Do you happen to know the minimal required version needed for 
your change to work? And do we need that \version line at all?


I'd keep the version in sync with the stable release, but I guess 
that's up to the maintainer. The documentation says that "Every 
LilyPond file should contain a version statement":


The version statement is important for at least two reasons. 
First, it allows automatic updating of the input file as LilyPond 
syntax changes. Second, it describes the version of LilyPond 
needed to compile the file.


If the version statement is omitted from an input file, LilyPond 
prints a warning during the compilation of the file. 


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

> Can you check if adding:
>
> \version "2.24.1"
> #(ly:set-option 'use-paper-size-for-page #f)
> #(ly:set-option 'tall-page-formats 'pdf)
>
> to the version-and-paper block fixes the issue.

Yes, except that I have lilypond 2.24.0, which failed until I changed
the version to fit my lilypond version.

Do you happen to know the minimal required version needed for your
change to work? And do we need that \version line at all?

> Also, I believe tagline = "" is now the only variable needed.

Looks like this on my side as well.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Dr. Arne Babenhauserheide]

Jonathan Gregory  writes:

> Hi Ihor
>
> On 12 Jul 2023, Ihor Radchenko wrote:
>
> [...]
>
>> I have recently seen https://masto.ai/@rfc1149/110674961710491363
>> that revealed a problem with example from
>> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org29a742f
>>
>> Instead of lilypond fragments, full pages are inserted when
>> exporting to pdf.
>>
>> Upon further investigation, it looks like something changed in how
>> Lilypond defines page layout.
>
> Can you check if adding:
>
> \version "2.24.1"
> #(ly:set-option 'use-paper-size-for-page #f)
> #(ly:set-option 'tall-page-formats 'pdf)

For a plain Lilypond file this works! It does not even need the version
(I tried it with \version "2.19.80").

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Ihor

On 12 Jul 2023, Ihor Radchenko wrote:

[...]

I have recently seen 
https://masto.ai/@rfc1149/110674961710491363 that revealed a 
problem with example from 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org29a742f


Instead of lilypond fragments, full pages are inserted when 
exporting to pdf.


Upon further investigation, it looks like something changed in 
how Lilypond defines page layout.


Can you check if adding:

\version "2.24.1"
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)

to the version-and-paper block fixes the issue.

Also, I believe tagline = "" is now the only variable needed.

--
Jonathan

[BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I typically use it directly, but if the maintenance burden is
> manageable, I could offer maintenance here, too (once I have the papers
> in place).

I have recently seen https://masto.ai/@rfc1149/110674961710491363 that
revealed a problem with example from
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html#org29a742f

Instead of lilypond fragments, full pages are inserted when exporting to pdf.

Upon further investigation, it looks like something changed in how
Lilypond defines page layout.

Arne, maybe you can point me in the right direction?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:

I'm now discarding this call for help on updates.orgmode.org.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Hi all,

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation

I've made this move now, with the exceptions we discussed in this
thread.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=db67c7e9231d35e34341431bb4fc8ba213f1d811

Please report anything weird that might happen here.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Allo Arne,

"Dr. Arne Babenhauserheide"  writes:

> Bastien  writes:
>
>> Less code is less bug and less maintainance.  So I'm considering
>> moving these files to the new (unmaintained) org-contrib repo at
>> https://git.sr.ht/~bzg/org-contrib:
>>
>> - ob-ditaa.el --- Babel Functions for ditaa
>
> This is well-established, and once I have my paperwork in place I would
> offer maintenance, because this is a major part of the lectures I write
> in org-mode.

Thanks again for offering your help.

Did you go through the copyright assignment process?  I can't see your
name in the FSF copyright file.

Let me know how it goes, and please CC me if you ping the FSF
copyright clerk at 

Thanks,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Jack Kamm]

Eric S Fraga  writes:

> On Tuesday,  4 May 2021 at 01:49, Timothy wrote:
>> For the future, I'd think Julia actually warrants 1st class inclusion in
>> Org, and I've instigated an effort to write an ob-julia that works well.
>
> +1!  Happy to help test if you wish.  I use Julia as my programming
> language these days.

+1 from me as well, I think Julia passes the "well-established" test and
is an important language for scientific computing.

I like Julia, but only occasionally use it, and it seems to frequently
cause troubles with my Org config whenever I update or move
computers. So I appreciate this effort to support it better -- thank you 
Timothy.

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Greg Minshall]

Bastien,

> > lisp/ob-julia.el: Add a Homepage header
> 
> that Homepage seems to point at
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be
> a (the?) full-on org-mode git repo, and which doesn't appear to have
> ob-julia.el.

apologies, i hadn't taken the time to look at the full git log message:


commit 2e0375d20b3a411ddf32194229c7d93f69aa701c
Author: Bastien Guerry 
Date:   Wed May 12 06:20:33 2021 +0200

lisp/ob-julia.el: Add a Homepage header

The Homepage header of ob-julia.el points to the new org-mode.git
repository because we will include ob-julia.el in Org's core.


cheers, Greg

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Greg Minshall]

hi, Bastien,

> 2e0375d2 — Bastien Guerry2 days ago
> lisp/ob-julia.el: Add a Homepage header

that Homepage seems to point at
https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be
a (the?) full-on org-mode git repo, and which doesn't appear to have
ob-julia.el.

for whatever reason, i point at https://github.com/gjkerns/ob-julia in
case that's of use.

cheers, Greg

ps -- snooping around, trying to figure out if i understood things,
org-link-edit.el seems to lack a Homepage.

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Jean Louis  writes:

> If those files have copyrights submitted, should they not end up in
> GNU ELPA?

Many of the authors for files in org-contrib did not want to assign
their copyright to the FSF.  

That's one of the reasons behind the contrib/ directory in the first
place.

Also, org-contrib in NonGNU ELPA will be a transitory package: once
all the files there find a maintainer and another place where to be
hosted, I'll delete the package and the repository.

> If there are no copyrights, then I hope maintainers would include it
> in NonGNU ELPA.
>
> Is that intention?

Yes, as a transitory stage to help people install it.

Unless someone wants to maintain all the files in org-contrib and the
NonGNU ELPA package.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Jean Louis]

* Bastien  [2021-05-03 18:14]:
> Hi all,
> 
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
> 
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation

Personally I use ditaa


If those files have copyrights submitted, should they not end up in
GNU ELPA?

If there are no copyrights, then I hope maintainers would include it
in NonGNU ELPA.

Is that intention?


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Victor A. Stoichita]

Le 04 May 2021, Bastien  a écrit :
>> I typically use it directly, but if the maintenance burden is
>> manageable, I could offer maintenance here, too (once I have the papers
>> in place).
>
> Thanks also for this then!
>

Thanks as well ! It’s good to know that knowledgeable people might care
for this little tool which I find very useful.

Regards,
Victor

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi Victor,

"Victor A. Stoichita"  writes:

> Le 03 May 2021, Bastien  a écrit :
>> I suggest a criterium for keeping ob*.el files in Org could be that
>> the extension is known by Emacs _or_ that the supported language is
>> well-established.
>
> I happen to be an active user of ob-lilypond. Lilypond is certainly
> peripheral to the world of programming languages. It is well established
> and active as an equivalent of LaTeX for music though ([1][2][3]).
> It comes with built-in support for Emacs [4].

Agreed, thanks for the references!

> I see no reason to not move ob-lilypond to org-contrib. I understand
> that only few of us use it these days. I can’t stand up as a maintainer
> since my Lisp skills and my knowledge of org-mode are quite insufficient
> for that. I was happy to see that someone submitted a patch for
> ob-lilypond in January. I hope that by the time something breaks I’ll be
> able to submit a patch myself.

I hope too.

PS: Also, in general, we are not talking about shutting down a
feature: ob-*.el packages in org-contrib.git continue to be available.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi,

"Dr. Arne Babenhauserheide"  writes:

> Lilypond is not just well-established, it is the dominant tool for note
> engraving. One of the few domains in which no proprietary comes close in
> terms of quality.
>
> I typically use it directly, but if the maintenance burden is
> manageable, I could offer maintenance here, too (once I have the papers
> in place).

Thanks also for this then!

> Having support in core directly helps a lot when using the tool, because
> that enables working zero-setup org-files (with some load-language in an
> elisp block).

... which is good if the package is really maintained, and calling for
trouble if it is not.  Anyway, I agree with you about the importance
of ob-lilypond.el.

Best,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi,

"Dr. Arne Babenhauserheide"  writes:

> This is well-established, and once I have my paperwork in place I would
> offer maintenance, because this is a major part of the lectures I write
> in org-mode.

Thanks for volunteering here.  Let me know when the paperwork is done
so that I can you as the maintainer.

Best,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Dr. Arne Babenhauserheide]

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-ditaa.el --- Babel Functions for ditaa

This is well-established, and once I have my paperwork in place I would
offer maintenance, because this is a major part of the lectures I write
in org-mode.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Dr. Arne Babenhauserheide]

Victor A. Stoichita  writes:

> Le 03 May 2021, Bastien  a écrit :
>> I suggest a criterium for keeping ob*.el files in Org could be that
>> the extension is known by Emacs _or_ that the supported language is
>> well-established.
>
> I happen to be an active user of ob-lilypond. Lilypond is certainly
> peripheral to the world of programming languages. It is well established
> and active as an equivalent of LaTeX for music though ([1][2][3]).
> It comes with built-in support for Emacs [4].

Lilypond is not just well-established, it is the dominant tool for note
engraving. One of the few domains in which no proprietary comes close in
terms of quality.

I typically use it directly, but if the maintenance burden is
manageable, I could offer maintenance here, too (once I have the papers
in place).

Having support in core directly helps a lot when using the tool, because
that enables working zero-setup org-files (with some load-language in an
elisp block).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Eric S Fraga]

On Tuesday,  4 May 2021 at 01:49, Timothy wrote:
> For the future, I'd think Julia actually warrants 1st class inclusion in
> Org, and I've instigated an effort to write an ob-julia that works well.

+1!  Happy to help test if you wish.  I use Julia as my programming
language these days.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Tim Cross  writes:

> +1 on this and the list of proposed languages.

Thanks for the feedback.

> Do any of these ob-* files have FSF copyright i.e. author assigned
> copyright to FSF. Just wondering, given the contrib package will live in
> non-gnu repo, if this is something we need to be concerned about or not?

All these ob-*.el files are part of Org core, so they are part of
Emacs and require the authors to sign the FSF papers.

So there is no real problem here.

org-contrib.git contains files with a free software license: most of
them are GPLv3+, a few of them GPVv2(+) and one (or two, from memory)
is using a MIT license.  So there is no blocker for org-contrib.git
to be packaged as a NonGNU package.

> Strikes me there is nothing written in stone here, so if a language
> becomes popular and it has maintainers, we can always review the
> decision to move it 'out' and when justified, move back into core.

Yes - on the other hand, we don't want to move files out of Org's core
too often.

> I think it is good having a clear distinction and the idea that if your
> using a contrib package, it is 'best effort only' and not guaranteed to
> work with the most recent org version compared to 'core', which has an
> expectation it works with most recent org version.

Yes, this is also the idea.  That's why I called for more maintainers
for the ob-*.el files, but we're not there yet, and for now it would
be too drastic IMHO to remove some ob-*.el for which we don't have a
maintainer or we are not 100% sure they are compatible.  But luckily
enough, I don't think backward compatibility problems happen often
with Babel files.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Tim Cross]

Bastien  writes:

> Hi all,
>
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation
>
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.
>

+1 on this and the list of proposed languages.

Do any of these ob-* files have FSF copyright i.e. author assigned
copyright to FSF. Just wondering, given the contrib package will live in
non-gnu repo, if this is something we need to be concerned about or not?

Strikes me there is nothing written in stone here, so if a language
becomes popular and it has maintainers, we can always review the
decision to move it 'out' and when justified, move back into core.

I think it is good having a clear distinction and the idea that if your
using a contrib package, it is 'best effort only' and not guaranteed to
work with the most recent org version compared to 'core', which has an
expectation it works with most recent org version.

-- 
Tim Cross

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Victor A. Stoichita]

Le 03 May 2021, Bastien  a écrit :
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.

I happen to be an active user of ob-lilypond. Lilypond is certainly
peripheral to the world of programming languages. It is well established
and active as an equivalent of LaTeX for music though ([1][2][3]).
It comes with built-in support for Emacs [4].

I see no reason to not move ob-lilypond to org-contrib. I understand
that only few of us use it these days. I can’t stand up as a maintainer
since my Lisp skills and my knowledge of org-mode are quite insufficient
for that. I was happy to see that someone submitted a patch for
ob-lilypond in January. I hope that by the time something breaks I’ll be
able to submit a patch myself.

Regards,
Victor

[1] http://lilypond.1069038.n5.nabble.com/

[2]  https://music.stackexchange.com/questions/tagged/lilypond

[3]  https://stackoverflow.com/questions/tagged/lilypond

[4]  
http://lilypond.org/doc/v2.21/Documentation/usage/text-editor-support.html#emacs-mode

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Timothy  writes:

> "community-developed non-core Org stuff that isn't actively maintained".

Yes, and: "In search for maintainers."

> The idea here being to move ob-* for rarely used languages to this repo
> to lessen the maintenance load.

Yes, that's it, thanks for stating it more directly than I did.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi Palak,

Palak Mathur  writes:

> Any reason why we can’t move all ob-* files out into this new repo? 

Yes, that's because Org Babel is a core documented feature of Org that
is not usable without these ob-*.el files.

We want to move out files that are of less importance and for which we
would like maintainance to happen elsewhere than in Org's core.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Palak Mathur]

> On May 3, 2021, at 2:44 PM, Timothy  wrote:
> 
> 
> Palak Mathur  writes:
> 
>> Any reason why we can’t move all ob-* files out into this new repo?
> 
> I trust Bastien will correct me if I'm wrong, but my understanding is
> this isn't a new repo for "miscellaneous Org stuff" more
> "community-developed non-core Org stuff that isn't actively maintained".
> 

Will it not make sense to separate out non-core from the core? 

> The idea here being to move ob-* for rarely used languages to this repo
> to lessen the maintenance load.
> 

In that case ob-groovy.el can be moved out. 

> --
> Timothy

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Timothy]

Palak Mathur  writes:

> Any reason why we can’t move all ob-* files out into this new repo?

I trust Bastien will correct me if I'm wrong, but my understanding is
this isn't a new repo for "miscellaneous Org stuff" more
"community-developed non-core Org stuff that isn't actively maintained".

The idea here being to move ob-* for rarely used languages to this repo
to lessen the maintenance load.

--
Timothy

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Palak Mathur]

> On May 3, 2021, at 1:07 PM, Bastien  wrote:
> 
> Thanks for your reply.
> 
> Timothy  writes:
> 
>> For the future, I'd think Julia actually warrants 1st class inclusion in
>> Org, and I've instigated an effort to write an ob-julia that works well.
>> More on this once it reaches a usable state.
> 
> Great, I suggest we delete ob-julia.el from org-contrib when we can
> point to this new version.
> 
>> Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
>> ob-io.el, and ob-shen.el may be worth adding to the list?
> 
> I agree ob-shen.el should probably move.
> For ob-io.el, I was perhaps too impressed by their website.
> For ob-groovy.el, I believe Groovy is quite actively used out there.
> 
> But I'll add these three to the "maybe" list.
> 
> Thanks,

Any reason why we can’t move all ob-* files out into this new repo? 


> -- 
> Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Thanks for your reply.

Timothy  writes:

> For the future, I'd think Julia actually warrants 1st class inclusion in
> Org, and I've instigated an effort to write an ob-julia that works well.
> More on this once it reaches a usable state.

Great, I suggest we delete ob-julia.el from org-contrib when we can
point to this new version.

> Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
> ob-io.el, and ob-shen.el may be worth adding to the list?

I agree ob-shen.el should probably move.
For ob-io.el, I was perhaps too impressed by their website.
For ob-groovy.el, I believe Groovy is quite actively used out there.

But I'll add these three to the "maybe" list.

Thanks,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Timothy]

This is only tangentally related, but this feels like a relevant place
to mention this and I don't think it deserves its own thread.

I think it's also worth considering deleting ob-julia.el from
org-contrib. Not to put to fine a point on things, but it's currently
dysfunctional. Trying to execute any code in a session causes Emacs to
freeze. Simply put, it was written for pre-1.0 Julia and is no longer
fit for purpose.

For the future, I'd think Julia actually warrants 1st class inclusion in
Org, and I've instigated an effort to write an ob-julia that works well.
More on this once it reaches a usable state.

-

Regarding your the list of proposed files to move to org-contrib, I
concur that they fall under the bar you're setting.

Just going from the fact I haven't heard of them, perhaps ob-groovy.el,
ob-io.el, and ob-shen.el may be worth adding to the list?

--
Timothy

Bastien  writes:

> Hi all,
>
> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation
>
> I suggest a criterium for keeping ob*.el files in Org could be that
> the extension is known by Emacs _or_ that the supported language is
> well-established.
>
> Since I can obviously not decide alone about "well-established", would
> you mind giving your advice on whether the files above can be moved to
> org-contrib?  (Of course we would advertize this carefully.  And also,
> there is absolutely nothing personal about perhaps moving *your* file
> out of Emacs, it's just that maintainance will be easier outside.)
>
> Are there any other?
>
> I'll leave this thread open during this week, no need to rush here.
>
> Thanks,

Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi all,

Less code is less bug and less maintainance.  So I'm considering
moving these files to the new (unmaintained) org-contrib repo at
https://git.sr.ht/~bzg/org-contrib:

- ob-abc.el --- Org Babel Functions for ABC
- ob-asymptote.el --- Babel Functions for Asymptote
- ob-coq.el --- Babel Functions for Coq
- ob-ditaa.el --- Babel Functions for ditaa
- ob-ebnf.el --- Babel Functions for EBNF
- ob-hledger.el --- Babel Functions for hledger
- ob-J.el --- Babel Functions for J
- ob-ledger.el --- Babel Functions for Ledger
- ob-lilypond.el --- Babel Functions for Lilypond
- ob-mscgen.el --- Babel Functions for Mscgen
- ob-picolisp.el --- Babel Functions for Picolisp
- ob-vala.el --- Babel functions for Vala evaluation

I suggest a criterium for keeping ob*.el files in Org could be that
the extension is known by Emacs _or_ that the supported language is
well-established.

Since I can obviously not decide alone about "well-established", would
you mind giving your advice on whether the files above can be moved to
org-contrib?  (Of course we would advertize this carefully.  And also,
there is absolutely nothing personal about perhaps moving *your* file
out of Emacs, it's just that maintainance will be easier outside.)

Are there any other?  

I'll leave this thread open during this week, no need to rush here.

Thanks,

-- 
 Bastien