unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: ian martins <ianxm@jhu.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] New package: ob-haxe
Date: Mon, 18 Jan 2021 11:31:50 -0500	[thread overview]
Message-ID: <jwv35yygqxh.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAC=rjb4CSBL2doeCaohbAZBCos-dj54wiHUt+EMoVsSJ4jQVcw@mail.gmail.com> (ian martins's message of "Sun, 17 Jan 2021 22:35:43 -0500")

>> I'd be happy to do that, but just to be sure, I'd like to understand
>> something first.  AFAICT, all other `ob-<LANG>.el` files are currently
>> bundled with Org.
>
> Thanks for responding. No, actually there are many that are maintained
> outside of Org.  If you search github for "org babel" some will come
> up. I see 46 packages that start with "ob-" in my `list-packages'.
>
> Of the ones that are bundled with Org, there are some that are
> considered "core" and others that are "contrib." I offered ob-haxe on
> the Org list and the maintainers said they didn't think it was
> appropriate for core and also that they were moving to shift more of
> the "contrib" language integrations out of the Org repo and into
> separate packages and suggested GNU ELPA for this.

Good, thanks.

>> Personally, I'd tend to consider that the
>> language-specific info for org-babel should belong with the major mode
>> (just like the language-specific support for indentation, highlighting,
>> flymake, imenu, etc.. belong to it).
>> [ Side note: I'm not sufficiently familiar with org-babel to know if
>>   bundling the info with the major mode is currently technically
>>   realistic.  ]
>
> I don't know if there's a technical problem with that approach, but
> I'm not aware of any case where it's done that way. All of the Org
> Babel language integrations I've seen have been bundled with Org or
> distributed as a separate package.
>
> I wasn't aware that usually language major modes came with more than
> indentation and highlighting.

Historically, major modes came with very little support, and over time
this set of supported facilities grows.

E.g. font-lock came with its own support for some major modes, and then
it quickly became clear that font-lock support for a particular language
is better placed in the major mode than in font-lock.el.

The same applies to most other such features: it's impractical for
flymake/flycheck/company/org-babel/... to come with support for all
languages, but it's also inconvenient for the user to have to install

    FOO
    ob-FOO
    company-FOO
    flymake-FOO
    younameit-FOO

before Emacs provides adequate support for the language FOO.  So as much
as possible, I think it makes sense to include those things along with
the language's major mode.

> If there's more than one package to choose from for a language's major
> mode, would the Org Babel functions have to be included in both of
> them?

Good question.  As a general rule "more than one package to choose from
for a language's major mode" is itself a problem (especially because
more often than not, it means none of the options are really maintained
and the choice is really between different sets of shortcomings).

So, IIUC you're saying that there is no main `haxe-mode` anyway into
which we could integrate `ob-haxe`?  If so, and since Org doesn't want
it, we should add it as a separate package, indeed.

[ Side note: if noone has come up to develop&maintain "the one and only"
  haxe-mode (which combines the good parts of the existing haxe modes),
  would you be willing to do that?  ]


        Stefan




  reply	other threads:[~2021-01-18 16:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-16 12:48 [ELPA] New package: ob-haxe ian martins
2021-01-17 22:41 ` Stefan Monnier
2021-01-18  3:35   ` ian martins
2021-01-18 16:31     ` Stefan Monnier [this message]
2021-01-19  5:30       ` Richard Stallman
2021-01-19 14:19         ` Stefan Monnier
2021-01-19 14:28       ` ian martins
2021-01-19 15:15         ` Stefan Monnier
2021-01-20  3:25           ` ian martins
2021-01-20  4:01             ` Stefan Monnier
2021-01-18  6:27   ` ASSI
2021-01-18 16:32     ` Stefan Monnier

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.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv35yygqxh.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=ianxm@jhu.edu \
    /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.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).