all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [ELPA] New package: ERC
@ 2021-09-18 17:03 Amin Bandali
  2021-09-19 14:38 ` Lars Ingebrigtsen
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-18 17:03 UTC (permalink / raw)
  To: emacs-devel, emacs-erc; +Cc: larsi, monnier

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


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-18 17:03 [ELPA] New package: ERC Amin Bandali
@ 2021-09-19 14:38 ` Lars Ingebrigtsen
  2021-09-26 15:22   ` Amin Bandali
  2021-09-20 16:48 ` Stefan Monnier
  2021-09-21  0:16 ` Emanuel Berg via General discussion about ERC
  2 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-19 14:38 UTC (permalink / raw)
  To: Amin Bandali; +Cc: emacs-erc, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-18 17:03 [ELPA] New package: ERC Amin Bandali
  2021-09-19 14:38 ` Lars Ingebrigtsen
@ 2021-09-20 16:48 ` Stefan Monnier
  2021-09-21  0:16 ` Emanuel Berg via General discussion about ERC
  2 siblings, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2021-09-20 16:48 UTC (permalink / raw)
  To: Amin Bandali; +Cc: emacs-devel, emacs-erc, larsi

> 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




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-18 17:03 [ELPA] New package: ERC Amin Bandali
  2021-09-19 14:38 ` Lars Ingebrigtsen
  2021-09-20 16:48 ` Stefan Monnier
@ 2021-09-21  0:16 ` Emanuel Berg via General discussion about ERC
  2021-09-21  5:31   ` Corwin Brust
  2 siblings, 1 reply; 20+ messages in thread
From: Emanuel Berg via General discussion about ERC @ 2021-09-21  0:16 UTC (permalink / raw)
  To: emacs-erc; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-21  0:16 ` Emanuel Berg via General discussion about ERC
@ 2021-09-21  5:31   ` Corwin Brust
  2021-09-21  7:12     ` Emanuel Berg via General discussion about ERC
  0 siblings, 1 reply; 20+ messages in thread
From: Corwin Brust @ 2021-09-21  5:31 UTC (permalink / raw)
  To: Emanuel Berg, emacs-erc; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-21  5:31   ` Corwin Brust
@ 2021-09-21  7:12     ` Emanuel Berg via General discussion about ERC
  2021-09-21 23:56       ` Amin Bandali
  0 siblings, 1 reply; 20+ messages in thread
From: Emanuel Berg via General discussion about ERC @ 2021-09-21  7:12 UTC (permalink / raw)
  To: emacs-erc; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-21  7:12     ` Emanuel Berg via General discussion about ERC
@ 2021-09-21 23:56       ` Amin Bandali
  0 siblings, 0 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-21 23:56 UTC (permalink / raw)
  To: emacs-erc; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-19 14:38 ` Lars Ingebrigtsen
@ 2021-09-26 15:22   ` Amin Bandali
  2021-09-26 19:28     ` Philip Kaludercic
                       ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-26 15:22 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-erc, Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 15:22   ` Amin Bandali
@ 2021-09-26 19:28     ` Philip Kaludercic
  2021-09-26 20:41       ` Amin Bandali
  2021-09-26 20:15     ` Stefan Kangas
  2021-09-27 19:42     ` Stefan Monnier
  2 siblings, 1 reply; 20+ messages in thread
From: Philip Kaludercic @ 2021-09-26 19:28 UTC (permalink / raw)
  To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 15:22   ` Amin Bandali
  2021-09-26 19:28     ` Philip Kaludercic
@ 2021-09-26 20:15     ` Stefan Kangas
  2021-09-26 21:03       ` Amin Bandali
  2021-09-27 19:42     ` Stefan Monnier
  2 siblings, 1 reply; 20+ messages in thread
From: Stefan Kangas @ 2021-09-26 20:15 UTC (permalink / raw)
  To: Amin Bandali, Lars Ingebrigtsen; +Cc: emacs-erc, Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 19:28     ` Philip Kaludercic
@ 2021-09-26 20:41       ` Amin Bandali
  2021-09-27 10:22         ` Philip Kaludercic
  0 siblings, 1 reply; 20+ messages in thread
From: Amin Bandali @ 2021-09-26 20:41 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel

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.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 20:15     ` Stefan Kangas
@ 2021-09-26 21:03       ` Amin Bandali
  2021-09-27 10:23         ` Philip Kaludercic
  0 siblings, 1 reply; 20+ messages in thread
From: Amin Bandali @ 2021-09-26 21:03 UTC (permalink / raw)
  To: Stefan Kangas, Philip Kaludercic
  Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel

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.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 20:41       ` Amin Bandali
@ 2021-09-27 10:22         ` Philip Kaludercic
  2021-09-28  2:36           ` Amin Bandali
  0 siblings, 1 reply; 20+ messages in thread
From: Philip Kaludercic @ 2021-09-27 10:22 UTC (permalink / raw)
  To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-erc, Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 21:03       ` Amin Bandali
@ 2021-09-27 10:23         ` Philip Kaludercic
  2021-09-29  1:26           ` Amin Bandali
  0 siblings, 1 reply; 20+ messages in thread
From: Philip Kaludercic @ 2021-09-27 10:23 UTC (permalink / raw)
  To: Amin Bandali
  Cc: Lars Ingebrigtsen, emacs-devel, emacs-erc, Stefan Kangas,
	Stefan Monnier

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-26 15:22   ` Amin Bandali
  2021-09-26 19:28     ` Philip Kaludercic
  2021-09-26 20:15     ` Stefan Kangas
@ 2021-09-27 19:42     ` Stefan Monnier
  2021-09-29  1:40       ` Amin Bandali
  2 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-09-27 19:42 UTC (permalink / raw)
  To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-devel, emacs-erc

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




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-27 10:22         ` Philip Kaludercic
@ 2021-09-28  2:36           ` Amin Bandali
  0 siblings, 0 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-28  2:36 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-erc, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-27 10:23         ` Philip Kaludercic
@ 2021-09-29  1:26           ` Amin Bandali
  0 siblings, 0 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-29  1:26 UTC (permalink / raw)
  To: Philip Kaludercic
  Cc: Lars Ingebrigtsen, emacs-devel, emacs-erc, Stefan Kangas,
	Stefan Monnier

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-27 19:42     ` Stefan Monnier
@ 2021-09-29  1:40       ` Amin Bandali
  2021-09-29  3:30         ` Stefan Monnier
  0 siblings, 1 reply; 20+ messages in thread
From: Amin Bandali @ 2021-09-29  1:40 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-erc, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-29  1:40       ` Amin Bandali
@ 2021-09-29  3:30         ` Stefan Monnier
  2021-09-29  4:11           ` Amin Bandali
  0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2021-09-29  3:30 UTC (permalink / raw)
  To: Amin Bandali; +Cc: Lars Ingebrigtsen, emacs-devel, emacs-erc

> 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




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [ELPA] New package: ERC
  2021-09-29  3:30         ` Stefan Monnier
@ 2021-09-29  4:11           ` Amin Bandali
  0 siblings, 0 replies; 20+ messages in thread
From: Amin Bandali @ 2021-09-29  4:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-erc, emacs-devel

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-09-29  4:11 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-09-18 17:03 [ELPA] New package: ERC Amin Bandali
2021-09-19 14:38 ` Lars Ingebrigtsen
2021-09-26 15:22   ` Amin Bandali
2021-09-26 19:28     ` Philip Kaludercic
2021-09-26 20:41       ` Amin Bandali
2021-09-27 10:22         ` Philip Kaludercic
2021-09-28  2:36           ` Amin Bandali
2021-09-26 20:15     ` Stefan Kangas
2021-09-26 21:03       ` Amin Bandali
2021-09-27 10:23         ` Philip Kaludercic
2021-09-29  1:26           ` Amin Bandali
2021-09-27 19:42     ` Stefan Monnier
2021-09-29  1:40       ` Amin Bandali
2021-09-29  3:30         ` Stefan Monnier
2021-09-29  4:11           ` Amin Bandali
2021-09-20 16:48 ` Stefan Monnier
2021-09-21  0:16 ` Emanuel Berg via General discussion about ERC
2021-09-21  5:31   ` Corwin Brust
2021-09-21  7:12     ` Emanuel Berg via General discussion about ERC
2021-09-21 23:56       ` Amin Bandali

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.