[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ELPA] New package: ERC

From: Stefan Monnier
Subject: Re: [ELPA] New package: ERC
Date: Mon, 20 Sep 2021 12:48:43 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]