Hi Eric.
After grabbing your function from the mailing list
and modifiying it a bit (see below) it only prints
the list of the files which i include in the current buffer.
Your %d paths found output seemed incorrect since
you remove the elemts from p and then print the length.
When i uncomment the prin1-to-string p i get a huge dump
from which i cant conclude anything.

semantic-analyze-current-context does not do anything for me (WInXP, XEmacs, cedet-1.0b3)

(defmethod hcj-semanticdb-printable-name ((table semanticdb-table))
  "Return a string which is a short and logical printable name for TABLE.
Use this instead of getting the :file slot of the table, which can
sometimes be unbound."
  ;; I know I said that the above is sometimes unbound.
  ;; Not that if this line throws an error, you should go to
  ;; the subclass, and override this method.
  (oref table file)

(defun semanticdb-find-test-translate-path (&optional arg)
  "Call and output results of `semanticdb-find-translate-path"
  (interactive "P")
  (let* ((p (semanticdb-find-translate-path nil arg))
 (len (length p ))
    ;; Output the result
    (with-output-to-temp-buffer "*Translated Path*"
;      (princ (prin1-to-string p))
      (while p
 (princ (hcj-semanticdb-printable-name (car p)))
 (princ "\n")
 (setq p (cdr p)))
    (message "%d paths found." len)





Von: Eric M. Ludlam [mailto:eric@siege-engine.com]
Gesendet: Fr 28.01.2005 13:09
An: Jans, Hauke
Cc: ville.vainio@tut.fi; thomas.porschberg@osp-dd.de; cedet-semantic@lists.sourceforge.net
Betreff: Re[1]: AW: [cedet-semantic] code completion for C++

>>> "Jans, Hauke" <hauke.jans@sesa.de> seems to think that:
>Hmm... To me it looks promising what i have seen from cedet and
>ecb so far. Very good project, for which i waited some time!!!
>The only thing which might need a principal improvement
>is the speed of the system when searching the tags.

Yes, tag lookup can be time consuming sometimes.

>But cant this be improved with the current implementation, for
>example by:
>--> lookup symbols in the same order as the compiler would do
>      --> current functions locals
>      --> current files locals
>      --> symbols from all included files, in order of inclusion

There are two ways to search for a tag.  This is the way used for the
smart completion, or summary display.  You can use the command (in
CVS only right now):

M-x semanticdb-find-test-translate-path RET

to see how it trims the search path down to your header files.  The
function locals and file locals show up first.  You can see those by

M-x semantic-analyze-current-context.

>--> Speed up lookups in symbol tables
>   --> Hashing
>   --> Indexing

That is certainly a possibility.  The basic analyze/complete steps
are still primitive and I've concentrated on those more than ways to
do indexing.  Several ideas have been floated on using an SQL
database, or other dedicated tag storage system with a fast lookup.

>I dunno how lookup is currently done but maybe there can be
>some improvement?
>An other point which comes to mind is maybe to implement
>the most time consuming stuff in a shared lib / dll and load it into =
>at run time.

That would be fun, but not compatible with Emacs.  Ideally, the core
parser/lexer could be loaded as a shared lib too to make that faster.

Have fun

>Von: cedet-semantic-admin@lists.sourceforge.net im Auftrag von Eric M. =
>Gesendet: Fr 28.01.2005 04:57
>An: Ville Vainio
>Cc: thomas.porschberg@osp-dd.de; cedet-semantic@lists.sourceforge.net
>Betreff: Re[3]: [cedet-semantic] code completion for C++
>>>> Ville Vainio <ville.vainio@tut.fi> seems to think that:
>>>>>>> "Eric" =3D=3D Eric M Ludlam <eric@siege-engine.com> writes:
>>    Eric> The current state of "smart completion" is very early yet.
>>    Eric> It seems to work well for most basic cases.  What it really
>>    Eric> needs is some sort of high-speed back end for searching
>>    Eric> through very large symbol tables in a controlled manner.
>>This would seem like a candidate for a separate project - a "source
>>code server" of some sort. One could imagine that someone might take
>>the C++ code database stuff out of eclipse and provided it as a
>>standalone server which you could instruct to parse source directories
>>and ask for completion of symbols...
>>But it's probably too deeply integrated w/ eclipse to actually be
>>worthwhile as a standalone product. It would still be nice for various
>>projects though, even ones that don't necessarily need to be source
>>code editors.
>I'm open to just about any kind of extension.  I tried to make the
>object system capable of being extended without tweaking semantic
>internals.  If you can do it, go for it!
>          Eric Ludlam:                 zappo@gnu.org, =
>   Home: http://www.ludlam.net            Siege: www.siege-engine.com
>Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>cedet-semantic mailing list