[ELPA] New package: ERC

[ELPA] New package: ERC

[Amin Bandali]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Hello,

It's about time we added ERC to GNU ELPA. :)

The first attached patch against elpa.git does that.

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.

I believe the above two are enough to get ERC onto GNU ELPA, with a
minimum required Emacs version of 27.

I would like to lower that lower bound by a few Emacs major versions
so that users on older Emacsen could install the package as well.
It seems that we could bring this lower bound down to Emacs 25 with
relatively small amount of effort, by:

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?

2. Adding browse-url to GNU ELPA, since erc-button uses its
   `browse-url-button-regexp', which was only added in Emacs 27.
   We could probably adjust erc-button to fall back onto Gnus's
   `gnus-button-url-regexp' on older Emacsen, but I think I'd
   rather not do that.

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.

It might be possible to further lower the minimum required version of
down to the 24 series, but that would require doing something about
the uses of `define-inline' from inline.el, which was added in
Emacs 25.  Not sure if it would make sense or be possible to get
inline added to GNU ELPA for Emacsen older than 25.  Stefan?

Thanks,
amin


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-erc-Add-package.patch --]
[-- Type: text/x-diff, Size: 2037 bytes --]

From 5581aa3c0fea8dabef3659928e234fc8d2e7ce82 Mon Sep 17 00:00:00 2001
From: Amin Bandali <bandali@gnu.org>
Date: Fri, 17 Sep 2021 22:27:08 -0400
Subject: [PATCH] * elpa-packages (erc): Add package

---
 elpa-packages | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index cffd9a63ca..9b54932bd5 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -158,6 +158,44 @@
   :auto-sync t)
  ("enwc"		:url "hg::https://hg.savannah.nongnu.org/hgweb/enwc/")
  ("epoch-view"		:url nil)
+ ("erc"
+  :core ("lisp/erc/erc-autoaway.el"
+         "lisp/erc/erc-backend.el"
+         "lisp/erc/erc-button.el"
+         "lisp/erc/erc-capab.el"
+         "lisp/erc/erc-dcc.el"
+         "lisp/erc/erc-desktop-notifications.el"
+         "lisp/erc/erc-ezbounce.el"
+         "lisp/erc/erc-fill.el"
+         "lisp/erc/erc-goodies.el"
+         "lisp/erc/erc-ibuffer.el"
+         "lisp/erc/erc-identd.el"
+         "lisp/erc/erc-imenu.el"
+         "lisp/erc/erc-join.el"
+         "lisp/erc/erc-lang.el"
+         "lisp/erc/erc-list.el"
+         "lisp/erc/erc-log.el"
+         "lisp/erc/erc-match.el"
+         "lisp/erc/erc-menu.el"
+         "lisp/erc/erc-netsplit.el"
+         "lisp/erc/erc-networks.el"
+         "lisp/erc/erc-notify.el"
+         "lisp/erc/erc-page.el"
+         "lisp/erc/erc-pcomplete.el"
+         "lisp/erc/erc-replace.el"
+         "lisp/erc/erc-ring.el"
+         "lisp/erc/erc-services.el"
+         "lisp/erc/erc-sound.el"
+         "lisp/erc/erc-speedbar.el"
+         "lisp/erc/erc-spelling.el"
+         "lisp/erc/erc-stamp.el"
+         "lisp/erc/erc-status-sidebar.el"
+         "lisp/erc/erc-track.el"
+         "lisp/erc/erc-truncate.el"
+         "lisp/erc/erc-xdcc.el"
+         "lisp/erc/erc.el"
+         "doc/misc/erc.texi"
+         :doc "erc.texi"))
  ("ergoemacs-mode"	:url "https://github.com/ergoemacs/ergoemacs-mode.git")
  ("excorporate"		:url nil)
  ("expand-region"	:url "https://github.com/magnars/expand-region.el")
-- 
2.17.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-lisp-erc-erc.el-Don-t-error-if-erc-loaddefs-does-not.patch --]
[-- Type: text/x-diff, Size: 765 bytes --]

From 085f074a2fe00648eb407f3b70532282abc1be8e Mon Sep 17 00:00:00 2001
From: Amin Bandali <bandali@gnu.org>
Date: Sat, 18 Sep 2021 12:53:59 -0400
Subject: [PATCH] * lisp/erc/erc.el: Don't error if erc-loaddefs does not
 exist.

That autoload file is created as part of the Emacs compilation
process, however we would like ERC to be usable if used outside
emacs.git (e.g. if installed from GNU ELPA).
---
 lisp/erc/erc.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el
index 1f39644f75..7554919720 100644
--- a/lisp/erc/erc.el
+++ b/lisp/erc/erc.el
@@ -58,7 +58,7 @@
 
 ;;; Code:
 
-(load "erc-loaddefs" nil t)
+(load "erc-loaddefs" 'noerror 'nomessage)
 
 (require 'cl-lib)
 (require 'format-spec)
-- 
2.17.1

Re: [ELPA] New package: ERC

[Lars Ingebrigtsen]

Amin Bandali <bandali@gnu.org> writes:

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

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.

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:

> 2. Adding browse-url to GNU ELPA, since erc-button uses its
>    `browse-url-button-regexp', which was only added in Emacs 27.
>    We could probably adjust erc-button to fall back onto Gnus's
>    `gnus-button-url-regexp' on older Emacsen, but I think I'd
>    rather not do that.

It's just a slippery slope, as you've found out with erc.  Putting stuff
into ELPA adds a real added maintenance cost, because you can't use
modern idioms and better constructs like:

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

Using `with-no-warnings' is usually a disservice, because it pastes over
other potential errors other than the one you meant to inhibit.

So I'm sceptical about all of this -- is the added utility of having
these libraries in ELPA for users so big that we want to take on the
added maintenance burden?

I'm doubtful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

Re: [ELPA] New package: ERC

[Philip Kaludercic]

Amin Bandali <bandali@gnu.org> writes:

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

It certainly could, the question is only if the functionality of a 300+
line file should be copied into a general-purpose compatibility library.

-- 
	Philip Kaludercic

Re: [ELPA] New package: ERC

[Amin Bandali]

Philip Kaludercic writes:

> Amin Bandali <bandali@gnu.org> writes:
>
>> 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'.
>
> It certainly could, the question is only if the functionality of a 300+
> line file should be copied into a general-purpose compatibility library.

By "300+ line file" you mean `iso8601.el'?  If so, I would indeed not
expect `compat.el' to duplicate all of that.  However, I wonder if
`compat.el' may be able to house some funs/vars needed to port
`iso8601.el' to older Emacsen?  I haven't had a close look at it, nor
at the time-related changes in Emacs 27, to know if this would be
doable in a reasonable way.  Perhaps Lars might.

Re: [ELPA] New package: ERC

[Philip Kaludercic]

Amin Bandali <bandali@gnu.org> writes:

> Philip Kaludercic writes:
>
>> Amin Bandali <bandali@gnu.org> writes:
>>
>>> 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'.
>>
>> It certainly could, the question is only if the functionality of a 300+
>> line file should be copied into a general-purpose compatibility library.
>
> By "300+ line file" you mean `iso8601.el'?  If so, I would indeed not
> expect `compat.el' to duplicate all of that.  However, I wonder if
> `compat.el' may be able to house some funs/vars needed to port
> `iso8601.el' to older Emacsen?  

That should certainly be possible. I don't think iso8601 depends on
anything that wasn't possible with Emacs 24. 

> I haven't had a close look at it, nor at the time-related changes in
> Emacs 27, to know if this would be doable in a reasonable way.
> Perhaps Lars might.

-- 
	Philip Kaludercic

Re: [ELPA] New package: ERC

[Amin Bandali]

Philip Kaludercic writes:

> Amin Bandali <bandali@gnu.org> writes:
>
>> Philip Kaludercic writes:
>>
>>> Amin Bandali <bandali@gnu.org> writes:
>>>
>>>> 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'.
>>>
>>> It certainly could, the question is only if the functionality of a 300+
>>> line file should be copied into a general-purpose compatibility library.
>>
>> By "300+ line file" you mean `iso8601.el'?  If so, I would indeed not
>> expect `compat.el' to duplicate all of that.  However, I wonder if
>> `compat.el' may be able to house some funs/vars needed to port
>> `iso8601.el' to older Emacsen?  
>
> That should certainly be possible. I don't think iso8601 depends on
> anything that wasn't possible with Emacs 24. 

Cool.  In that case I guess we could hope to potentially see iso8601
on GNU ELPA at some later point in the future with compatibility down
to Emacs 26 or perhaps a bit older. :)

>> I haven't had a close look at it, nor at the time-related changes in
>> Emacs 27, to know if this would be doable in a reasonable way.
>> Perhaps Lars might.

-- 
https://bndl.org

Re: [ELPA] New package: ERC

[Stefan Kangas]

Amin Bandali <bandali@gnu.org> writes:

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

I just marked the unused stuff in there explicitly obsolete, so it
should be easy to just move it out of obsolete/ and continue from there.

Perhaps it is better to do it before Emacs 28.1 to avoid any confusion,
even if the only concrete step is to move the file out of obsolete/.

Re: [ELPA] New package: ERC

[Amin Bandali]

Stefan Kangas writes:

> Amin Bandali <bandali@gnu.org> writes:
>
>> 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.
>
> I just marked the unused stuff in there explicitly obsolete, so it
> should be easy to just move it out of obsolete/ and continue from there.
>
> Perhaps it is better to do it before Emacs 28.1 to avoid any confusion,
> even if the only concrete step is to move the file out of obsolete/.
>

Thanks.  I've been a bit torn about restoring `erc-compat.el'
vs. potentially working something out with Philip's `compat.el'.
However, I suppose if we're very close to `emacs-28' being cut (as in
days ?) and if `compat.el' is currently mainly only a proposal and not
being urgently added, it would probably be better for me to go ahead
and restore `erc-compat.el' sooner rather than later (in a day or two)
and do what we already used to for ERC in the past anyway.

Re: [ELPA] New package: ERC

[Philip Kaludercic]

Amin Bandali <bandali@gnu.org> writes:

> Stefan Kangas writes:
>
>> Amin Bandali <bandali@gnu.org> writes:
>>
>>> 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.
>>
>> I just marked the unused stuff in there explicitly obsolete, so it
>> should be easy to just move it out of obsolete/ and continue from there.
>>
>> Perhaps it is better to do it before Emacs 28.1 to avoid any confusion,
>> even if the only concrete step is to move the file out of obsolete/.
>>
>
> Thanks.  I've been a bit torn about restoring `erc-compat.el'
> vs. potentially working something out with Philip's `compat.el'.
> However, I suppose if we're very close to `emacs-28' being cut (as in
> days ?) and if `compat.el' is currently mainly only a proposal and not
> being urgently added,

To clarify, compat would be an ELPA package (and if accepted, it
wouldn't be added before Emacs 28.1 is released).

>it would probably be better for me to go ahead
> and restore `erc-compat.el' sooner rather than later (in a day or two)
> and do what we already used to for ERC in the past anyway.

-- 
	Philip Kaludercic

Re: [ELPA] New package: ERC

[Amin Bandali]

Philip Kaludercic writes:

[...]
>
> To clarify, compat would be an ELPA package (and if accepted, it
> wouldn't be added before Emacs 28.1 is released).

That's clear, thanks.  I'll go with the (restoring) erc-compat
approach for the time being, and later in the future we could make
ERC optionally depend on compat if it means being able to use iso8601
on older Emacsen.

-- 
https://bndl.org

Re: [ELPA] New package: ERC

[Stefan Monnier]

>> 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.
>
> Thanks for pointing this out.  Admittedly, my understanding of the
> autoload machinery is somewhat lacking.  Would you please elaborate
> more on this?

I think I was just confused.  I thought ERC used a similar mechanism to
the one used by MH-E and Tramp (where they use special lisp/Makefile
rules to generate their <pkg>-loaddefs.el files).


        Stefan

Re: [ELPA] New package: ERC

[Amin Bandali]

Stefan Monnier writes:

>>> 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.
>>
>> Thanks for pointing this out.  Admittedly, my understanding of the
>> autoload machinery is somewhat lacking.  Would you please elaborate
>> more on this?
>
> I think I was just confused.  I thought ERC used a similar mechanism to
> the one used by MH-E and Tramp (where they use special lisp/Makefile
> rules to generate their <pkg>-loaddefs.el files).
>
>
>         Stefan
>
>

Oh, indeed.  Here's the commit that introduced erc-loaddefs.el:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=95369ac346d75a7b75bc2c5adf632cc4faa1241a
It just set the `generated-autoload-file' file local variable to
"erc-loaddefs.el" in erc*.el.

So I suppose it's fine as is, and I could proceed with my initially
proposed patches.

My only question at this point is, would the recent change to GNU ELPA
machinery where it pulls the exact commit changing the Version apply
for a new addition like ERC as well?  Does that mean adding ERC right
now would take it from this commit?
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4fa778b62c936d5d3a3cc348043c072d7011f13f

-- 
https://bndl.org

Re: [ELPA] New package: ERC

[Stefan Monnier]

> My only question at this point is, would the recent change to GNU ELPA
> machinery where it pulls the exact commit changing the Version apply
> for a new addition like ERC as well?  Does that mean adding ERC right
> now would take it from this commit?
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4fa778b62c936d5d3a3cc348043c072d7011f13f

Yes.


        Stefan

Re: [ELPA] New package: ERC

[Amin Bandali]

Stefan Monnier writes:

>> My only question at this point is, would the recent change to GNU ELPA
>> machinery where it pulls the exact commit changing the Version apply
>> for a new addition like ERC as well?  Does that mean adding ERC right
>> now would take it from this commit?
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4fa778b62c936d5d3a3cc348043c072d7011f13f
>
> Yes.
>
>
>         Stefan
>
>

Okay, thanks for confirming.  In that case I'll add ERC to elpa.git
only after bumping Version, which should be very soon anyway.

-- 
https://bndl.org

Re: [ELPA] New package: ERC

[Stefan Monnier]

> 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

Re: [ELPA] New package: ERC

[Emanuel Berg via General discussion about ERC]

Amin Bandali wrote:

> It's about time we added ERC to GNU ELPA. :)

I'm obviously out of the loop here but isn't ERC shipped
with/in vanilla Emacs already?

So why would one put it in ELPA (no disrespect)?

Or are we outsourcing key Emacs resources to remote
repositories, much like the KGB did the Soviet Union's
monetary and natural reserves, just before it collapsed?

wonders,
yours truly

-- 
underground experts united
https://dataswamp.org/~incal

Re: [ELPA] New package: ERC

[Corwin Brust]

Hi Emanuel!

On Mon, Sep 20, 2021 at 7:16 PM Emanuel Berg via General discussion
about ERC <emacs-erc@gnu.org> wrote:
>
> Amin Bandali wrote:
>
> > It's about time we added ERC to GNU ELPA. :)
>
> I'm obviously out of the loop here but isn't ERC shipped
> with/in vanilla Emacs already?
>
> So why would one put it in ELPA (no disrespect)?
>

I think there are several reasons why it makes sense to place a core
package also in ELPA.  In this case, I see a bunch of benefits; I find
these three most exciting:

1. Getting new ERC versions from ELPA means easier, more rapid access
to fixes and new features.

Currently, our options for updating ERC are
a) building Emacs from the main development branch (not everyone finds
this easy),
b) merging elisp from that branch (when that works, the ERC that will
come with Emacs 28 will have need of at least Emacs 27, IIUC), or
c) waiting for new Emacs releases to be cut, publishing the
accumulated ERC changes since the last Emacs release.

My sense is that this last is most common, at present though I won't
claim I have any data to support that theory ;)

2. Releasing ERC more frequently can improve ERC's quality.

Currently, we release ERC once per Emacs version.  As ERC starts to
release more frequently than Emacs people will be able to experiment
with and provide feedback and bug reports on each.  That additional
testing should (eventually) lead to more stability from the ERC that
ships with each Emacs release.

3. Shorter development cycles will make hacking on ERC more fun.

Development is more exciting the more people who, and the more rapidly
people do see our changes.

By releasing ERC more often (vs Emacs releases), we make it easier for
ERC to be a "proving ground".  This can help increase the desire of
others to try contributing to ERC and thereby gain feedback, skill,
and confidence, and get encouraged to contribute to other ways, such
as developing contributions to other parts of Emacs.  More frequent
releases can also make ERC more useful for experimenting with new
approaches/techniques that we (aspiring) ERC hackers consider may be
useful in other parts of Emacs (if they work, people like them, they
don't turn out to be difficult to maintain, ...).

Cheers!
-- 
Corwin
corwin@bru.st

Re: [ELPA] New package: ERC

[Emanuel Berg via General discussion about ERC]

Corwin Brust wrote:

> I think there are several reasons why it makes sense to
> place a core package also in ELPA.

OK _also_ in ELPA. So people don't have to opt-in to get
it. Good.

> In this case, I see a bunch of benefits; I find these three
> most exciting [...]
>
> 1. Getting new ERC versions from ELPA means easier, more
>    rapid access to fixes and new features. [...]
>
> 2. Releasing ERC more frequently can improve ERC's quality.
>    [...]
>
> 3. Shorter development cycles will make hacking on ERC more
>    fun. [...]

OK, so you want to decouple it from the Emacs wheel which
spins slower ...

I wonder tho if people who are into that kind of speed aren't
already downloading the latest Emacs available to compile
locally anyway ... ? Don't they get the latest ERC then
as well?

Or does the "ELPA ERC" wheel (is it predicted to) spin faster
than that as well? Or even faster?

But I don't really care as long as it is built-in as well.
More roads, more traffic, no matter the opposite being claimed
multiple times all falsely.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [ELPA] New package: ERC

[Amin Bandali]

Emanuel Berg via General discussion about ERC writes:

> Corwin Brust wrote:
>
>> I think there are several reasons why it makes sense to
>> place a core package also in ELPA.
>
> OK _also_ in ELPA. So people don't have to opt-in to get
> it. Good.

Yes.

>> In this case, I see a bunch of benefits; I find these three
>> most exciting [...]
>>
>> 1. Getting new ERC versions from ELPA means easier, more
>>    rapid access to fixes and new features. [...]
>>
>> 2. Releasing ERC more frequently can improve ERC's quality.
>>    [...]
>>
>> 3. Shorter development cycles will make hacking on ERC more
>>    fun. [...]
>
> OK, so you want to decouple it from the Emacs wheel which
> spins slower ...
>
> I wonder tho if people who are into that kind of speed aren't
> already downloading the latest Emacs available to compile
> locally anyway ... ? Don't they get the latest ERC then
> as well?

The reasoning here is that building and installing ERC is considerably
easier and faster than that of all of Emacs, and it's convenient to be
able to get latest features of ERC with a simple M-x package-install.
For instance on a cheap/small VM, I'd rather install whatever Emacs
version comes with the distro as opposed to building my own, but still
be able to use the latest version of ERC conveniently, from GNU ELPA.

> Or does the "ELPA ERC" wheel (is it predicted to) spin faster
> than that as well? Or even faster?
>
> But I don't really care as long as it is built-in as well.
> More roads, more traffic, no matter the opposite being claimed
> multiple times all falsely.

To be clear, ERC will continue to be included and developed in Emacs
core and there are no plans for changing that.  This is only in
addition to that.