If you have a tag in an ECB buffer that gives you a semantic tag and
you want to locate that tag in the originating buffer, you have
* Use `semantic-tag-buffer' - for loaded buffers only.
* Use `semantic-tag-file-name'. This Will work on cloned tags
whose originating buffer is now out of memory.
* Use `semanticdb-find-tag-by-name'. You may get a header
file reference here.
* Use `semanticdb-brute-deep-find-tags-by-name'. This searches
everything in a project.
If there is some combination of 'brutish' and 'deep' searches, it
could be added as a custom search which is pretty easy.
The table search mechanism is based on semanticdb-project-roots
variable, plus a similar function. The ECB equivalent is not linked
to semantic (yet.)
I'm not sure why the semanticdb script would take a along time, other
than that the time it takes is relative to the number of tag
>>> "Jans, Hauke" <hauke.jans@...> seems to think that:
>Well, what i am trying to do really is not
>only to lookup headers but to be able to let my
>ecb-tagdefinition.el - addition to find a tag in my complete
>project. Currently it f=EDnds the tag only if the file is loaded.
>Klaus suggested running a shell script for parsing all source
>files, but this has two problems for me:
>- It runs very long (for one directory out of 20 i
>let it run for one hour and it did not complete)
>- i dont have the impression that the semantic.cache from subdir
> A is found when a lookup from a subdir B of my project for
> a tag definition is done.
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 28.01.2005 13:04
>An: Jans, Hauke
>Betreff: Re: AW: [cedet-semantic] EDE Problems
> Since you are only trying to link to include files, I do not
>recommend using EDE. It is heavyweight for that task.
> The -c- path is for finding headers. The semanticdb-project-roots
>variable is for finding database tables. (and a recent bug posted
>indicates this is broken for system files.) The ECB base directory
>thing is for ECB only, and some clever linkage is needed to adopt it's
>values into semantic.
> I will see if the -c- variable can be added to both the semantic and
>>>> "Jans, Hauke" <hauke.jans@...> seems to think that:
>>The project.ede file exists in the toplevel dir and is created in the =
>>dir. After that, the error occurs. I am then only able to open
>>a file in that directory if i delete the sublevel project.ede file.
>>Maybe it has to do with win32-paths?
>>For my problem with include paths:
>>I did set my project root at the toplevel within ecb.
>>But that did not work for me in a way that
>>a #include <b.h> in subdir a=3D20
>>finds the file b.h in subdir b.
>>Do i need to add all my subdirs to the ecb-project roots
>>for this to work?
>>I tried the semantic-default-c-path now and it looks good
>>after i added all my include paths to that var.
>>I did not find that variable, because it is in group "C"
>>and not in "semantic" or "ecb" (where i have looked for that).
>>Von: Eric M. Ludlam [mailto:eric@...]
>>Gesendet: Fr 28.01.2005 05:21
>>An: Jans, Hauke
>>Betreff: Re: [cedet-semantic] EDE Problems
>> There are lots of ways to configure where include files are found.
>>In the case of a C file, there is `semantic-default-c-path'.
>> As for project roots, there is the ECB method (via context menu in
>>the directory tree browser). There is the semanticdb method, via the
>>variable `semanticdb-project-roots'. In EDE, there is the project
>>mechanism you defined.
>> As for this specific EDE problem, I'm not sure. I'd guess it will
>>find the new project after the system is saved and emacs is
>>restarted. I seem to recall some frailness in that system for
>>sub-projects, but thought I'd solved those issues. (All of cedet is
>>built with EDE and sub projects.) Did the Project.ede file exist? I
>>think the error means that the project object exists but there was no
>>file. The problem might be a missing save operation.
>>>>> "Jans, Hauke" <hauke.jans@...> seems to think that:
>>>After trying to find out what happens when one clicks on
>>>the list of includes and wondering why only files from the
>>>current directorie are found (and none from my files which
>>>reside in other directories) i found that i might need
>>>to setup ede-projects.
>>>But after creating a toplevel project in my toplevel dir,
>>>i tried to create a project in the next lower dir.
>>>This gives me the error message / backtrace:
>>>Signaling: (error "No project for =3D3D
>>>\Project.ede, but passes project-p test")
>>> signal(error ("No project for =3D3D
>>>\Project.ede, but passes project-p test"))
>>> cerror("No project for %s, but passes project-p test" =3D3D
>>> apply(cerror "No project for %s, but passes project-p test" =3D3D
>>> error("No project for %s, but passes project-p test" =3D3D
>>> #<compiled-function nil "...(14)" [ede-object project-new-target =
>>>ede-current-project nil ede-buffer-object ede-apply-object-keymap] 2 =
>>>("h:\\.xemacs\\cedet-1.0beta3b\\ede\\ede.elc" . 22059) nil>()
>>> command-execute(ede-new-target t)
>>>This is for XEmacs 21.4.13 and WinXP with cedet-1.0b3.
>>>Or is there any other way to tell ECB the paths to all my source
>> [ ... ]
>> Eric Ludlam: zappo@..., =3D
>> Home: http://www.ludlam.net Siege: http://www.siege-engine.com
>>Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org