Re: [ELPA] New package: ERC

[Amin Bandali]

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