Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Stefan Monnier]

>     Backport cl-defgeneric to Emacs 24

Better just use the cl-generic package (available from GNU ELPA), which
should provide a more reliable emulation.


        Stefan

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Chris Feng]

Yes, and my code might cause problems for other packages referring to
it, so I'll remove it. But I'd still keep some related code since it's
not (and perhaps should not be) covered by the cl-generic package from
GNU ELPA.

On Sun, Sep 20, 2015 at 11:25 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>     Backport cl-defgeneric to Emacs 24
>
> Better just use the cl-generic package (available from GNU ELPA), which
> should provide a more reliable emulation.
>
>
>         Stefan

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Chris Feng]

I released xelb in GNU ELPA but was surprised by the outcomes:

* I added cl-generic 0.2 as a dependency of xelb to make it working on
Emacs 24. But this causes a problem on Emacs 25: the builtin
cl-generic of version 1.0 is not listed in
`package--builtin-versions', so package.el would wrongly install
cl-generic 0.2 from GNU ELPA. Perhaps `package--builtin-versions'
should include cl-generic, or this variable would be useless since it
seems it's is only used in package.el.

* Due to a bug of EIEIO in Emacs 24, I cannot define classes with more
than 101 slots. Would it be possible to fix it in the next release of
Emacs 24 (by simply setting a fallback length of the obarray in
`eieio-defclass')?

* And finally a minor issue: README.org was picked as the long
description of this package. I personally consider org-mode files as
well as reStructuredText or other markup files, when not properly
rendered, are not easily readable. In fact I made this file mainly for
the GitHub project page and thought GNU ELPA would pick the
'Commentary:' section. Of course I can rename it to something not
mentioned in archive-contents.el to work around this problem.

Chris

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Stefan Monnier]

> The builtin cl-generic of version 1.0 is not listed in
> `package--builtin-versions',

That's a bug.  IIUC it's because cl-generic.el is preloaded, whereas
package--builtin-versions is populated via loaddefs.el.

> * Due to a bug of EIEIO in Emacs 24, I cannot define classes with more
> than 101 slots. Would it be possible to fix it in the next release of
> Emacs 24 (by simply setting a fallback length of the obarray in
> `eieio-defclass')?

Not sure what you're referring to.

> * And finally a minor issue: README.org was picked as the long
> description of this package. I personally consider org-mode files as
> well as reStructuredText or other markup files, when not properly
> rendered, are not easily readable. In fact I made this file mainly for
> the GitHub project page and thought GNU ELPA would pick the
> 'Commentary:' section. Of course I can rename it to something not
> mentioned in archive-contents.el to work around this problem.

If you use README.md, it will be ignored (quoting
elpa.git/admin/archive-contents.el:

      (let ((rm (archive--get-section
                 "Commentary" '("README" "README.rst"
                                ;; Most README.md files seem to be currently
                                ;; worse than the Commentary: section :-(
                                ;; "README.md"
                                "README.org")
                 srcdir mainsrcfile)))


-- Stefan

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Chris Feng]

>> * Due to a bug of EIEIO in Emacs 24, I cannot define classes with more
>> than 101 slots. Would it be possible to fix it in the next release of
>> Emacs 24 (by simply setting a fallback length of the obarray in
>> `eieio-defclass')?
>
> Not sure what you're referring to.

I meant in the following snippet (from eieio-defclass in eieio-core.el
of emacs-24 branch) `vl' would be nil if the class has more than 101
slots, and the subsequent `make-vector` would fail:

(let* ((cnt 0)
       (pubsyms (eieio--class-public-a newc))
       (prots (eieio--class-protection newc))
       (l (length pubsyms))
       (vl (let ((primes '( 3 5 7 11 13 17 19 23 29 31 37 41 43 47
                              53 59 61 67 71 73 79 83 89 97 101 )))
             (while (and primes (< (car primes) l))
               (setq primes (cdr primes)))
             (car primes)))
       (oa (make-vector vl 0))
       (newsym))

>> * And finally a minor issue: README.org was picked as the long
>> description of this package. I personally consider org-mode files as
>> well as reStructuredText or other markup files, when not properly
>> rendered, are not easily readable. In fact I made this file mainly for
>> the GitHub project page and thought GNU ELPA would pick the
>> 'Commentary:' section. Of course I can rename it to something not
>> mentioned in archive-contents.el to work around this problem.
>
> If you use README.md, it will be ignored (quoting
> elpa.git/admin/archive-contents.el:
>
>       (let ((rm (archive--get-section
>                  "Commentary" '("README" "README.rst"
>                                 ;; Most README.md files seem to be currently
>                                 ;; worse than the Commentary: section :-(
>                                 ;; "README.md"
>                                 "README.org")
>                  srcdir mainsrcfile)))

Yes, I mentioned this solution. But I guess the exclusion of README.md
is merely a temporary measure?

Re: [elpa] externals/xelb ad879fb: Backport cl-defgeneric to Emacs 24

[Stefan Monnier]

> I meant in the following snippet (from eieio-defclass in eieio-core.el
> of emacs-24 branch) `vl' would be nil if the class has more than 101
> slots, and the subsequent `make-vector` would fail:

Duh!  I see.  Sadly, it's too late to fix it, since there's no plan to
make a new Emacs-24 release.

> Yes, I mentioned this solution. But I guess the exclusion of README.md
> is merely a temporary measure?

I don't think it's temporary.  More specifically it'll be with us at
least until there's some mechanism to tell GNU ELPA whether to use
README.md or not.

BTW, an alternative might be to move the Commentary text to a new README
file.


        Stefan