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,gmane.emacs.erc.general Subject: Re: [ELPA] New package: ERC Date: Mon, 20 Sep 2021 12:48:43 -0400 Message-ID: References: <87tuih3jfq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38464"; 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, emacs-erc@gnu.org, larsi@gnus.org To: Amin Bandali Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 20 19:09:12 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 1mSMn1-0009pj-2I for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Sep 2021 19:09:11 +0200 Original-Received: from localhost ([::1]:56370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSMmz-00034b-RY for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Sep 2021 13:09:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43034) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSMTo-0005xv-Pw; Mon, 20 Sep 2021 12:49:21 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27306) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSMTk-0007wy-Rq; Mon, 20 Sep 2021 12:49:18 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2EDAB80928; Mon, 20 Sep 2021 12:49:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EA6C48067B; Mon, 20 Sep 2021 12:49:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1632156551; bh=g/KnIYWlBG7BmBdi5lcleWb5xIUSunIbL9GsrJmChX8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DJqtwWTRljJfxoRjWfLp//G02kB0hnDxFfvzcxc0eaSaHI8BudvOzvCAjennr2Uqx vJN96gtB/v/mESsHeVuvidY4dflt8kGgQFobmQPVubaBxJVDy6hjVmu5z3TS+xReGa AmKhzCbncokm78aRgWeGXIyhzZw1vTe2NgdDWogPd0QjcARa7ULJjJR5Pq0ukC3wHC jHeOTyHOW0Zdenlg9ELtTcejNqkMeXHjkNVAkBwZQGQy7DDRvrdPmcXTCWrt0HR8pc Qw4Cn4nj5+iTuVbRQLhUxQMsBtawcSNiiFZ7eyKDiYxDkr7GHsi2pAzNAplR8Y/I+F GM6BQrfqqaaaQ== Original-Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CEDD0120273; Mon, 20 Sep 2021 12:49:11 -0400 (EDT) In-Reply-To: <87tuih3jfq.fsf@gnu.org> (Amin Bandali's message of "Sat, 18 Sep 2021 13:03:21 -0400") 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:275155 gmane.emacs.erc.general:1594 Archived-At: > I believe the above two are enough to get ERC onto GNU ELPA, with a > minimum required Emacs version of 27. Sounds OK to me. > 1. Making the iso8601 dependency optional; or even better, adding it > to GNU ELPA and adapting it to only use the new functions like > `string-replace' on newer Emacsen. > > What do you think about this, Lars? IIRC there was a desire/attempt to export iso8601.el to GNU ELPA (can't remember what was the motivation back then) in the past, but it was non trivial because it relies on changes in the lower level functions that manipulate time. Note also that Debian stable comes with Emacs-27, so I'm not sure it's worthwhile trying to lower the bar much further. > 3. Not using `with-suppressed-warnings' (added in Emacs 27) on older > Emacsen and perhaps fall back on `with-no-warnings' for the single > use of that macro instead. In `verilog-mode.el` we just defined a `verilog--suppressed-warnings` macro, so we get backward compatibility without losing the extra precision of `with-suppressed-warnings`. > The second patch allows for a nonexistent erc-loaddefs, since that > file would not generated for the GNU ELPA package, and instead an > erc-autoloads.el would be generated and (IIRC) automatically loaded. Note that `erc-autoloads.el` and `erc-loaddefs.el` do not play quite the same role. `erc-autoloads.el` should ideally contain just the handful of ERC autoloads found in lisp/loaddefs.el. The way you're suggesting to do it, `erc-autoloads.el` will end up defining/autoloading a lot more "stuff" even when ERC is not used/loaded. Maybe it's not terribly important, but I think it's important to be aware of the difference. Stefan