unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ian martins <ianxm@jhu.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] New package: ob-haxe
Date: Tue, 19 Jan 2021 22:25:49 -0500	[thread overview]
Message-ID: <CAC=rjb6x2grbeQjsQcWi2+EwOB5MCgh-aH=Pfc4Z+a19Kva_UA@mail.gmail.com> (raw)
In-Reply-To: <jwvft2xatcf.fsf-monnier+emacs@gnu.org>

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

That makes sense. Where there is shared code or variables it makes
sense to keep the implementations together.  For the ob-haxe and
haxe-mode case the implementations are independent of each other.  I
guess if haxe had a flymake integration it would want to share the
compiler name variable with ob-haxe, though.

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

That's a good point.

> 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.  Then I think it would be good to try and work with the
> major-mode's maintainer and merge the two packages.

I am not yet convinced of it, smaller packages and dependencies seem
neater and more flexible to me.  But as you say, history tells us that
is what tends to happen, so maybe it will be.

Do you think it would be better to merge the packages or just add a
dependency from haxe-mode to ob-haxe? Does it make a difference?

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

Thank you.



  reply	other threads:[~2021-01-20  3:25 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
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 [this message]
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='CAC=rjb6x2grbeQjsQcWi2+EwOB5MCgh-aH=Pfc4Z+a19Kva_UA@mail.gmail.com' \
    --to=ianxm@jhu.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).