Discussion:
[mh-e:bugs] #487 move from cl to cl-lib
Mike Kupfer
2017-02-14 04:03:50 UTC
Permalink
---

** [bugs:#487] move from cl to cl-lib**

**Status:** unread
**Milestone:** Unassigned
**Created:** Tue Feb 14, 2017 04:03 AM UTC by Mike Kupfer
**Last Updated:** Tue Feb 14, 2017 04:03 AM UTC
**Owner:** nobody
Since the old ‘cl.el’ does not use a clean namespace, Emacs has a policy that packages distributed with Emacs must not load ‘cl’ at run time. (It is ok for them to load ‘cl’ at _compile_ time, with ‘eval-when-compile’, and use the macros it provides.) There is no such restriction on the use of ‘cl-lib’. New code should use ‘cl-lib’ rather than ‘cl’.
MH-E uses cl but doesn't always avoid loading cl at runtime (see bug#25552 on debbugs.gnu.org). If we move to cl-lib, we could avoid this sort of bug and probably simplify the code.


---

Sent from sourceforge.net because mh-e-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Mike Kupfer
2017-02-14 04:06:23 UTC
Permalink
- **status**: unread --> open
- **Comment**:

See also #482.



---

** [bugs:#487] move from cl to cl-lib**

**Status:** open
**Milestone:** Unassigned
**Created:** Tue Feb 14, 2017 04:03 AM UTC by Mike Kupfer
**Last Updated:** Tue Feb 14, 2017 04:03 AM UTC
**Owner:** nobody
Since the old ‘cl.el’ does not use a clean namespace, Emacs has a policy that packages distributed with Emacs must not load ‘cl’ at run time. (It is ok for them to load ‘cl’ at _compile_ time, with ‘eval-when-compile’, and use the macros it provides.) There is no such restriction on the use of ‘cl-lib’. New code should use ‘cl-lib’ rather than ‘cl’.
MH-E uses cl but doesn't always avoid loading cl at runtime (see bug#25552 on debbugs.gnu.org). If we move to cl-lib, we could avoid this sort of bug and probably simplify the code.


---

Sent from sourceforge.net because mh-e-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Mike Kupfer
2017-02-14 04:07:52 UTC
Permalink
In debbugs #25552, Glenn Morris noted that cl-lib is available from elpa.gnu.org for Emacs older than 24.3.


---

** [bugs:#487] move from cl to cl-lib**

**Status:** open
**Milestone:** Unassigned
**Created:** Tue Feb 14, 2017 04:03 AM UTC by Mike Kupfer
**Last Updated:** Tue Feb 14, 2017 04:06 AM UTC
**Owner:** nobody
Since the old ‘cl.el’ does not use a clean namespace, Emacs has a policy that packages distributed with Emacs must not load ‘cl’ at run time. (It is ok for them to load ‘cl’ at _compile_ time, with ‘eval-when-compile’, and use the macros it provides.) There is no such restriction on the use of ‘cl-lib’. New code should use ‘cl-lib’ rather than ‘cl’.
MH-E uses cl but doesn't always avoid loading cl at runtime (see bug#25552 on debbugs.gnu.org). If we move to cl-lib, we could avoid this sort of bug and probably simplify the code.


---

Sent from sourceforge.net because mh-e-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/mh-e/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/mh-e/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Continue reading on narkive:
Loading...