Thanks, I'll adopt some of your printing options.
A semanticdb search runs through these phases:
* Pick a search routine.
* It calls `semanticdb-find-tags-collector' with some args.
* This determines the 'path', or calculates it.
* calculate path with `semanticdb-find-translate-path'.
-- see doc for this function.
* Loop over all tag tables looking for something.
* create/return a 'tag results'
The mechanism in `semanticdb-find-translate-path' for non-brutish
searches is probably the most key aspect of the search. That resides
in `semanticdb-find-translate-path-includes-default'. This is where
`semanticdb-find-table-for-include' is which is probably the problem
area for not finding tags in the right database. There is a big
comment in it proclaiming my frustration.
I know there is a problem here with system includes, and include file
recursion that really needs to be resolved. Doing so would fix a lot
of obscure bugs. The commented out implementation slows things down
quite a bit which is why it is off. Perhaps some sort of option to
turn it on would help.
For `semantic-analyze-current-context', you need to put the cursor on
something interesting, which it will then try to analyze, such as:
c.b-!-;
where -!- is the cursor.
Good Luck.
Eric
>>> "Jans, Hauke" <hauke.jans@...> seems to think that:
>Ok, when i do:
>=20
>(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*"
> (while p
> (princ (semanticdb-full-filename (car p)))
> (princ "\n")
> (princ (hcj-semanticdb-printable-name (car p)))
> (princ "\n")
> (setq p (cdr p)))
> )
> (message "%d paths found." len)
> ))
>
>the output makes more sense to me.
>There i see the path names of the found include files.
>=20
>But that gives the following:
>I have set up semantic-default-c-path
>to include all my dirs, but the function above
>does print the filename only if i have loaded the file.
>=20
>I have set up semanticdb-project-roots and ecb-source-path to my
>toplevel dir.
>=20
>Regards
>=20
>Hauke
>=20
>
>________________________________
>
>Von: Jans, Hauke
>Gesendet: Fr 28.01.2005 15:25
>An: Eric M. Ludlam
>Cc: ville.vainio@...; thomas.porschberg@...; =
>cedet-semantic@...
>Betreff: AW: Re[1]: AW: [cedet-semantic] code completion for C++
>
>
>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.
>=20
>Your %d paths found output seemed incorrect since
>you remove the elemts from p and then print the length.
>=20
>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)
> ))
>
>
>
>Regards
>
>=20
>
>Hauke
>
>=20
>
>
>________________________________
>
>Von: Eric M. Ludlam [mailto:eric@...]
>Gesendet: Fr 28.01.2005 13:09
>An: Jans, Hauke
>Cc: ville.vainio@...; thomas.porschberg@...; =
>cedet-semantic@...
>Betreff: Re[1]: AW: [cedet-semantic] code completion for C++
>
>
>
>>>> "Jans, Hauke" <hauke.jans@...> 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!!!
>>=3D20
>>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
>using:
>
>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.
>
>>=3D20
>>I dunno how lookup is currently done but maybe there can be
>>some improvement?
>>=3D20
>>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 =
>=3D
>>emacs
>>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
>Eric
>
>>=3D20
>>Regards
>>=3D20
>>Hauke
>>
>>________________________________
>>
>>Von: cedet-semantic-admin@... im Auftrag von Eric M. =
>=3D
>>Ludlam
>>Gesendet: Fr 28.01.2005 04:57
>>An: Ville Vainio
>>Cc: thomas.porschberg@...; cedet-semantic@...
>>Betreff: Re[3]: [cedet-semantic] code completion for C++
>>
>>
>>
>>>>> Ville Vainio <ville.vainio@...> seems to think that:
>>>>>>>> "Eric" =3D3D=3D3D Eric M Ludlam <eric@...> 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
>>
>>--
>> Eric Ludlam: zappo@..., =3D
>>eric@...
>> Home: http://www.ludlam.net Siege: http://www.siege-engine.com
>>Emacs: http://cedet.sourceforge.net GNU: http://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
>>cedet-semantic@...
>>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>
>>
>>
>
>
>
>
5H
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|