From: Ihor Radchenko <yantar92@gmail.com>
To: Jarmo Hurri <jarmo.hurri@iki.fi>
Cc: emacs-orgmode@gnu.org
Subject: Re: The fate of ob-asymptote.el
Date: Thu, 28 Jul 2022 22:29:24 +0800 [thread overview]
Message-ID: <87fsil9upn.fsf@localhost> (raw)
In-Reply-To: <87r127c8q5.fsf@iki.fi>
Jarmo Hurri <jarmo.hurri@iki.fi> writes:
> 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.
Well. You convinced me. If Asymptote has very stable syntax and major
features, it probably makes more sense to maintain it within Org or
within Org community.
> 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.
I agree that it is nice, but we cannot, unfortunately support all the
programming languages out there. As long a some specific language has a
maintainer, things are fine, but in long term it is only reliable to
support popular ones + possibly GNU projects (as Org is a part of GNU, and it is kind of obligation).
> - 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.
Because it is unmaintained. Beside that note, we also ask potential
maintainers to go ahead to adopt the unmaintained pieces. Those pieces
can then move to ELPA/non-GNU ELPA and be maintained properly.
>> 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?
Not necessarily. I just expressed doubts about long-term
maintainability. As long as there is a person maintaining ob-asymptote,
things should be fine. Especially if there is a good test coverage and
WORG documentation.
Best,
Ihor
next prev parent reply other threads:[~2022-07-28 14:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 14:55 The fate of ob-asymptote.el Jarmo Hurri
2022-07-20 15:18 ` Tory S. Anderson
2022-07-20 19:43 ` Nick Dokos
2022-07-21 5:17 ` Jarmo Hurri
2022-07-21 11:54 ` Ihor Radchenko
2022-07-21 13:21 ` Max Nikulin
2022-07-22 0:27 ` Ihor Radchenko
2022-07-22 7:12 ` Jarmo Hurri
2022-07-26 1:46 ` Ihor Radchenko
2022-07-26 10:23 ` Jarmo Hurri
2022-07-27 3:24 ` Ihor Radchenko
2022-07-27 7:31 ` Jarmo Hurri
2022-07-28 14:29 ` Ihor Radchenko [this message]
2022-07-30 9:23 ` Jarmo Hurri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fsil9upn.fsf@localhost \
--to=yantar92@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=jarmo.hurri@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).