Hi all,
semanticdb can certainly solve the problem of finding parent
classes. The main parser does not try to resolve parent names during
the parse but instead just saves the name away for later. The goal is
to make the parse as fast as possible and make the user wait if they
want something complicated, like clicking on the parent name in ECB.
(This answers Dan's question on parse-time name resolution.)
While semantic-go-to-tag will solve the direct problem mentioned by
Dan's example, it does not currently use semanticdb. Using
semanticdb would be a reasonable addition to semantic-go-to-tag.
As for the "When will cedet 1.0 stable" be out? I'd love to say
"now!", but I haven't had much time. I've been making the
pre-releases, and trying to solve all the install & setup problems
people have. The feedback has been useful, but I've been having
trouble keeping up lately. I will, however, time the 1.0 release
against when I get my employer release, which would make the 1.0
release fully assigned to the FSF for inclusion with Emacs. As that
paperwork is in the process right now, it will depend on how fast the
legal department is at my company.
For Dan's purposes of solving tag scope and structure issues, you
can use C-c . j (local jump) or C-c . J (jump) as basic ways of
finding out how tag searching works (ie, if you can jump to the tag by
name, it is findable via normal means.) The next tool is
`semantic-analyze-current-context'. This will give you lists of
things semantic can 'find', and let you know if all the analyzer
overrides are working as expected. (ie, pulling in the correct
scopes.)
Next, it's just a matter of using C-M-: with hand written semanticdb
queries. You can use `semanticdb-find-toggle-logging', and
`semanticdb-reset-log' to see what tables it is using, and why it may
fail to find your tag.
In general the parse output looks fine to me, so we should
investigate failures in the searching routines. If ECB is using a
non-deep semanticdb-find call, this would be a main cause for the
tag name not being found. To be clear, ECB should not use a deep
search. A deep search will flatten the tag hierarchy (See
`semantic-flatten-tags-table') and then search that. I guess the
right answer is that ECB would first place the cursor in the context
of the child class (for which he has a valid tag) and then use a
combination of routines like `semantic-ctxt-scoped-types' to learn
that the containing module is in scope, so he can refine the search.
I'm somewhat surprised this hasn't come up in C++ yet with the
namespace issue. The following example has exactly the same problem
as described by the Ruby problem:
------
namespace moose {
=20
class fee {
int fi;
};
class fie : public fee {
int fi;
};
}
------
Klaus, we should probably work out an ideal way for this to work.
You could easily switch to a deep search, but you would miss out on
multiple conflicting namespace names. Using an active scope would be
better, but more complicated.
Eric
>>> <klaus.berndl@...> seems to think that:
>Hi all,
>
>Eric has already told you some aspects and hints concerning semantic.
>
>Now something from the ECB-side ;-)
>
>Well, maybe i found the (or at least one) reason for your problem:
>
>This is what the method-buffer looks like with your small test:
>
>[-] FooClass : class
> `- thingy (()) : method=20
>[-] BarClass : class
> | [-] Parents
> | `- FooClass
> `- foo (arg) : method=20
>
>In this case, if you were to click on 'FooClass' under the Parents
>tab, nothing happens. Right? This was, what you have sent to me...
>
>Explanation:
>
>ECB stores f=C3=BCr each node under the [Parents]-bucket not a semantic-=
tag
>as for tags like functions, methods etc.. (e.g. thingy()) but only the
>name of the parent. This is because parent-classes are often defined out=
side
>of the current source-file so ECB/semantic can not know the semantic-tag
>of a parent-class at parsing time if defined in another file probably
>not loaded into Emacs.
>
>Well, this is not fully correct, because cedet/semantic contains the
>semanticdb which is meant to solve exactly such problems/situations (Eri=
c,
>please scream loudly und correct me if i write nonsens ;-)
>
>Well, this semanticdb is used by ECB to try to get the semantic-tag of
>the definition of a parent-class and to be most flexible ECB uses semant=
icdb
>for finding each parent regardless(!) if defined in the same file or in=20
>other files - semanticdb can find it in both situations!
>
>ECB uses for this the functions `semanticdb-find-tags-by-name' and
>`semanticdb-strip-find-results' - with some sugar around it ;-)
>
>Do you get the point? ;-) If you want that ECB can jump to the definitio=
n
>of a parent-class if you click onto such a parent-node in the methods-bu=
ffer
>you have to switch on semanticdb! See the manual how to do this! AFAIK y=
ou
>can switch on it out-of-the-box for your new language - but this can be =
better
>justified by Eric.
>
>So, please try to switch on semanticdb and tell us if the problem still =
occurs!
>
>Ciao,
>Klaus
>
>P.S.
>Eric, please have a look at this TODO-comment of ECB:
>
>;; TODO: Klaus Berndl <klaus.berndl@...>: When cedet-1.0 is stable an=
d
>;; released (and also included as default XEmacs-package) we should use =
here
>;; the function `semantic-go-to-tag' because a) it has already buildin m=
ost of
>;; tghe intelligency we need here and b) it is overloadable! The we can
>;; probably write `ecb-method-clicked' and `ecb-jump-to-tag' much more
>;; simpler!
>
>;; With the new implementation of semantic-go-to-tag we can for example =
write
>;; a function:
>
>;; (defun ecb-tag-location (tag)
>;; "Return a cons-cell with the buffer and the pos of TAG"
>;; (let ((buf nil)
>;; (pos nil))
>;; (save-excursion
>;; (setq pos (semantic-go-to-tag tag))
>;; (setq buf (current-buffer)))
>;; (cons buf pos)))
>
>When do you think we will have a stable release of cedet1.0? ;-) especia=
lly
>the wonderfull overloadable semantic-go-to-tag function would be a great
>help for simplifying some current ECB-code! But this remark is not menti=
oned
>as pressure onto you - just a question!!!
>
>
>Daniel Debertin wrote:
>> "Eric M. Ludlam" <eric@...> writes:
>>=20
>>> For debugging your language, I recommend using `bovinate' as a
>>> basic way to see exactly the structure your parser generates for a
>>> given buffer. This may reveal clues as to why the 'parent' is not
>>> jumpable.=20
>>=20
>> [...]
>>=20
>> Thanks. That did help, in the sense that I think I have a better
>> handle on what's going on. More below.
>>=20
>>> The ruby module looks to be similar to the C++ namespace.
>>=20
>> For the purposes of semantic, both classes and modules define
>> namespaces.
>>=20
>>> You could also just strip out the module alltogether, putting all
>>> sub-classes into the global space. This would be similar to the C++
>>> extern "C" notation in the c.by parser.
>>=20
>> If it were just modules, I would definitely do that. But clases are
>> involved, too, which would mean that my entire namespace would have to
>> be flat.
>>=20
>> Anyway, in looking at the bovinate output:
>>=20
>> (("FooMod" type
>> (:members
>> (("FooClass" type
>> (:members
>> (("methodcall" code nil
>> (reparse-symbol stmts)
>> #<overlay from 36 to 37 in superclass.rb>))
>> :type "class")
>> (reparse-symbol stmts)
>> #<overlay from 17 to 43 in superclass.rb>)
>> ("BarClass" type
>> (:superclasses "FooClass" :members
>> (("methodcall" code nil
>> (reparse-symbol stmts)
>> #<overlay from 77 to 78 in superclass.rb>))
>> :type "class")
>> (reparse-symbol stmts)
>> #<overlay from 47 to 84 in superclass.rb>))
>> :type "module")
>> nil #<overlay from 1 to 89 in superclass.rb>))
>>=20
>> I have a somewhat-educated guess: BarClass can't refer to FooClass
>> because they're on the same list of members. When BarClass refers to
>> FooClass as its superclass, FooClass doesn't exist yet. Sort of like
>> how (in Lisp) functions defined via FLET can't refer to eachother.
>>=20
>> Does this sound like a possible explanation? If so, does overriding
>> 'semantic-tag-expand-function' sound like a reasonable solution?
>>=20
>> Thanks,
>>=20
>> Dan
>
--=20
Eric Ludlam: zappo@..., eric@...=
om
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|