Created attachment 363604 [details] ecb-2.40.9999.ebuild Noticed that the currect ecb won't build under emacs-vcs due to failing cedet build. Found this page http://alexott.blogspot.se/2012/06/ecb-fresh-emacscedet.html which points to a fixed ecb repo on github: https://github.com/alexott/ecb This fixed ecb can use the included cedet in emacs so I did a an git based ebuild(attached). Maybe the maintainer can add some version of this ecb to the tree?
We could do that if Alex Ott was the new upstream of ECB, but I'm very reluctant to add an ebuild for a snapshot of a fork. However, if you extract the commit(s) that makes ECB work with the newest Emacs, then we could apply it as a patch to ecb-2.40.
Thats quite a few commits .. However I saw this mail thread: http://sourceforge.net/mailarchive/forum.php?thread_name=CALV1_%3DJ%3DCNDyFintso77e4Svxeyn3OHyfROwTAJBBGCgXT-dcA%40mail.gmail.com&forum_name=ecb-list Seems like Ryan Ware is taking over maintainership of ecb so hopefully there will be something official soon.
(In reply to Joakim Tjernlund from comment #2) > Seems like Ryan Ware is taking over maintainership of ecb so hopefully there > will be something official soon. That would be these repos, right? https://github.com/ecb-home/ecb https://github.com/ware/ecb No activity there since more than one year.
(In reply to Ulrich Müller from comment #3) > (In reply to Joakim Tjernlund from comment #2) > > Seems like Ryan Ware is taking over maintainership of ecb so hopefully there > > will be something official soon. > > That would be these repos, right? > https://github.com/ecb-home/ecb > https://github.com/ware/ecb > > No activity there since more than one year. Yes, seems like Ryan Ware never got to it. There is Alex over at https://github.com/alexott/ecb/commits/master seems like he is still maintaining ecb
(In reply to Joakim Tjernlund from comment #4) > There is Alex over at > https://github.com/alexott/ecb/commits/master > seems like he is still maintaining ecb Does the tip of that branch work properly with Emacs 24.4?
Don't know, I never got the hang of ecb :( The below ebuild compiles, that is all I know ATM # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/app-emacs/ecb/ecb-2.40-r2.ebuild,v 1.5 2012/09/29 07:49:04 ulm Exp $ EAPI=5 inherit elisp eutils git-r3 DESCRIPTION="Source code browser for Emacs" HOMEPAGE="http://alexott.blogspot.se/2012/06/ecb-fresh-emacscedet.html" SRC_URI="" LICENSE="GPL-2+" SLOT="0" KEYWORDS="amd64 ppc x86 ~amd64-linux ~x86-linux ~ppc-macos" IUSE="java" DEPEND="java? ( app-emacs/jde )" RDEPEND="${DEPEND}" SITEFILE="70${PN}-gentoo.el" EGIT_REPO_URI="https://github.com/alexott/ecb.git" src_prepare() { epatch "${FILESDIR}/${PN}-2.32-gentoo.patch" sed -i -e "s:@PF@:${PF}:" ecb-help.el || die "sed failed" } src_compile() { local loadpath="" sl=${EPREFIX}${SITELISP} if use java; then loadpath="${sl}/elib ${sl}/jde ${sl}/jde/lisp" fi emake -i LOADPATH="${loadpath}" } src_install() { elisp_src_install insinto "${SITEETC}/${PN}" doins -r ecb-images doinfo info-help/ecb.info* dohtml html-help/*.html dodoc NEWS README RELEASE_NOTES } pkg_postinst() { elisp-site-regen elog "ECB is now autoloaded in site-gentoo.el. Add the line" elog " (require 'ecb)" elog "to your ~/.emacs file to enable all features on Emacs startup." }
This indicates there is some activity still http://sourceforge.net/p/ecb/mailman/message/32678793/
(In reply to Joakim Tjernlund from comment #7) > This indicates there is some activity still > http://sourceforge.net/p/ecb/mailman/message/32678793/ I'd rather see commits than mailing list postings. :/ Anyway, this seems to confirm that maintainership was handed over to Ryan Ware, so let's wait for the announced "near future" actions to happen.
(In reply to Ulrich Müller from comment #8) > (In reply to Joakim Tjernlund from comment #7) > > This indicates there is some activity still > > http://sourceforge.net/p/ecb/mailman/message/32678793/ > > I'd rather see commits than mailing list postings. :/ yes, now its lots of talk but no shop > > Anyway, this seems to confirm that maintainership was handed over to Ryan > Ware, so let's wait for the announced "near future" actions to happen. until then alex tree is the best bet, I am not to hopeful about the new manitainership as it has been a long time with no activity
Created attachment 388956 [details] build.log (In reply to Joakim Tjernlund from comment #9) > until then alex tree is the best bet, [...] The problem is that it doesn't build with Emacs 24.4 (with Emacs 24.3 it is fine). See attached log. (In reply to Joakim Tjernlund from comment #6) > emake -i LOADPATH="${loadpath}" Ignoring errors is not a solution.
(In reply to Ulrich Müller from comment #10) > Created attachment 388956 [details] > build.log > > (In reply to Joakim Tjernlund from comment #9) > > until then alex tree is the best bet, [...] > > The problem is that it doesn't build with Emacs 24.4 (with Emacs 24.3 it is > fine). See attached log. > > > (In reply to Joakim Tjernlund from comment #6) > > emake -i LOADPATH="${loadpath}" > > Ignoring errors is not a solution. Right, now I remember. There is some small syntax change in newer emacs. I never got around to work out exacly what it was, I don't think it mattered much, perhaps you can see what it is?
Might be a bug in Emacs 24.4. http://thread.gmane.org/gmane.emacs.devel/176646
(In reply to Ulrich Müller from comment #12) > Might be a bug in Emacs 24.4. > http://thread.gmane.org/gmane.emacs.devel/176646 This is fixed in app-editors/emacs-24.4-r1. I've committed a snapshot of the Alex Ott repo as app-emacs/ecb-2.41_pre20140215. Thank you for reporting!
(In reply to Ulrich Müller from comment #13) > (In reply to Ulrich Müller from comment #12) > > Might be a bug in Emacs 24.4. > > http://thread.gmane.org/gmane.emacs.devel/176646 > > This is fixed in app-editors/emacs-24.4-r1. > > > I've committed a snapshot of the Alex Ott repo as > app-emacs/ecb-2.41_pre20140215. > Thank you for reporting! Nice! Thank you.
(In reply to Ulrich Müller from comment #13) > (In reply to Ulrich Müller from comment #12) > > Might be a bug in Emacs 24.4. > > http://thread.gmane.org/gmane.emacs.devel/176646 > > This is fixed in app-editors/emacs-24.4-r1. > > > I've committed a snapshot of the Alex Ott repo as > app-emacs/ecb-2.41_pre20140215. > Thank you for reporting! hmm, noticed this with emacs-24.4-r1: In end of data: ecb-symboldef.el:646:1:Warning: the function `eieio-help-mode-augmentation-maybee' is not known to be defined. Seems like this function has been removed from emacs-24.4-r1?
(In reply to Joakim Tjernlund from comment #15) > hmm, noticed this with emacs-24.4-r1: > In end of data: > ecb-symboldef.el:646:1:Warning: the function > `eieio-help-mode-augmentation-maybee' is not known to be defined. > > Seems like this function has been removed from emacs-24.4-r1? Yes, it was still there in 24.3 (in eieio-opt.el) but removed in this commit: revno: 115913.1.2 committer: David Engster <dengste@eml.cc> branch nick: eieiohelp timestamp: Wed 2014-01-08 22:30:12 +0100 message: Rewrite EIEIO help functions and hook them into help system.
(In reply to Ulrich Müller from comment #16) > (In reply to Joakim Tjernlund from comment #15) > > hmm, noticed this with emacs-24.4-r1: > > In end of data: > > ecb-symboldef.el:646:1:Warning: the function > > `eieio-help-mode-augmentation-maybee' is not known to be defined. > > > > Seems like this function has been removed from emacs-24.4-r1? > > Yes, it was still there in 24.3 (in eieio-opt.el) but removed in this commit: > > revno: 115913.1.2 > committer: David Engster <dengste@eml.cc> > branch nick: eieiohelp > timestamp: Wed 2014-01-08 22:30:12 +0100 > message: > Rewrite EIEIO help functions and hook them into help system. So that needs fixing, bugger. I installed your latest ecb in emacs 24.4-r1, started ecb and got a bunch of: (emacs:14539): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion 'G_IS_LOADABLE_ICON (icon)' failed (emacs:14539): Gtk-WARNING **: Error loading theme icon 'gtk-index' for stock: Failed to load icon (emacs:14539): Gtk-CRITICAL **: render_fallback_image: assertion 'pixbuf != NULL' failed (emacs:14539): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (emacs:14539): Gdk-CRITICAL **: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (emacs:14539): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Seems to be related to a bad icon cache but I cannot make out exactly what. Do you get the same error? Installed versions: 24.4-r1(24)(21:55:25 10/11/14)(X acl alsa dbus gif gnutls gpm gtk gtk3 inotify jpeg png svg tiff xpm zlib
(In reply to Joakim Tjernlund from comment #17) > > > In end of data: > > > ecb-symboldef.el:646:1:Warning: the function > > > `eieio-help-mode-augmentation-maybee' is not known to be defined. > So that needs fixing, bugger. Patches are welcome. :) Does that cause any problems at runtime? > I installed your latest ecb in emacs 24.4-r1, started ecb and got a bunch of: > > (emacs:14539): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion > 'G_IS_LOADABLE_ICON (icon)' failed > [...] I don't see these here.
(In reply to Ulrich Müller from comment #18) > (In reply to Joakim Tjernlund from comment #17) > > > > In end of data: > > > > ecb-symboldef.el:646:1:Warning: the function > > > > `eieio-help-mode-augmentation-maybee' is not known to be defined. > > > So that needs fixing, bugger. > > Patches are welcome. :) Does that cause any problems at runtime? Its been 20+ years since I did any serious tinkering with emacs LISP :( I don't know if it is causing any problem, I have yet to get a better understanding of ecb :) > > > I installed your latest ecb in emacs 24.4-r1, started ecb and got a bunch of: > > > > (emacs:14539): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion > > 'G_IS_LOADABLE_ICON (icon)' failed > > [...] > > I don't see these here. Just my luck :) I will look harder at this though
