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
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
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
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
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:
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.
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
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
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:
> >
> >
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:
>
>
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
>
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
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=""
>
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
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
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
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
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
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
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
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
"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
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
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,
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,
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
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
>>
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
"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
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
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
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
>
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
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
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
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
* 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
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
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.
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
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
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
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
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.
--
:
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
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
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
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
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
> 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
>
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".
> 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
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
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
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
72 matches
Mail list logo
