Re[1]: [cedet-semantic] A few questions about the semantic API

[Eric M. L. <er...@si...>]

Hi,

  Your project ideal sounds pretty cool.

1)

  The best place to optimize for speed in semantic at the moment is in
'semanticdb'.  The larger a project gets, the slower lookups become
because of the many scattered databases.  (1 per directory.)

  Semamticdb uses tables and project databases via EIEIO which allows
full subclassing.  Thus, you can make a new database class (1 per
directory at the moment) and a new database table (1 per file, many
per database.) These implementations can store and search databases
via virtual methods.

  I don't know if that is the target of your tool or not.  At the
moment it is even possible for some new global Db to coincide with the
existing imple, and search throttles can choose between them.

2)

  Moving on, the existing analyzer engine caches results in overlays
in the buffer.  It clears out those overlays as you move around though
to keep memory usage down, but allows for faster behavior while
diddling around in a buffer.

  It is possible to override the impl of the analyzer, but that is
really for mode-specific activities.

  For your question on the hooks... I must profess I don't really
remember.  However, semantic-decorate-mode does use the hooks, and it
may prove useful to see what it does.  If you need more hooks with
better detail, we can certainly add some.

  One thing semantic cannot yet do is identify that a tag has moved.
Thus if function 'foo' is set with some property (read-only, new
color, whatever) and it is moved to another location, it is considered
a 'new' tag, and loses old properties.

3)

There are existing overlays for semantic, 1 per specific tag.  What
they cover is language specific.  In C you cover a variable, function,
whatever.  In a function, each argument is covered.

Scopes are not covered.

The Java parser is the most advanced one in semantic and it parses the
entire buffer.  This is a goal I aspire to for C/C++ as well.  How
exactly to deal with sub-scopes has not been studied.

I've also considered adding overlays to the { ... } part of functions
and marking it 'code.  Overlays there could help optimize incremental edits.

4)

Every language implements local arguments very differently, and there
is no real consistency.

However, you can get the arguments and local vars separately.  The
local args are also sorted in terms of closeness to point.  (I don't
recall which order.)  That might prove useful.

It would be good to discuss 1 a bit more before delving into many
details on other topics so I can better understand what you propose.
The existing analyzer was built to be tweakable in many ways that
should prevent the need for a full-scale replacement.

Eric
  

>>> "Toby 'qubit' Cubitt" <ts...@ca...> seems to think that:
>Hi,
>
>I'm trying to make use of semantic information in the
>intellisense-like completion package I maintain (predictive completion
>mode). It stores possible completions in "dictionary" data structures
>optimised for fast lookup (fast enough to return completions from a
>40,000 word English dictionary quicker than I can type on my old
>Pentium2 450). It also learns word usage frequencies as you type, and
>can prioritise completions using this information.
>
>I know semantic's completion speed has been discussed now and again on
>this list, so I'm hoping using my package on top of semantic might be
>of interest to some people. And prioritising completions by how often
>they've been used might be a nice feature for intellisense-like
>tools.
>
>So much for the propaganda and vapour-ware announcements ;-)
>
>
>I've read the manual and some of the code in semantic-ia.el,
>semantic-ctxt.el and semantic-analyze.el, but there are a few things
>I'm still not sure about, probably because I know next to nothing
>about parser/lexers. Sorry if the questions are vague, trivial, show I
>misunderstood something fundamental about semantic, or are answered in
>the manual (I hope I've done my best to avoid 2 and 4...!)
>
>1) As I understand it, I'll basically need to write an alternative
>version of `semantic-analyze-possible-completions' that looks up
>completions in my dictionary structures instead of directly in the tag
>tables. I'll also need code to automatically generate those
>dictionaries, and keep them synced with the tag tables. (The
>dictionaries then basically serve as a structured cache of the
>completion candidates.) Does this sound reasonable from the
>perspective of someone who understands semantic better than me?
>
>2) Obviously, caching completion candidates is a waste of time,
>however clever the data structure, if you have to regenerate the cache
>every time you look up a completion. I was hoping to use the
>information from `semantic-after-partial/toplevel-cache-change-hook'
>to tell me which tags have been created/removed/modified. But from
>playing with it a bit, I get the impression that the argument passed
>to hook functions only contains new tags, not removed/modified
>ones. Is that right? Is there some way to get at that information? Or
>is it simply not available because of the way the (incremental) parser
>works?
>
>3) You define dictionaries for predictive mode that are local to
>certain buffer regions using overlays. I think I'll at least need to
>set up an overlay for each scope, possibly more. I've written a
>package that can automatically create overlays as you type, defined by
>regexps (again designed to work fast enough not to get in the way of
>typing). But I know semantic sets up overlays all over the place for
>the tags found by the parser. Does semantic already create overlays I
>could use? E.g. are there overlays covering the text between {...} in
>c-mode, or covering the symbol after a "->" dereference? If so, can I
>get semantic to add extra properties to them?
>
>4) It would be useful for me to be able to get a list of
>functions/variables/arguments that are local to the current scope.
>I.e. not all variables available in the current scope, but all
>variables only available in the innermost scope. I think
>`semantic-get-local-variables' and related return the former. Are
>there functions that return the latter? If not, is it safe to use
>`semantic-up-context', as `semantic-get-local-variables-default' does,
>or will this only work with some languages?
>
>
>Ok, I think that'll do for now ;)
>
>Thanks a lot for any help. Hope I'll be able to contribute back some
>useful code eventually.
>
>Toby

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org