From: Tim Cross <email@example.com> To: firstname.lastname@example.org Subject: Re: Moving some lisp/ob-*.el files to org-contrib - your advice? Date: Tue, 04 May 2021 08:19:53 +1000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Bastien <email@example.com> 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
next prev parent reply other threads:[~2021-05-03 22:46 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-03 15:13 Bastien 2021-05-03 17:49 ` Timothy 2021-05-03 18:05 ` Bastien 2021-05-03 19:36 ` Palak Mathur 2021-05-03 19:44 ` Timothy 2021-05-03 19:47 ` Palak Mathur 2021-05-03 20:34 ` Bastien 2021-05-03 20:33 ` Bastien 2021-05-04 7:55 ` Eric S Fraga 2021-05-19 3:36 ` Jack Kamm 2021-05-03 20:52 ` Victor A. Stoichita 2021-05-04 10:19 ` Dr. Arne Babenhauserheide 2021-05-04 11:28 ` Bastien 2021-05-04 18:38 ` Victor A. Stoichita 2021-05-04 11:32 ` Bastien 2021-05-03 22:19 ` Tim Cross [this message] 2021-05-03 23:15 ` Bastien 2021-05-04 10:19 ` Dr. Arne Babenhauserheide 2021-05-04 11:10 ` Bastien 2021-09-26 8:17 ` Bastien 2021-05-06 9:19 ` Jean Louis 2021-05-06 9:39 ` Bastien 2021-05-14 18:23 ` Greg Minshall 2021-05-17 16:39 ` Greg Minshall 2021-09-26 12:50 ` Bastien Guerry 2021-10-02 17:11 ` Bastien Guerry
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Moving some lisp/ob-*.el files to org-contrib - your advice?' \ /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
Code repositories for project(s) associated with this 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).