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 22:25:49 -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="24336"; 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 Wed Jan 20 04:27:04 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 1l249A-0006Dc-51 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 04:27:04 +0100 Original-Received: from localhost ([::1]:36050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2499-00066y-2Z for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 22:27:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l248C-0005em-HI for emacs-devel@gnu.org; Tue, 19 Jan 2021 22:26:04 -0500 Original-Received: from mail-ed1-f44.google.com ([209.85.208.44]:41222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l248A-00070w-QO for emacs-devel@gnu.org; Tue, 19 Jan 2021 22:26:04 -0500 Original-Received: by mail-ed1-f44.google.com with SMTP id bx12so10050693edb.8 for ; Tue, 19 Jan 2021 19:26:02 -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=Bscum3+E7WIDXYOZv/hYIBvMMUudocM8jKlZL11tObI=; b=qWwVKS56r8cHmXjxUATUt2JsrZlcuZt2kVlRuD4mpZ/Ul02EZ+E72uMF+OSosobLSp EsrW81fI3t43zuo8pBuLXSv0YSfq5nCh03PKNWc/HqQeYdfmVlT8Ye9dEXuQIFLZWjEK 4Pw/rq+kCu9wiizHnm+lUiqvXJkMkcFyqlcDeQ2W++vbf4K2a6lF65Nac+ANNWY/gsGg gCx3q5Wr0qtVeGjgDXsHjCTvaKWoCJ/Si1of2F80XITHL5QCzyXALgiLqC2DDs1U4RU+ wl3gSFeO9mRYa0d2QV2cEFpjcSmoN8QvBKUsEGiXSB0t8OufV0KcyI1DYYbhoEULY3XY BaOg== X-Gm-Message-State: AOAM531lI0vyDtWumi97cQRjqv/51XfifzhzA0Frb01khRb+Q7+VsGnh f91+LFG6M39RIg0TfBfEu5UcE6NbarmJdvVVGyDSwbUgakA= X-Google-Smtp-Source: ABdhPJzEBvoYWjTVGLmgPTU2FoVcePcv+6M+gjk7hlQ3iIdDviE/IV583wcvJEnj7sutQapvnCHcur3OIOhci2t13f0= X-Received: by 2002:aa7:cac2:: with SMTP id l2mr5740095edt.141.1611113161051; Tue, 19 Jan 2021 19:26:01 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.208.44; envelope-from=ianxm1@gmail.com; helo=mail-ed1-f44.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:263190 Archived-At: > > 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.