Bugzilla Bug 187332

Patch to follow...we will apply it anytime soon

Created an attachment (id=126569) [details]
Patch for ebuild, no sitefile needed

Created an attachment (id=126570) [details]
Patch for ebuild

Argh, chose the wrong patch

(In reply to comment #2)
> Created an attachment (id=126570) [edit] [details]
> Patch for ebuild
> 
> Argh, chose the wrong patch
> 

it's maintainer needed so just go ahead and commit it.

fixed

(In reply to comment #4)
> fixed

Not really, since libidn-1.0 is not fixed.

Fixed in 1.0-r1.

Adding xemacs to CC. Hans, maybe you want to look at XEmacs support?

Yes, I'll probably want to add xemacs support for this as well, but it will not
be so easy. There is only one lispdir option to the configure script, and
that's already taken by emacs. So we'd need to either rig this so that only
emacs or xemacs can be specified, or the install and compile options need to be
a bit more convoluted. I'm going to put this on the backburner since it won't
be a quick fix.

1.0 fixed by ulm, emacs is out of here...only xemacs left.

Christian, why didn't you use a sitefile and instead chose to tell the user via
elog that he has to tweak his .emacs or site-start.el file?

I think it would be better to add these three lines to site-gentoo.el via
elisp-common.eclass, but maybe you had some reason unknown to me for doing it
this way.

(In reply to comment #9)
> Christian, why didn't you use a sitefile and instead chose to tell the user via
> elog that he has to tweak his .emacs or site-start.el file?
> 
> I think it would be better to add these three lines to site-gentoo.el via
> elisp-common.eclass, but maybe you had some reason unknown to me for doing it
> this way.

 Because that's our policy.  To quote from
http://www.gentoo.org/proj/en/lisp/emacs/emacs.xml: 
"Important: A load command for site initialisations is only acceptable for a
few packages. If used, it always loads the whole package and makes Emacs
start-up really slow, so the autoload mechanism is the preferred way."

Thanks for the link.  The mentioned section continues:

"The elisp-common eclass has functions to generate an autoload file if none is
shipped is with the package [...] Keep pollution low but provide sane default
settings out of the box so even a novice can start working fast."

Wouldn't it be a good idea to load idna.el and punycode.el via autoload?

(BTW: "... none is shipped is ..." has one "is" too many.)

(In reply to comment #11)
> Thanks for the link.  The mentioned section continues:
> 
> "The elisp-common eclass has functions to generate an autoload file if none is
> shipped is with the package [...] Keep pollution low but provide sane default
> settings out of the box so even a novice can start working fast."
> 
> Wouldn't it be a good idea to load idna.el and punycode.el via autoload?

 No, because the Elisp files don't ship with autoload snippets and we
won't/can't create them.  Don't strip the important part that says "but the
functionality is available in the source nonetheless". If you want to discuss
this further please contact us by mail at emacs@gentoo.org to not bugspam the
other people on this bug.

> (BTW: "... none is shipped is ..." has one "is" too many.)

 Fixed.

>  No, because the Elisp files don't ship with autoload snippets and we
> won't/can't create them.

Actually it's trivial in this case, since the API consists of four functions
only. I'll take a closer look later today.

(In reply to comment #11)
> Wouldn't it be a good idea to load idna.el and punycode.el via autoload?

In CVS as libidn-1.9.r1.

This is fixed, if I overlook that correctly.

Not fixed for XEmacs.