"Hey Joe, didn't you see that Alex Ott just submitted a patch for the unbound slot problem an hour ago? Don't you think you should read the mailing list before posting" Well, yes, I would have if I weren't subscribed to digest mode. Oops, sorry! And thanks, Alex!
The rest of the stuff about newtrunk and cedet-build on Windows still applies at least.
Like some others, I've been having the unbound slot error since updating cedet (trunk) on my Windows box at work. I have the same problem with emacs 23 or 24. I just saw the suggestion about debugging the built-in ede/auto.el from a few days ago, I'll try that when I'm at work tomorrow. I've had some suspicion that it's p4.el (perforce integration) interfering somehow, since that's the only major thing with any kind of file hooks I load at work that I don't load at home. But I haven't tried to back that suspicion up yet.
At home, I don't have any problems with it, but I am using newtrunk on Mac OS X and Emacs 24. I would be happy to try newtrunk on Windows, except cedet-build hasn't been updated for the new directory structure and whatever other changes are needed (I tried some simple things to get it to work, but each thing I fix just results in more things that need fixing. Not having had problems building cedet before, I don't know how far down the rabbit hole this process will lead me). Trying to coax cygwin's make into building with the regular Windows emacs was also not very appealing (I DID try it... briefly).
1) I will try to debug ede/auto some more for the unbound slot error on trunk
2) I'm more than happy to test newtrunk on Windows as soon as it's possible to do so
3) Being a volunteer open source project, if it's not going to be possible soon unless I do something about it myself, can anyone give me some pointers as to what cedet-build.el ought to be doing differently on newtrunk as opposed to trunk?
4) The problems using cygwin's make and Windows emacs are (mostly?) path stuff. It occurs to me I could possibly run make -n, take the output, fix just the paths that are getting sent to emacs to be normal windows paths, and run that as a script. Reasonable?
5) I'm aware that cygwin also includes emacs. I don't want to use that, I prefer the "normal" Windows version.
Incidentally, I've been just living with the unbound slot thing this way: It gives me that error once when I try to load a new file outside my project tree, but it DOES load the file, then fails to switch to the buffer. I'll load the file, get the error, then C-x b and switch to the new buffer. Annoying, but workable. And it does work fine for files that do live in the project tree, otherwise it'd be far more annoying.