Re: [ELPA] New package: ob-haxe

[ian martins <ianxm@jhu.edu>]

> 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.

This makes sense to me, but I don't see why the solution has to be to
combine them all into a single package.

If putting everything related to flymake doesn't work, couldn't the
same problems arise if we clump together everything related to a
language? It's the same solution (partitioning functionality into
packages based on relatedness), but now we're slicing it on a
different axis [language] than before [feature]. I may be missing the
main issue, but suspect the problem with keeping all languages in
flymake is that users don't want to install flymake implementations
for languages they don't use and maintainers don't want to maintain
code they aren't familiar with.  Both of these problems would apply to
major modes that include everything related to that language. There
are probably many people who use haxe but don't use Org.

Another option is to have small packages with specific functions, and
use dependencies to build up larger chunks of functionality. Would it
solve the problem if we had a haxe-bundle package with dependencies on
haxe-mode and ob-haxe? Then users only have to find one package to
install all haxe functionality if they want it, but if they don't want
it all they can pick individual packages instead.  Also that way all
of the code is maintained by those who know it best.  Also, parent
packages can be created today to encompass existing languages
relatively easily, but merging all of the existing packages for each
language together into major modes would be a large effort and
significant disruption to those projects.

> > 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).

I'm not sure about this rule. How can we know that two competing
packages won't be maintained? Doesn't it depend on relative interest
and the size of the community using them?

Even if competing packages don't co-exist for long, there can be some
time after someone clones a package to try it another way and the
community has two options. If someone cloned haxe-mode and it included
ob-haxe, then for as long as they both existed, updates to ob-haxe
would have to be pushed to both haxe-modes.

> 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.

No, sorry, I was asking hypothetically. Actually I think there were
multiple haxe major modes at one point but I checked yesterday and saw
only one (there are a couple other haxe packages, but just one major
mode). I asked because if ob-haxe should be a separate package in this
case, then should we follow that pattern in the general case, since
any major mode can have two packages at some point in time?