From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: ob-haxe Date: Tue, 19 Jan 2021 10:15:39 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3335"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: ian martins Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 19 16:39:36 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1t6W-0000ky-Jv for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 16:39:36 +0100 Original-Received: from localhost ([::1]:44516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1t6T-0008C6-VI for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 10:39:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1sjU-0005HE-6a for emacs-devel@gnu.org; Tue, 19 Jan 2021 10:15:48 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25263) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1sjQ-0001w4-Ao for emacs-devel@gnu.org; Tue, 19 Jan 2021 10:15:47 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1DB10805F4; Tue, 19 Jan 2021 10:15:43 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 581AA80272; Tue, 19 Jan 2021 10:15:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1611069341; bh=mDOxiGeiJCFMR/X6lr8iXGmnqhd93YLhKXKua5NGHEI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=A64TVL6ABnXt6ujRfbVi06TCHdhXJZyLLUCDRpNhCC5k35SwEKlV2vGn/AZkkaPHi vDeNY1gFP2aYvne6peIyeIic1yj7ev4RFuRpzNb6x2XPpCL4aJuOcAurV3Eo8jKRkq xCrGNb5Rs8CCnK1ycPaPVaEZznh+p9ociiJxkGga7lg5L34fUGj4VCf6iTQPPzrlsW /5pGGCAo1lQThUbMnvz5DCA1uBgOr6tTOwBdceJWDgomCWDMflYXHAD7hBdmKo6Gu/ ToEx3mbo9Nhgl2biRzc+Dp0VupqrXJNsQUKTMbSzZTEvUUjM1dvdZVBMiqJdIKHj+8 M6nm1GytXMTbg== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3161C12055F; Tue, 19 Jan 2021 10:15:41 -0500 (EST) In-Reply-To: (ian martins's message of "Tue, 19 Jan 2021 09:28:32 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263173 Archived-At: >> 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