From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: ian martins Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: ob-haxe Date: Tue, 19 Jan 2021 09:28:32 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 19 15:34:27 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 1l1s5S-0004jJ-8P for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 15:34:26 +0100 Original-Received: from localhost ([::1]:37980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1s5R-0002oc-A2 for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 09:34:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1s03-0007tL-Ah for emacs-devel@gnu.org; Tue, 19 Jan 2021 09:28:51 -0500 Original-Received: from mail-ed1-f46.google.com ([209.85.208.46]:34909) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l1rzy-0002xx-HB for emacs-devel@gnu.org; Tue, 19 Jan 2021 09:28:47 -0500 Original-Received: by mail-ed1-f46.google.com with SMTP id u19so21762608edx.2 for ; Tue, 19 Jan 2021 06:28:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=61xCq7Pr6o//PqXgNiFnNOI/SCW6YGk1WbAZvp33aCk=; b=i6NKXIsIzGIq/RwCCr+1vsHaWU5Ow3FjRqOnqR5Yamp4l6WOF/VmFaDkrTmPeofmzL mB2sCbmL6b9Hl1+Z1nr5P1D6BIBcuLXJmRByY1yic3pdQE1cZGE18KT3DZGMBN8l1cjq ieeOtyuyIv/SDwL0hkO0+L3UMRleBx+XH6Nun9aEqNxolbi8jrEXPXpAy8V7aU2njAME l4HDR3Me03Jioymxs0AoKLw34hGhlniEOli7PTMOUlXu5ReyWO8tk/U5IsJwFPZYl+aT ElV7VCiFrIbjawTWM5cHQue7Ml5IEsZgrnSng+OvX37hLFSKgoUr5uliABknSrnTtGf4 lWrA== X-Gm-Message-State: AOAM533Udd+ID+DRLIMK58VYAl7kVzqFCzbVTVk9A1ML5qTGp08dOxk7 oByf5WaBWRqgNPn+h8ZWkJ+/7fEXqR09S/AuRO1Ma5jkPEhZYQ== X-Google-Smtp-Source: ABdhPJydrfPDKhp7fjKv2f4IXnCH0Awyq6bRNGqIEPtChv0ZUeWbSk00pn/vDDZy0Y8ybG13svBgbqAb0ifEnyf+mkk= X-Received: by 2002:a05:6402:149a:: with SMTP id e26mr901601edv.254.1611066524254; Tue, 19 Jan 2021 06:28:44 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.208.46; envelope-from=ianxm1@gmail.com; helo=mail-ed1-f46.google.com X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:263169 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? 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?