Re: [ELPA] New package: ob-haxe

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

In theory, yes.

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

Indeed.  In practice it tends to work much better, but there's no
guarantee: one size never fits all.

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

Not only that.  Typically, the code that provides flymake support for
a given language will need to know something about that language and
some of that info is also needed in the major-mode (e.g. the name of the
compiler), so the two will usually want to share some
defconst/defcustom, but you can't have flymake *depend* on all those
major modes, so you typically end up with duplication.

> Both of these problems would apply to major modes that include
> everything related to that language.

I think part of the reason why the tradeoffs are different is that the
number of "infrastructure" packages (font-lock, imenu, flymake, company,
eglot, org-babel, smie, ...) tends to be much smaller and grow much less
frequently than the number of languages.

> Another option is to have small packages with specific functions, and
> use dependencies to build up larger chunks of functionality.

Of course.

> Would it solve the problem if we had a haxe-bundle package with
> dependencies on haxe-mode and ob-haxe?

I don't think there's really a problem to solve, really.

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

If there is an actual choice for the user, that's good.  But if the
choice is only "include org-babel support or not" then I think this is
actually detrimental for the user: the gain of not having org-babel
support for those users not using org-babel *should* be negligible
(i.e. it should not incur extra dependencies and the increase in size
should be irrelevant).

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

Nobody is forcing them to be merged.  I'm just saying that history tells
us that they tend to merge that way, and that it's usually a good thing
both for the users and for technical reasons.  So we may as well
consciously move in that direction whenever convenient.

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

I am.

> How can we know that two competing packages won't be maintained?

We don't (and nowhere did I say that we do).

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

Good.  Then I think it would be good to try and work with the
major-mode's maintainer and merge the two packages.

In the mean time, I'll do the initial addition of `ob-haxe` to GNU ELPA.


        Stefan