Thread: [cedet-semantic] Intellisense across files
Brought to you by:
zappo
From: Roch G. <ro...@ba...> - 2004-10-01 14:35:31
|
Hello, I've been experimenting with CEDET and love many of its features, but I cannot do one thing... Is it possible to set up the Intellisense-esque completion to work for objects and structures not in the current file. I expect this will impose a significant performance penalty, but with the code I work with it is very rare for the object/structure declaration to be in the same file as the implementation. Sorry if this is covered elsewhere, but I have spent a long time routing through the available options, around the internet and in the Intellisense FAQ page. Any help much appreciated, Roch Gadsdon ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. ________________________________________________________________________ |
From: Bruce S. <bru...@ce...> - 2004-10-01 15:18:29
|
"Roch Gadsdon" <ro...@ba...> writes: > I've been experimenting with CEDET and love many of its features, > but I cannot do one thing... > > Is it possible to set up the Intellisense-esque completion to work > for objects and structures not in the current file. I expect this > will impose a significant performance penalty, but with the code I > work with it is very rare for the object/structure declaration to be > in the same file as the implementation. > > Sorry if this is covered elsewhere, but I have spent a long time > routing through the available options, around the internet and in > the Intellisense FAQ page. I *think* this ought to work now for files whose semantic cache information has been read in. So if you've visited the relevant files, for example. Maybe there's some other setting somewhere; I can't remember what it is, though. It's also possible to load a collection of semantic cache files on emacs startup, and to generate them in a batch job. Anyway, I agree entirely that this is an important missing feature: it's what I miss most, anyway. There's commented code that searches through #include files and things, but it's justifiably commented out, because it's too slow for use. I made some progress months ago at sticking the data into a PostgreSQL database and querying that, but I've done little with that subsequently for a variety of reasons (mostly serious illness, although I'm fine now). You can take the code if you want, it's here <http://www.cenderis.demon.co.uk/archives/bruce-2004/sem/sem--dev/sem--dev--0/patch-10/sem--dev--0--patch-10.tar.gz>. However, it'll require some work before it's useful. I chose PostgreSQL originally, but I think that's probably the wrong choice. I suspect hacking some kind of executable using SQLite would result in something that's more convenient to use: so emacs would run this executable in a buffer and feed data to it, and run queries on it. With pgsql you need to set up the database and stuff, but SQLite just works with a local file. (There are lots of bindings for SQLite available, so the executable can be in some lispy language for easier communication with emacs.) [...] |
From: Eric M. L. <er...@si...> - 2004-10-14 11:04:03
|
>>> "Roch Gadsdon" <ro...@ba...> seems to think that: >Hello, > >I've been experimenting with CEDET and love many of its features, but I >cannot do one thing... > >Is it possible to set up the Intellisense-esque completion to work for >objects and structures not in the current file. I expect this will impose a >significant performance penalty, but with the code I work with it is very >rare for the object/structure declaration to be in the same file as the >implementation. > >Sorry if this is covered elsewhere, but I have spent a long time routing >through the available options, around the internet and in the Intellisense >FAQ page. [ ... ] Hi, The feature you are looking for can work with the current version of semantic with some caveats. Mainly, all the "smart" stuff tries to be, well, smart, and only search headers. This boosts speed over searching through the tags in all files that might be in your project. Unfortunately, it only scans down one level of includes. Thus if you include "super-header.h", and that includes "header-i-use.h", then you will be out of luck. You can use `semanticdb-find-test-translate-path' to see if the right things are on your path. (I forgot to include it in other emails I sent today.) As Bruce pointed out, there is commented out code to re-enable this, but it is tricky. I suspect there is a clever way to solve this, but I just haven't been clever enough lately. Eric ------------------- ;;; Perform interactive tests on the path/search mechanisms. ;; (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))) ;; Output the result (with-output-to-temp-buffer "*Translated Path*" (while p (princ (semanticdb-printable-name (car p))) (princ "\n") (setq p (cdr p))) ) (message "%d paths found." (length p)) )) -- 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 |
From: Bruce S. <bru...@ce...> - 2004-10-14 22:01:45
|
"Eric M. Ludlam" <er...@si...> writes: [...] > The feature you are looking for can work with the current version > of semantic with some caveats. > > Mainly, all the "smart" stuff tries to be, well, smart, and only > search headers. This boosts speed over searching through the tags > in all files that might be in your project. Unfortunately, it only > scans down one level of includes. Thus if you include > "super-header.h", and that includes "header-i-use.h", then you will > be out of luck. > > You can use `semanticdb-find-test-translate-path' to see if the > right things are on your path. (I forgot to include it in other > emails I sent today.) > > As Bruce pointed out, there is commented out code to re-enable > this, but it is tricky. > > I suspect there is a clever way to solve this, but I just haven't > been clever enough lately. I'm not sure about clever. I think the current approach is doomed: if you #include (for C/C++) certain header files, I think you bring in enough symbols that trying to load them all is going to make the system too slow. For example, the semantic cache for /usr/include/openssl (one which I use quite a lot) is 2M, and reading (and parsing, building objects, and especially using) that kind of size of elisp file is going to take an annoying length of time. Admittedly, you could split that up, but presumably the cache was limited to one per directory because that worked out better. And almost always, you don't care about more than a small number of symbols---and typically you want exact matches (you want to know what d2i_X509_CRL is) or you've got an initial substring (you want to list symbols beginning with d2i_X509). To me, that just screams for a database of some sort. Source Navigator uses a collection of db databases (which can also work for initial substring searches, because you can use btree storage). That's workable, and it has the nice feature that you don't have to maintain some kind of SQL database server, but coding with it is pretty horrible: looking at the code, it seems clear that they really wanted to use an SQL database, but just didn't have one handy. On the whole I think it's (using a database that someone else has written) the dumb solution rather than a clever one: it's admitting defeat and letting someone else deal with the problem. If I had lots of free time and were building something like the semanticdb bits of cedet, I suspect I'd start by coding sqlite wrappers for emacs (so you could build emacs with configure --with-sqlite=...), and store the tag tables in a local sqlite database. (And yeah, I'd probably just put code in cedet to barf if there's no sqlite support.) Of course, I'm not actually doing this coding, so my opinion is merely opinion. On a separate issue, what happened to the Java .class semanticdb thing, where cedet could produce completion for jndi symbols (or whatever) just by being pointed at the j2sdk class files? I was trying to find out how to configure this, and then noticed that semanticdb-java.el isn't byte-compiled, so I imagine this doesn't work any more? [...] |