CEDET

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

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 <deng@...> 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
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>



-- 
*Илья Зонов* (*Ilya Zonov*) aka *puzan*
Нижний Новгород, Россия (Nizhny Novgorod, Russia)

Ilya Zonov <izonov@...> 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

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

Re

On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng@...> 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

Alex Ott writes:
> Re
>
> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng@...> 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

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

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 <deng@...> 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
> Cedet-devel@...
> 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

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 <alexott@...> 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 <deng@...> 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
>> Cedet-devel@...
>> 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

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

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

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

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 <deng@...> 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

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 <deng@...> 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

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

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 <deng@...> 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

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<deng@...>  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

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 <deng@...> 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

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

Thank you David!

On Tue, May 1, 2012 at 2:11 PM, David Engster <deng@...> 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

David Engster writes:
> Alex Ott writes:
>> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng@...> 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

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 <deng@...> wrote:
> David Engster writes:
>> Alex Ott writes:
>>> On Thu, Apr 26, 2012 at 10:11 PM, David Engster <deng@...> 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

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

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