emacs semantic windows inconsistent

Question

At work we have quite a large code base and I am really, really trying to get Semantic to just work. Yesterday it seemed to have parsed the file I was working on as well as the non-system includes: Great. I could create an instance of a class which is defined in another include file and after construction I could browse through all the functions etc with a key binded to semantic-ia-complete-symbol-meu.

Firstly, I am using:

Emacs 24.3.1 with
CEDET bzr version: rev_8678.tar.gz and, all of this is running on
Windows 7 (unfortunately).
MinGW and MSYS installed
Microsoft Visual Studio 10

In my .emacs (related to CEDET stuff):

;; MODE: CEDET
(load-file "~/.emacs.d/cedet/cedet-devel-load.el") ;; This is the latest dev' version ~~ 26th Sept 2014
;; Add further minor-modes to be enabled by semantic-mode.
;; See doc-string of `semantic-default-submodes' for other things
;; you can use here.
(add-to-list 'semantic-default-submodes 'global-semantic-idle-summary-mode t)
(add-to-list 'semantic-default-submodes 'global-semantic-idle-completions-mode t)
(add-to-list 'semantic-default-submodes 'global-cedet-m3-minor-mode t)
(semantic-mode 1)
(global-ede-mode 1)
;(global-semantic-decoration-mode)

;(setq semanticdb-default-save-directory "~/.emacs.d/.semanticdb/")
;(add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
;(add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))
;(semantic-add-system-include "c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/include" 'c++-mode)
;(semantic-add-system-include "/usr/include/c++/3.4.4")

Therefore, my default semantic database location is ~/.emacs.d/semanticdb

I come in today and find that when I load the same file up I keep on getting three errors (both of which I have searched for but nothing matches my issue):

Parsing main.cpp (LL)...
Idle Parse Error: "#<buffer main.cpp> - End of buffer"

And

Save Error: nil: c:/Users/[MY_USER]/.emacs.d/semanticdb/!drive_[STUFF_HERE]!semantic.cache

And

Idle Service Error semantic-idle-summary-idle-function: "#<buffer main.cpp> - End of buffer"

As I said, this was working yesterday, so why not today? (PS: Btw, this only happens with main.cpp - when I search for definitions of functions using xcscope and open the definition up the file is parsed correctly with CEDET and local includes are parsed and I can symbol-lookup, it seems to just be main.cpp for some reason.)

PS: I have just read a similar problem that someone has with MATLAB. The solution was to either create the directory stated in the matlab-include path, or change the list in the path. But, this does not make sense to my situation because this was working yesterday and I have not touched CEDET since yesterday at all.

semantic-c-dependency-system-include-path is a variable defined in `c.el'.
Its value is ("/usr/include")

semantic-dependency-include-path is a variable defined in `dep.el'.
Its value is nil
Local in buffer main.cpp; global value is the same.

Both of these are the same as yesterday.

PS: Also, when semantic-mode is enabled I am no longer to use (imenu-add-to-menubar) - I only get the option to rescan everything. However, when I do not have semantic-mode enabled then this works fine. I did not know that semantic messed with imenu unless you told it to?

It is all a little annoying because I really like the potential of CEDET/Semantic and appreciate the work that has been put into it. Emacs is already powerful, but with a fully working CEDET its power tends to over 9000!

I believe the developers involved with CEDET should run tests on a Windows machine so that any bugs can be found with Windows issues. I know the OS is horrible but some developers are forced to use it in the workplace. I have never found an issue with CEDET so far on my Linux machines because things are in standard places! But, this is about Windows.

PS: If it is any help a very simple project works fine with this set up and CEDET. I have, in a completely different place:

emacs_test_semantic> ls -l
total 103
-rw-r--r-- 1 [USER] Administrators    43 Oct  2 17:28 Makefile
-rw-r--r-- 1 [USER] Administrators   158 Oct  8 12:04 main.cpp
-rw-r--r-- 1 [USER] Administrators   247 Oct  1 12:51 myClass.cpp
-rw-r--r-- 1 [USER] Administrators   159 Oct  1 12:51 myClass.hpp
-rwxr-xr-x 1 [USER] Administrators 99862 Oct  2 17:28 output.exe

And, in the main:

#include <list>
#include "myClass.hpp"

using namespace std;

int main() {
   MC CLASS( 3, 5 );



   list<MC> myList;
myList.

   return 0;
}

So, I am able to complete symbols of the MC class, however, not the STL list. BUT, this is topic is not about being able to complete STL functions/templates because there are many questions on this.

This small project, even though with (global-semantic-decoration-mode) enabled and a RED over #include <vector> does not give the same three errors described above. Also, imenu works!

===

In summary, I am somewhat confused as to the inconsistency, here. The fact that in the large code base things worked yesterday, but now I have these three errors that I didn't get before!

===

PS: Just after I wrote this I load up that same file and this time global-decoration-mode shows that the local includes are actually now understood! Even though I have changed nothing. So now it seems to work again - but it is this inconsistency which is not understandable.

Well, it works for one branch and not for another. Interestingly, in the branch that gives me the three errors (indicated above) I have a DB file (and imenu does not work, and nor is decoration-mode visable:

-rw-r--r-- 1 [USER] Administrators    449 Oct  8 13:42 !drive_d![SOME_STUFF]!semantic.cache

Compared to the one that works which is (where, global-decoration-mode is visible and imenu works):

-rw-r--r-- 1 [USER] Administrators 555184 Oct  8 13:51 !drive_d![SOME_STUFF]!semantic.cache

You can see the big difference in size. And these two branches only differ in a completely different location in the code base. So, just some extra information.

===

As a user of CEDET/semantic (albeit, not a very good one) I would really like to know a way to manually FORCE the parsing of all files in a given list that is wrote to the DB rather than relying on semantic to do it. This has been requested before and people have created some hack lisp, but with CEDET ever changing from 1.1 the code does not work.

===

PS: Latest edit: Out of no where the errors have gone away, the only thing I can remember doing is saving the buffer. You can tell when the errors have gone away because the global-decaration's start to show - i.e. the underlines and highlighted include files. Is this because I saved the buffer? I am unsure. I cannot recall if I was saving it before. Also, the file save of the DB has increased and the last modification of the DB file was a few minutes ago from this post:

What was before:

-rw-r--r-- 1 [USER] Administrators    449 Oct  8 13:42 !drive_d![SOME_STUFF]!semantic.cache

Is now:

-rw-r--r-- 1 [USER] Administrators 158327 Oct  8 15:38 !drive_d![SOME_STUFF]!semantic.cache

rjd rjd · Accepted Answer · 2014-10-15T16:15:07

Having just messed about at work a lot of the glitches that I originally found are starting to make sense and are appearing to be just my lack of understanding of the product. There is no problem parsing system includes (such as STL) or local includes anymore on Windows and this is mainly down the the brilliant feature of: global-semantic-decoration-mode. It makes it clear if a source file has been parsed or not, etc etc. So now, I use this in my .emacs.

The problem of inconsistency (which I have found is not inconsistency, see below) - I have found - arises when the parser comes across a line of code like this:

#if defined(X)

//hundreds of lines of code

#endif /* define(X) */

I can half understand it. Unless X has been defined then don't bother parsing. But, I still want CEDET/Semantic to work on all of the code. I still might want to use completion if I am working in a function that exists in an area non-existent because of something undefined.

I say, naively, that semantic/cedet should parse code regardless of whether something is defined or not. However, perhaps this was a premeditated feature?

Thanks.

emacs semantic windows inconsistent

1 Answers