Thread: [CEDET-devel] Merge of 'newtrunk' branch
Brought to you by:
zappo
From: David E. <de...@ra...> - 2012-04-22 13:24:09
|
As Eric has already written, CEDET 1.1 will be the last release to use the current build and file name infrastructure. Over the past months, I have worked on a new branch called 'newtrunk', which again is based on Lluís' 'file-rename' branch, featuring a completely new build system and new file names in accordance to the ones in Emacs proper. It also has hundreds of other changes from the Emacs maintainers; for instance, the way the Semantic/EDE modes are set up will be completely different. Note that we will not switch to using 'newtrunk', but merge 'newtrunk' into 'trunk' instead. I have already done this locally, fixing all the conflicts and getting the unit and integrations tests to run. I will fix the remaining compiler warnings next, then do some more testing and push the changeset during next week. This will be a *huge* set of changes. If you're following CEDET-bzr, but need it for work or other important things, you might be better off to switch to the current stable release CEDET 1.1 and wait until the dust settles. If you're using Emacs 22, you will have to stay on CEDET 1.1 anyway, since we're now dropping support for it. I will write more details when I've done the push. Be afraid. Be very afraid. Cheers, David |
From: David E. <de...@ra...> - 2012-04-24 19:22:12
|
David Engster writes: > This will be a *huge* set of changes. If you're following CEDET-bzr, but > need it for work or other important things, you might be better off to > switch to the current stable release CEDET 1.1 and wait until the dust > settles. If you're using Emacs 22, you will have to stay on CEDET 1.1 > anyway, since we're now dropping support for it. I will write more > details when I've done the push. It is done. Please see the INSTALL file for details on how things work now. In a nutshell: - You now have to load cedet-devel-load.el instead of common/cedet.el. I have thought of providing a symlink for compatibility, but let's see how it works out. - The way CEDET is initialized has changed; instead of the canned configurations your supposed to frob semantic-default-submodes and simply activate semantic-mode. However, I have ported the canned configurations to the new setup, so they will still work. - If you have manually required certain packages, you will have to adapt the names to the new scheme, for example semanticdb-find -> semantic/db-find semantic-c -> semantic/bovine/c ede-linux -> ede/linux and so on. A little browsing through the directories should show you how. Most things seem to work, but there are surely problems; please report them here. The tests run fine in Emacs24; on Emacs23 there seems to be a small problem with the integration test, but it's not a major issue. The bad news is that the git mirror is completely borked. It seems the bzr fast-export plugin cannot cope with all the merges I did; I'm currently using the version in Debian stable, maybe using the current devel-version will fix things. Until then, no git mirror; sorry. Anyway, this is a big step towards a cleaner code base and proper syncing with Emacs. I especially want to thank Lluís for all the work he has put into this; he did the initial bzr conversion, created the file-rename branch and, most importantly, explained to me and Eric about 5 times how this should work. If you want to put some stress on Sourceforge's Loggerhead, here's the final merge commit: http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/revision/8235 Cheers, David |
From: Ilya Z. <iz...@gm...> - 2012-04-25 13:57:29
|
Hello David, I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ia.el) is not available at last revision. It seems this function was removed after sync with Emacs. Will this function be returned back? Or maybe you could suggest some other compilation function with the same menu. On Tue, Apr 24, 2012 at 23:21, David Engster <de...@ra...> wrote: > David Engster writes: > > This will be a *huge* set of changes. If you're following CEDET-bzr, but > > need it for work or other important things, you might be better off to > > switch to the current stable release CEDET 1.1 and wait until the dust > > settles. If you're using Emacs 22, you will have to stay on CEDET 1.1 > > anyway, since we're now dropping support for it. I will write more > > details when I've done the push. > > It is done. > > Please see the INSTALL file for details on how things work now. In a > nutshell: > > - You now have to load cedet-devel-load.el instead of common/cedet.el. I > have thought of providing a symlink for compatibility, but let's see > how it works out. > > - The way CEDET is initialized has changed; instead of the canned > configurations your supposed to frob semantic-default-submodes and > simply activate semantic-mode. However, I have ported the canned > configurations to the new setup, so they will still work. > > - If you have manually required certain packages, you will have to adapt > the names to the new scheme, for example > > semanticdb-find -> semantic/db-find > semantic-c -> semantic/bovine/c > ede-linux -> ede/linux > > and so on. A little browsing through the directories should show you > how. > > Most things seem to work, but there are surely problems; please report > them here. The tests run fine in Emacs24; on Emacs23 there seems to be a > small problem with the integration test, but it's not a major issue. > > The bad news is that the git mirror is completely borked. It seems the > bzr fast-export plugin cannot cope with all the merges I did; I'm > currently using the version in Debian stable, maybe using the current > devel-version will fix things. Until then, no git mirror; sorry. > > Anyway, this is a big step towards a cleaner code base and proper > syncing with Emacs. I especially want to thank Lluís for all the work he > has put into this; he did the initial bzr conversion, created the > file-rename branch and, most importantly, explained to me and Eric about > 5 times how this should work. > > If you want to put some stress on Sourceforge's Loggerhead, here's the > final merge commit: > > http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/revision/8235 > > Cheers, > David > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- *Илья Зонов* (*Ilya Zonov*) aka *puzan* Нижний Новгород, Россия (Nizhny Novgorod, Russia) |
From: Kiwon Um <um....@gm...> - 2012-04-25 14:06:17
|
Ilya Zonov <iz...@gm...> writes: > Hello David, > > I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ia.el) is not available at last > revision. It seems this function was removed after sync with Emacs. Will this function be returned back? Or maybe you > could suggest some other compilation function with the same menu. I also missed that function. Anyhow, FYI, I suggest auto-complete; specifically the 'ac-complete-semantic' function. It's exactly the same functionality. Good luck :) -- Kiwon Um |
From: David E. <de...@ra...> - 2012-04-26 20:11:55
|
Ilya Zonov writes: > I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ > ia.el) is not available at last revision. It seems this function was removed > after sync with Emacs. Will this function be returned back? Yes, it was removed in Emacs. I'm not sure, but my guess is that it was removed because it depends on Senator, and we wanted to get rid of that one, hence I don't think we should bring it back. > Or maybe you could suggest some other compilation function with the > same menu. Kiwon already mentioned auto-complete, which is great. Another good choice is company-mode, which is in GNU ELPA (if you're using Emacs24, just do M-x list-packages). You shouldn't use it together with stickyfunc-mode on Emacs24, since it's currently buggy with header-lines. Cheers, David |
From: Alex O. <al...@gm...> - 2012-04-27 06:44:30
|
Re On Thu, Apr 26, 2012 at 10:11 PM, David Engster <de...@ra...> wrote: > Ilya Zonov writes: >> I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ >> ia.el) is not available at last revision. It seems this function was removed >> after sync with Emacs. Will this function be returned back? > > Yes, it was removed in Emacs. I'm not sure, but my guess is that it was > removed because it depends on Senator, and we wanted to get rid of that > one, hence I don't think we should bring it back. It's good idea to remove something, but this function is often used, as I see, and its removal, without providing alternatives out-of-box, is pretty bad idea :-( >> Or maybe you could suggest some other compilation function with the >> same menu. > > Kiwon already mentioned auto-complete, which is great. Another good > choice is company-mode, which is in GNU ELPA (if you're using Emacs24, > just do M-x list-packages). You shouldn't use it together with > stickyfunc-mode on Emacs24, since it's currently buggy with > header-lines. -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-04-27 21:39:35
|
Alex Ott writes: > Re > > On Thu, Apr 26, 2012 at 10:11 PM, David Engster <de...@ra...> wrote: >> Ilya Zonov writes: >>> I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ >>> ia.el) is not available at last revision. It seems this function was removed >>> after sync with Emacs. Will this function be returned back? >> >> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was >> removed because it depends on Senator, and we wanted to get rid of that >> one, hence I don't think we should bring it back. > > It's good idea to remove something, but this function is often used, > as I see, and its removal, without providing alternatives out-of-box, > is pretty bad idea :-( This is CEDET-bzr, anything can happen. ;-) I see that Senator is actually still in Emacs trunk, so I'm at a loss why the above function was removed. Eric, do you know? Otherwise I'll ask Yidong. -David |
From: Eric M. L. <eri...@gm...> - 2012-04-28 22:58:31
|
On 04/27/2012 05:39 PM, David Engster wrote: > Alex Ott writes: >> Re >> >> On Thu, Apr 26, 2012 at 10:11 PM, David Engster<de...@ra...> wrote: >>> Ilya Zonov writes: >>>> I found that function 'semantic-ia-complete-symbol-menu' (/lisp/cedet/semantic/ >>>> ia.el) is not available at last revision. It seems this function was removed >>>> after sync with Emacs. Will this function be returned back? >>> >>> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was >>> removed because it depends on Senator, and we wanted to get rid of that >>> one, hence I don't think we should bring it back. >> >> It's good idea to remove something, but this function is often used, >> as I see, and its removal, without providing alternatives out-of-box, >> is pretty bad idea :-( > > This is CEDET-bzr, anything can happen. ;-) > > I see that Senator is actually still in Emacs trunk, so I'm at a loss > why the above function was removed. Eric, do you know? Otherwise I'll > ask Yidong. I don't recall the specifics, but when it comes down to it, I think that CEDET uses Senator as a place to hang lots of features, whereas integration into Emacs caused a new 'Development' menu to be setup instead, and that is where some tools go, and others get integrated into other Emacs menus, so no need for Semator. I don't know what happened to the completion with a menu function. I like the idea of not supporting completion UIs in core CEDET, and instead just providing a good API to people who like writing those things. Eric |
From: David E. <de...@ra...> - 2012-04-28 08:13:16
|
David Engster writes: > The bad news is that the git mirror is completely borked. It seems the > bzr fast-export plugin cannot cope with all the merges I did; I'm > currently using the version in Debian stable, maybe using the current > devel-version will fix things. Until then, no git mirror; sorry. I went back to using good old 'tailor' for git conversion, so the mirror is running again. However, this resulted of course in a completely new repository, so you won't be able to simply 'pull' from an old clone. -David |
From: Alex O. <al...@gm...> - 2012-04-28 09:23:31
|
Hello David I found, that autoloads for many functions were removed (for example, for functions from cedet-global.el) - this was intended, or I can restore them? On Sat, Apr 28, 2012 at 10:13 AM, David Engster <de...@ra...> wrote: > David Engster writes: >> The bad news is that the git mirror is completely borked. It seems the >> bzr fast-export plugin cannot cope with all the merges I did; I'm >> currently using the version in Debian stable, maybe using the current >> devel-version will fix things. Until then, no git mirror; sorry. > > I went back to using good old 'tailor' for git conversion, so the mirror > is running again. However, this resulted of course in a completely new > repository, so you won't be able to simply 'pull' from an old clone. > > -David > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: Alex O. <al...@gm...> - 2012-04-28 09:41:04
|
I committed small fix into top-level Makefile - on Mac OS X, install-info don't created directory 'doc/info', but instead copied into this file. I added explicit directory creation... On Sat, Apr 28, 2012 at 11:23 AM, Alex Ott <al...@gm...> wrote: > Hello David > > I found, that autoloads for many functions were removed (for example, > for functions from cedet-global.el) - this was intended, or I can > restore them? > > On Sat, Apr 28, 2012 at 10:13 AM, David Engster <de...@ra...> wrote: >> David Engster writes: >>> The bad news is that the git mirror is completely borked. It seems the >>> bzr fast-export plugin cannot cope with all the merges I did; I'm >>> currently using the version in Debian stable, maybe using the current >>> devel-version will fix things. Until then, no git mirror; sorry. >> >> I went back to using good old 'tailor' for git conversion, so the mirror >> is running again. However, this resulted of course in a completely new >> repository, so you won't be able to simply 'pull' from an old clone. >> >> -David >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Cedet-devel mailing list >> Ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-04-28 10:02:03
|
Alex Ott writes: > I committed small fix into top-level Makefile - on Mac OS X, > install-info don't created directory 'doc/info', but instead copied > into this file. I added explicit directory creation... doc/info is part of the bzr repository: http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/files/head%3A/doc/info/ There should be no need to create it. -David |
From: David E. <de...@ra...> - 2012-04-28 10:04:34
|
David Engster writes: > Alex Ott writes: >> I committed small fix into top-level Makefile - on Mac OS X, >> install-info don't created directory 'doc/info', but instead copied >> into this file. I added explicit directory creation... > > doc/info is part of the bzr repository: > > http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/files/head%3A/doc/info/ > > There should be no need to create it. But, as I see now, the git mirror doesn't have it. No idea why. Anyway, your change is fine. :-) -David |
From: Alex O. <al...@gm...> - 2012-04-28 12:31:32
|
Yes, Git doesn't store empty directories in repository - I'm using Git because it's more fast & I can have private repositories with some changes, not yet ready to commit On Sat, Apr 28, 2012 at 12:04 PM, David Engster <de...@ra...> wrote: > David Engster writes: >> Alex Ott writes: >>> I committed small fix into top-level Makefile - on Mac OS X, >>> install-info don't created directory 'doc/info', but instead copied >>> into this file. I added explicit directory creation... >> >> doc/info is part of the bzr repository: >> >> http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/files/head%3A/doc/info/ >> >> There should be no need to create it. > > But, as I see now, the git mirror doesn't have it. No idea why. Anyway, > your change is fine. :-) > > -David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-04-28 10:07:24
|
Alex Ott writes: > I found, that autoloads for many functions were removed (for example, > for functions from cedet-global.el) - this was intended, or I can > restore them? Well, the question is: are they needed? Did you encounter an error without them? The GNU global support is enabled through `semanticdb-enable-gnu-global-databases', which has an autoload and will in turn require cedet-global. Cheers, David |
From: Alex O. <al...@gm...> - 2012-04-28 12:29:47
|
Re Ah, ok - previous version of semanticdb-enable-gnu-global-databases signaled when no GNU Global were in PATH, so I've used `cedet-gnu-global-version-check' to enable support only if we have GNU Global On Sat, Apr 28, 2012 at 12:07 PM, David Engster <de...@ra...> wrote: > Alex Ott writes: >> I found, that autoloads for many functions were removed (for example, >> for functions from cedet-global.el) - this was intended, or I can >> restore them? > > Well, the question is: are they needed? Did you encounter an error > without them? The GNU global support is enabled through > `semanticdb-enable-gnu-global-databases', which has an autoload and will > in turn require cedet-global. > > Cheers, > David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-04-28 14:28:46
|
Alex Ott writes: > Re > > Ah, ok - previous version of semanticdb-enable-gnu-global-databases > signaled when no GNU Global were in PATH, so I've used > `cedet-gnu-global-version-check' to enable support only if we have GNU > Global We can add autoloads if it makes sense, that means if it is a function that is likely to be directly called by the user, be it interactively or in his init file. I guess the above GNU-global check would count as such. It is important to state the reasoning behind adding an autoload in the commit message, so that the Emacs guys know why it is there. Note however that we're not allowed to autoload EIEIO classes or methods anymore. I did take a look at your configuration at github, and I noticed that you manually require a lot of packages. I think you should be able to get rid of most, if not all of them. One should be able to configure CEDET without having to manually require packages, since this can drastically increase Emacs startup time. Also, in the past this has led to a cargo cult, where people just have randomly required packages in their .emacs, which is a terribly frustrating process for them and can even have bad side effects (it shouldn't, but it did nonetheless). -David |
From: Alex O. <al...@gm...> - 2012-04-28 17:58:19
|
Hello David Yes, I want to get rid of most of these require's, I remember, that when I switched to newtrunk some time ago, not all functions were autoloaded - that's why I required them... I'll review my config when I'll update article on CEDET to match new load scheme. Another reason for explicit requiring was that I rarely restart Emacs, so startup time doesn't bother me, but I had sometime issues with autoloads in middle of my work, so I was need to restart Emacs to fix problem, so I prefer to know about problem during the start, than during the work On Sat, Apr 28, 2012 at 4:28 PM, David Engster <de...@ra...> wrote: > Alex Ott writes: >> Re >> >> Ah, ok - previous version of semanticdb-enable-gnu-global-databases >> signaled when no GNU Global were in PATH, so I've used >> `cedet-gnu-global-version-check' to enable support only if we have GNU >> Global > > We can add autoloads if it makes sense, that means if it is a function > that is likely to be directly called by the user, be it interactively or > in his init file. I guess the above GNU-global check would count as > such. It is important to state the reasoning behind adding an autoload > in the commit message, so that the Emacs guys know why it is there. Note > however that we're not allowed to autoload EIEIO classes or methods > anymore. > > I did take a look at your configuration at github, and I noticed that > you manually require a lot of packages. I think you should be able to > get rid of most, if not all of them. One should be able to configure > CEDET without having to manually require packages, since this can > drastically increase Emacs startup time. Also, in the past this has led > to a cargo cult, where people just have randomly required packages in > their .emacs, which is a terribly frustrating process for them and can > even have bad side effects (it shouldn't, but it did nonetheless). > > -David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: Alex O. <al...@gm...> - 2012-05-01 08:47:57
|
Hello David I found one error with autoloads, and not sure how to fix it - can you look onto it? I have code in my cedet config in following form: (when (cedet-ectag-version-check t) (require 'semantic/ectags/db) (semantic-load-enable-primary-ectags-support)) When I start Emacs, I get following error: Debugger entered--Lisp error: (file-error "Cannot open load file" "ectags/util") (cedet-ectag-version-check t) (if (cedet-ectag-version-check t) (progn (require (quote semantic/ectags/db)) (semantic-load-enable-primary-ectags-support))) (when (cedet-ectag-version-check t) (require (quote semantic/ectags/db)) (semantic-load-enable-primary-ectags-support)) eval-buffer(#<buffer *load*<2>> nil "/Users/ott/emacs/rc/emacs-rc-cedet.el" nil t) ; Reading at buffer position 2885 load-with-code-conversion("/Users/ott/emacs/rc/emacs-rc-cedet.el" "/Users/ott/emacs/rc/emacs-rc-cedet.el" nil nil) load("~/emacs/rc/emacs-rc-cedet.el") eval-buffer(#<buffer *load*> nil "/Users/ott/.emacs" nil t) ; Reading at buffer position 784 load-with-code-conversion("/Users/ott/.emacs" "/Users/ott/.emacs" t t) load("~/.emacs" t t) .... It looks like loaddefs aren't correctly generated. I checked semantic/loaddefs.el, and `cedet-ectag-version-check' function exists there, but it marked as (autoload 'cedet-ectag-version-check "ectags/util" ...) instead of correct value (autoload 'cedet-ectag-version-check "semantic/ectags/util" ...) - I changed it manually, and everything is working correctly now, but I don't know how to fix it so it will have semantic prefix before each package... load-path is a variable defined in `C source code'. Its value is ("~/projects/cedet-git/contrib/" "/Users/ott/projects/cedet-git/lisp/speedbar" "/Users/ott/projects/cedet-git/lisp/common" "/Users/ott/projects/cedet-git/lisp/eieio" "/Users/ott/projects/cedet-git/lisp/cedet" "/Users/ott/projects/cedet-git/" "/Applications/Emacs.app/Contents/Resources/site-lisp" "/Applications/Emacs.app/Contents/Resources/lisp" "/Applications/Emacs.app/Contents/Resources/lisp/vc" "/Applications/Emacs.app/Contents/Resources/lisp/url" "/Applications/Emacs.app/Contents/Resources/lisp/textmodes" "/Applications/Emacs.app/Contents/Resources/lisp/progmodes" "/Applications/Emacs.app/Contents/Resources/lisp/play" "/Applications/Emacs.app/Contents/Resources/lisp/org" "/Applications/Emacs.app/Contents/Resources/lisp/nxml" "/Applications/Emacs.app/Contents/Resources/lisp/net" "/Applications/Emacs.app/Contents/Resources/lisp/mh-e" "/Applications/Emacs.app/Contents/Resources/lisp/mail" "/Applications/Emacs.app/Contents/Resources/lisp/language" "/Applications/Emacs.app/Contents/Resources/lisp/international" "/Applications/Emacs.app/Contents/Resources/lisp/gnus" "/Applications/Emacs.app/Contents/Resources/lisp/eshell" "/Applications/Emacs.app/Contents/Resources/lisp/erc" "/Applications/Emacs.app/Contents/Resources/lisp/emulation" "/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp" "/Applications/Emacs.app/Contents/Resources/lisp/calendar" "/Applications/Emacs.app/Contents/Resources/lisp/calc" "/Applications/Emacs.app/Contents/Resources/lisp/obsolete" "/Applications/Emacs.app/Contents/Resources/leim") On Sat, Apr 28, 2012 at 4:28 PM, David Engster <de...@ra...> wrote: > Alex Ott writes: >> Re >> >> Ah, ok - previous version of semanticdb-enable-gnu-global-databases >> signaled when no GNU Global were in PATH, so I've used >> `cedet-gnu-global-version-check' to enable support only if we have GNU >> Global > > We can add autoloads if it makes sense, that means if it is a function > that is likely to be directly called by the user, be it interactively or > in his init file. I guess the above GNU-global check would count as > such. It is important to state the reasoning behind adding an autoload > in the commit message, so that the Emacs guys know why it is there. Note > however that we're not allowed to autoload EIEIO classes or methods > anymore. > > I did take a look at your configuration at github, and I noticed that > you manually require a lot of packages. I think you should be able to > get rid of most, if not all of them. One should be able to configure > CEDET without having to manually require packages, since this can > drastically increase Emacs startup time. Also, in the past this has led > to a cargo cult, where people just have randomly required packages in > their .emacs, which is a terribly frustrating process for them and can > even have bad side effects (it shouldn't, but it did nonetheless). > > -David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-05-01 12:11:15
|
Alex Ott writes: > It looks like loaddefs aren't correctly generated. I checked > semantic/loaddefs.el, and `cedet-ectag-version-check' function exists > there, but it marked as Yes, ones has to override `generated-autoload-load-name' in the local variables section of the file, which I forgot to do. This is now fixed in trunk. > (when (cedet-ectag-version-check t) > (require 'semantic/ectags/db) > (semantic-load-enable-primary-ectags-support)) That require in there shouldn't be necessary. If you see that you need to require packages to call end-user functions, please report this as a bug. Thanks, David |
From: Alex O. <al...@gm...> - 2012-05-01 13:29:52
|
Thank you David! On Tue, May 1, 2012 at 2:11 PM, David Engster <de...@ra...> wrote: > Alex Ott writes: >> It looks like loaddefs aren't correctly generated. I checked >> semantic/loaddefs.el, and `cedet-ectag-version-check' function exists >> there, but it marked as > > Yes, ones has to override `generated-autoload-load-name' in the local > variables section of the file, which I forgot to do. This is now fixed > in trunk. > >> (when (cedet-ectag-version-check t) >> (require 'semantic/ectags/db) >> (semantic-load-enable-primary-ectags-support)) > > That require in there shouldn't be necessary. If you see that you need > to require packages to call end-user functions, please report this as a > bug. > > Thanks, > David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: Alex O. <al...@gm...> - 2012-05-02 19:53:44
|
Thank you David I also installed autocomplete and trying to use it together with Semantic, although maybe I'll need to experiment with semantic-only backend, etc. On Wed, May 2, 2012 at 9:49 PM, David Engster <de...@ra...> wrote: > David Engster writes: >> Alex Ott writes: >>> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <de...@ra...> wrote: >>>> Ilya Zonov writes: >>>>> I found that function 'semantic-ia-complete-symbol-menu' >>>>> (/lisp/cedet/semantic/ >>>>> ia.el) is not available at last revision. It seems this function was removed >>>>> after sync with Emacs. Will this function be returned back? >>>> >>>> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was >>>> removed because it depends on Senator, and we wanted to get rid of that >>>> one, hence I don't think we should bring it back. >>> >>> It's good idea to remove something, but this function is often used, >>> as I see, and its removal, without providing alternatives out-of-box, >>> is pretty bad idea :-( >> >> This is CEDET-bzr, anything can happen. ;-) >> >> I see that Senator is actually still in Emacs trunk, so I'm at a loss >> why the above function was removed. Eric, do you know? Otherwise I'll >> ask Yidong. > > OK, I've brought the function back with a 'do not merge' notice. > > The different completion tools in CEDET are... confusing. We have the > semantic-ia-complete-symbol/menu/tip functions, which (I'm guessing) > predate semantic-complete-analyze-inline, which is configured through > `semantic-complete-inline-analyzer-displayor-class' (phew...). The > semantic-complete package is more powerful but doesn't have that neat > menu-style completion from the semantic-ia package. Instead, it has this > 'ghosting' style and tooltips. I guess the semantic-ia-complete > functions should be deprecated some day and moved to semantic-complete? > > None of those functions is as streamlined as company-mode or > auto-complete. But the Emacs guys really want to use > `completion-at-point' for everything, which for Semantic currently > points to `semantic-ia-complete-symbol'. > > Well, as I've said, it's all pretty confusing... > > -David -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott |
From: David E. <de...@ra...> - 2012-05-02 19:59:05
|
Alex Ott writes: > Thank you David > > I also installed autocomplete and trying to use it together with > Semantic, although maybe I'll need to experiment with semantic-only > backend, etc. Yes, I would recommend to use (setq-default ac-sources '(ac-source-semantic-raw)) to really only get Semantic completions. I would also recommend to choose a longer delay until auto-complete triggers, otherwise it can easily become quite annoying. -David |
From: David E. <de...@ra...> - 2012-05-02 19:49:25
|
David Engster writes: > Alex Ott writes: >> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <de...@ra...> wrote: >>> Ilya Zonov writes: >>>> I found that function 'semantic-ia-complete-symbol-menu' >>>> (/lisp/cedet/semantic/ >>>> ia.el) is not available at last revision. It seems this function was removed >>>> after sync with Emacs. Will this function be returned back? >>> >>> Yes, it was removed in Emacs. I'm not sure, but my guess is that it was >>> removed because it depends on Senator, and we wanted to get rid of that >>> one, hence I don't think we should bring it back. >> >> It's good idea to remove something, but this function is often used, >> as I see, and its removal, without providing alternatives out-of-box, >> is pretty bad idea :-( > > This is CEDET-bzr, anything can happen. ;-) > > I see that Senator is actually still in Emacs trunk, so I'm at a loss > why the above function was removed. Eric, do you know? Otherwise I'll > ask Yidong. OK, I've brought the function back with a 'do not merge' notice. The different completion tools in CEDET are... confusing. We have the semantic-ia-complete-symbol/menu/tip functions, which (I'm guessing) predate semantic-complete-analyze-inline, which is configured through `semantic-complete-inline-analyzer-displayor-class' (phew...). The semantic-complete package is more powerful but doesn't have that neat menu-style completion from the semantic-ia package. Instead, it has this 'ghosting' style and tooltips. I guess the semantic-ia-complete functions should be deprecated some day and moved to semantic-complete? None of those functions is as streamlined as company-mode or auto-complete. But the Emacs guys really want to use `completion-at-point' for everything, which for Semantic currently points to `semantic-ia-complete-symbol'. Well, as I've said, it's all pretty confusing... -David |
From: Eric M. L. <eri...@gm...> - 2012-05-02 22:33:04
|
On 05/02/2012 03:49 PM, David Engster wrote: > David Engster writes: [...] >> I see that Senator is actually still in Emacs trunk, so I'm at a loss >> why the above function was removed. Eric, do you know? Otherwise I'll >> ask Yidong. > > OK, I've brought the function back with a 'do not merge' notice. > > The different completion tools in CEDET are... confusing. We have the > semantic-ia-complete-symbol/menu/tip functions, which (I'm guessing) > predate semantic-complete-analyze-inline, which is configured through All the semantic-ia functions were meant as examples, showing how to write a simple function using the semantic backend to do the heavy lifting. The point being to help folks writing a nice completion ui something to try out. That took a long time though, so enhancements went in making them not so simple. ;) > `semantic-complete-inline-analyzer-displayor-class' (phew...). The > semantic-complete package is more powerful but doesn't have that neat > menu-style completion from the semantic-ia package. Instead, it has this > 'ghosting' style and tooltips. I guess the semantic-ia-complete > functions should be deprecated some day and moved to semantic-complete? The primary complexity in the semantic-complete function is performance, recycling as much data as possible between requests within a particular completion edit session. ie. handling multiple completion requests on a single bit of text as you expand it. Later performance improvements have made the simplified versions to be of similar speed, so it doesn't have much of a win anymore. > None of those functions is as streamlined as company-mode or > auto-complete. But the Emacs guys really want to use > `completion-at-point' for everything, which for Semantic currently > points to `semantic-ia-complete-symbol'. I find the idea of a standard completion interface on multiple backends appealing. That makes the semantic configuration very straight forward. For example, semantic-ia-complete-symbol could locally bind a configuration for, and then call completion-at-point. Eric |