Patch to follow...we will apply it anytime soon
Created attachment 126569 [details, diff] Patch for ebuild, no sitefile needed
Created attachment 126570 [details, diff] Patch for ebuild Argh, chose the wrong patch
(In reply to comment #2) > Created an attachment (id=126570) [edit] > 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.
Need a patch for that. :)
idna.el and punycode.el are now part of the net-utils package as provided by upstream which is released as a pre-release package. As such I have made it available in the emacs overlay.
Thanks mgorny for bringing this to my attention. Looking into this I see that I made a version bump on the app-xemacs/net-utils package 2018-08-11 (https://gitweb.gentoo.org/repo/gentoo.git/commit/app-xemacs/net-utils/net-utils-1.61.ebuild?id=12e79bfd2b2b0090deba168b4c20351edee09e43) introducing version 1.61 that contains the files idna.el and punycode.el. I missed to update this bug then.
Tested idna.el and punycode.el with xemacs-21.4.24-r2 that they work according to the test examples in the header in each file. So closing this as resolved.
