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: Mon, 18 Jan 2021 11:31:50 -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="18005"; 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 Mon Jan 18 18:12:35 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 1l1Y4x-0004ap-9M for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Jan 2021 18:12:35 +0100 Original-Received: from localhost ([::1]:32856 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1Y4w-0006vP-9t for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Jan 2021 12:12:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1XRl-0002cn-8q for emacs-devel@gnu.org; Mon, 18 Jan 2021 11:32:05 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1XRf-0001ZN-Pi for emacs-devel@gnu.org; Mon, 18 Jan 2021 11:32:04 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 707FE8063C; Mon, 18 Jan 2021 11:31:54 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ACB20803FA; Mon, 18 Jan 2021 11:31:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1610987512; bh=VN3XJnd+ImBpBPBySl+EPs0WQStJyiISte4oKaeo5p4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cESIiYRpWSjlqXuDpkXulRwdA8ONYwQBUsYAu0f0Vt4EVcf5cizaaPveej4fDsGWE 51WQNo+ja7yCwbUrqK2/Isa5QyVnqvzpFb4b3r4G252nvldD60v7sQgATDgMJBUhVh MHgsA/qfHA2qr+q57CmVe7+xckSXeSjkacn+6OtY3psd5cbQnZoUKUkZzmDWpfGRDX dPYPnQqr7HWHRPDhrrYMUp/wM0kqTtFo8eDNdaIZp+vo40NCuvVFSNHzCqND0NZ0Tp 8ymWSGUdjkhlgjj6Ik2v/QhqLWLiFYhVWGf0cgQRMJsLYUxSFFd/AEeFwI+XXvNQ22 UKIkhN18dvXng== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 43B3B1200A1; Mon, 18 Jan 2021 11:31:52 -0500 (EST) In-Reply-To: (ian martins's message of "Sun, 17 Jan 2021 22:35:43 -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:263153 Archived-At: >> I'd be happy to do that, but just to be sure, I'd like to understand >> something first. AFAICT, all other `ob-.el` files are currently >> bundled with Org. > > Thanks for responding. No, actually there are many that are maintained > outside of Org. If you search github for "org babel" some will come > up. I see 46 packages that start with "ob-" in my `list-packages'. > > Of the ones that are bundled with Org, there are some that are > considered "core" and others that are "contrib." I offered ob-haxe on > the Org list and the maintainers said they didn't think it was > appropriate for core and also that they were moving to shift more of > the "contrib" language integrations out of the Org repo and into > separate packages and suggested GNU ELPA for this. Good, thanks. >> Personally, I'd tend to consider that the >> language-specific info for org-babel should belong with the major mode >> (just like the language-specific support for indentation, highlighting, >> flymake, imenu, etc.. belong to it). >> [ Side note: I'm not sufficiently familiar with org-babel to know if >> bundling the info with the major mode is currently technically >> realistic. ] > > I don't know if there's a technical problem with that approach, but > I'm not aware of any case where it's done that way. All of the Org > Babel language integrations I've seen have been bundled with Org or > distributed as a separate package. > > I wasn't aware that usually language major modes came with more than > indentation and highlighting. Historically, major modes came with very little support, and over time this set of supported facilities grows. E.g. font-lock came with its own support for some major modes, and then it quickly became clear that font-lock support for a particular language is better placed in the major mode than in font-lock.el. The same applies to most other such features: 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. > 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). 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. [ Side note: if noone has come up to develop&maintain "the one and only" haxe-mode (which combines the good parts of the existing haxe modes), would you be willing to do that? ] Stefan