[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The fate of ob-asymptote.el
From: |
Jarmo Hurri |
Subject: |
Re: The fate of ob-asymptote.el |
Date: |
Wed, 27 Jul 2022 10:31:30 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hello again.
Ihor Radchenko <yantar92@gmail.com> writes:
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>> As a result, changes in Org are much more likely to affect
>> ob-asymptote.el than changes in Asymptote. I think basic software
>> development rules of thumb suggest that ob-asymptote.el should then
>> be bundled with Org.
>
> From my point of view ob-asymptote.el is as bare bones as babel
> library can be. It does not use any fancy Org babel features like
> sessions, error display of converting the output to various :results
> output options.
>
> In contrast, it does a lot of work trying to convert Elisp types to
> Asymptote in `org-babel-asymptote-var-to-asymptote`.
Fair point. Then again, the involved datatypes of Asymptote are,
practically, immutable.
I can not resist pointing out that we are having this discussion because
of changes in Org, not because of changes in Asymptote. I consider Org
much more volatile than Asymptote.
But I might be digressing. A bit of a summary:
- I embrace a (any) maintained feature which extends the applicability
of Org without compromising "the core." I have had great moments
noticing that Org already supports something new I need.
- Asymptote is brilliant. :-) I hope I can provide connectivity to Org
for current and future users. When I shrivel away, this support might
get buried next to me.
- Org contrib basically advertises itself as unmaintained. While that
may change, and there is in fact a request to help maintain the
add-ons on the github page, I am pessimistic. I would not install it,
so I doubt others would either.
- I see Org as the logical place for ob-asymptote.el. If this is
rejected, I may try inclusion into Asymptote if it is not an uphill
battle.
> From my point of view, any kind of new functionality in
> ob-asymptote.el requires a deep knowledge about the Asymptote
> programming - the knowledge most of the Org devs lack. At the same
> time, changes in Org babel core functionality are unlikely to cause
> any issues in ob-asymptote - we try our best to keep backwards
> compatibility with third-party babel packages anyway.
Does this suggest that, from the point of view of Org, the risk of
supporting ob-asymptote.el is minimal?
All the best,
Jarmo
- Re: The fate of ob-asymptote.el, (continued)
- Re: The fate of ob-asymptote.el, Tory S. Anderson, 2022/07/20
- Re: The fate of ob-asymptote.el, Nick Dokos, 2022/07/20
- Re: The fate of ob-asymptote.el, Ihor Radchenko, 2022/07/21
- Re: The fate of ob-asymptote.el, Max Nikulin, 2022/07/21
- Re: The fate of ob-asymptote.el, Ihor Radchenko, 2022/07/21
- Re: The fate of ob-asymptote.el, Jarmo Hurri, 2022/07/22
- Re: The fate of ob-asymptote.el, Ihor Radchenko, 2022/07/25
- Re: The fate of ob-asymptote.el, Jarmo Hurri, 2022/07/26
- Re: The fate of ob-asymptote.el, Ihor Radchenko, 2022/07/26
- Re: The fate of ob-asymptote.el,
Jarmo Hurri <=
- Re: The fate of ob-asymptote.el, Ihor Radchenko, 2022/07/28
- Re: The fate of ob-asymptote.el, Jarmo Hurri, 2022/07/30