From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Amin Bandali Newsgroups: gmane.emacs.erc.general,gmane.emacs.devel Subject: Re: [ELPA] New package: ERC Date: Sun, 26 Sep 2021 11:22:05 -0400 Message-ID: <87o88f746a.fsf@gnu.org> References: <87tuih3jfq.fsf@gnu.org> <875yuwpr4o.fsf@gnus.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="11470"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-erc@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Sun Sep 26 17:22:34 2021 Return-path: Envelope-to: sf-erc-help@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 1mUVz7-0002ka-3k for sf-erc-help@m.gmane-mx.org; Sun, 26 Sep 2021 17:22:33 +0200 Original-Received: from localhost ([::1]:45708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUVz6-0006z2-3U for sf-erc-help@m.gmane-mx.org; Sun, 26 Sep 2021 11:22:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUVyj-0006yi-K4; Sun, 26 Sep 2021 11:22:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50196) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUVyh-0005CT-E0; Sun, 26 Sep 2021 11:22:08 -0400 Original-Received: from [2607:fea8:3fdf:f2d9:b468:6d78:c63:9e25] (port=47920 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUVyg-0006w5-Nt; Sun, 26 Sep 2021 11:22:07 -0400 In-Reply-To: <875yuwpr4o.fsf@gnus.org> X-BeenThere: emacs-erc@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion about ERC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Original-Sender: "emacs-erc" Xref: news.gmane.io gmane.emacs.erc.general:1600 gmane.emacs.devel:275515 Archived-At: Lars Ingebrigtsen writes: [...] > > I don't think there's much point in using `string-replace' at all in > packages that are meant to be used in older Emacs versions -- they can > be trivially rewritten to use `replace-regexp-in-string' always. Right. Or it wouldn't be too hard to make the use conditional on the Emacs version, as I did for the existing uses in ERC. > But I'm not sure whether it makes much sense to put a bunch of the > built-in Emacs libraries in ELPA -- perhaps it does make sense for > iso8601.el (even if there's been some internal time changes for time > representation of sub-second times), but for instance: > [...] Stefan Monnier writes: [...] > > 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. Thanks for pointing that out; I'd completely forgotten about it. For others who may be interested in reading about it: https://lists.gnu.org/archive/html/emacs-devel/2020-02/msg00064.html https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00376.html Perhaps with a closer look/reexamination, Lars could port `iso8601.el' to Emacs < 27 -- and it'd be nice -- but as far as ERC is concerned, I think it's not critical (our use for it is an optional convenience feature for ignoring users for a certain amount of time, rather than indefinitely), and I think we could make that part of it available only if Emacs >= 27. > Note also that Debian stable comes with Emacs-27, so I'm not sure it's > worthwhile trying to lower the bar much further. Right. I wouldn't want to go too far back, but I know of several users who are on 26 or 25 by necessity (somewhat) and would appreciate getting ERC updates. So ideally I'd like to aim for 25 compatibility. >> 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`. Oh, right. I just recalled that we used to have an `erc-compat.el' that we obsoleted last year. I think I will revive that and put it back into lisp/erc/, and that the additional things I wanted in there. On this topic, I've briefly seen philipk's proposal for `compat.el' on emacs-devel, but I'm not yet sure if it's meant to tend to the needs of individual packages like ERC and add funs/vars on request. So for ERC's purposes it might be better to revive and use `erc-compat.el'. >> 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 Thanks for pointing this out. Admittedly, my understanding of the autoload machinery is somewhat lacking. Would you please elaborate more on this? I'm guessing a possible solution would be reducing the number of `;;;###autoload' cookies in erc*.el files; but that would also affect folks using the ERC that's bundled into Emacs relying on `erc-loaddefs.el', and I'm not sure that's the best/desired solution anyway. Is there a way to be more nuanced about this? What would be your suggestion? Thanks, amin