Re: [CEDET-devel] CEDET changes

"Eric M. Ludlam" <eric@...> writes:
> If you find out what it is, let us know. Thanks!
This sure was "fun" to debug. The cause and effect chain goes like
this:
I have set HOME to 'c:\documents and settings\hannuko' in my
environment. The directory is actually named 'c:\Documents and
Settings\hannuko' but since Windows is case-insensitive (well, to
an extent anyway), it has never caused any trouble (this far).
ede-project-placeholder-cache-file in ede.el is set to to
(expand-file-name "~/.projects.ede") and ~/ is expanded using $HOME
so the result is "c:/documents and settings/hannuko/.projects.ede".
When ede.el is loaded, it calls ede-load-cache, which
find-file-noselects ede-project-placeholder-cache-file. The
buffer-file-name of that ends up being "c:/Documents and
Settings/hannuko/.projects.ede". At the end of ede-load-cache it
tries to get-file-buffer ede-project-placeholder-cache-file so that
it can close the buffer. That fails, because buffer-file-name of
the buffer does not match exactly (as the documentation of
get-file-buffer says) ede-project-placeholder-cache-file.
So the buffer is left open and not only that, it is left as the
current buffer. This means that for the rest of ede.el's execution
buffer local variables are those of
ede-project-placeholder-cache-file buffer. Including
default-directory. At the end of ede.el ede-speedbar-file-setup is
called. It should be autoloaded from ede-speedbar. But since
the only path that pointed to the ede directory was relative and
default-directory is now something else than what it should be,
autoloading fails.
So, I was able to get rid of the problem by fixing my HOME
environment variable. Nevertheless, I think something should be
done about this. Perhaps get-file-buffer and/or expand-file-name
should be changed but then again, I believe buffer-file-name of a
loaded file can be different from what is given to
find-file-noselect for other reasons as well (see
find-file-visit-truename), so I'd also modify ede-load-cache so
that it kills the buffer find-file-noselect returns.
--
Hannu

Thread view

Hi all,
There have been several changes checked into CEDET CVS recently.
Let me attempt to enumerate.
First, a while back, I rewrote parts of the INSTALL file and
documentation. The INSTALL points directly toward a cedet.info file
which can help bootstrap new users. I think I already discussed this,
so this is just a reminder. Check it out, and let me know if it
helps.
Second, I found a bug in the semantic-analyzer today. If you had a
superclass that could not be found, an error would prevent the entire
chain from providing smart completions. With this fixed, you can at
least get some completions instead of no completions. This is likely
the "I can't reproduce the problem with a small example" problem that
was floating on the list earlier this summer.
After a couple questions on the ECB mailing list, I added two new
"smart" commands which may be useful. They are:
semantic-ia-fast-jump - analyze the current context, and jump right to
that tag.
semantic-ia-describe-class - Show all members of some class, including
those inherited. You have to type in the name though.
All the functions in `semantic-ia.el' are supposed to be short
examples on how to use the analyzer tools to do stuff. As such,
functions here often get promoted to more complex tools once the
basics are understood. Please give these a try, and if you feel
brave, hack 'em to do what you want. They are all short functions.
Also in the same completion arena, I fixed a problem in
semanticdb-ebrowse that accidentally disabled some search ability of
semantic even if you weren't using semanticdb-ebrowse.
Next, I have changes to EDE. I know most folks can't use EDE because
you are working on some big project that EDE doesn't understand.
EDE, however, is my interface for specifying where a project root is,
and how to find files in that project.
For purposes of these large C++ type projects where you don't want to
use the various EDE project types, there is now `ede-cpp-root.el'.
This enables a whole new style of EDE project. With one line in your
.emacs, you can now take advantage of how semantic uses EDE to find
your header files. Please read the commentary section of that file
for details. This bit will be important for allowing users to get
smart completion working well for big C++ projects, so any assistance
in trying it out and testing will be much appreciated.
Thanks all
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:
>>>> Hannu Koivisto <azure@...> seems to think that:
...
> Ah, Daniel had some bad regexps that weren't quoted in properly.
> Emacs 22 allows those quoted strings to work. I checked in a fix for
> that.
Thanks, the fix helped.
> It could be that ede-speedbar was somehow whacked during a
> cvs-update. Deleting the file (if it is in cedet/ede) and doing
> another cvs update ought to fix that up.
No, that's not it, the file is ok (and yes, I even verified it with
your suggestion). There is something weird going on:
emacs -batch --no-site-file -l ede-compile-script --eval '(progn (require ''eieio "eieio.el") (require ''ede "ede.el") (message "%s" (require ''ede-speedbar "ede-speedbar.el")))' -f batch-byte-compile project-am.el
ede-speedbar
Wrote c:/documents and settings/hannuko/share/emacs22/site-lisp/cedet/ede/project-am.elc
...
emacs -batch --no-site-file -l ede-compile-script -f batch-byte-compile project-am.el
In toplevel form:
project-am.el:44:4:Error: Cannot open load file: ede-speedbar
I don't get it. This doesn't happen with 21.4 or 22.0.50.1 (old
CVS snapshot) in Linux. Even though I haven't tried with released
22 in Linux, this smells like an Emacs/Windows problem.
> Nil means to include the current working directory, which sort-of
> obsoletes ".". The algorithm that builds that could use some work.
Hm, right, I should have known that.
--
Hannu

"Eric M. Ludlam" <eric@...> writes:
> If you find out what it is, let us know. Thanks!
This sure was "fun" to debug. The cause and effect chain goes like
this:
I have set HOME to 'c:\documents and settings\hannuko' in my
environment. The directory is actually named 'c:\Documents and
Settings\hannuko' but since Windows is case-insensitive (well, to
an extent anyway), it has never caused any trouble (this far).
ede-project-placeholder-cache-file in ede.el is set to to
(expand-file-name "~/.projects.ede") and ~/ is expanded using $HOME
so the result is "c:/documents and settings/hannuko/.projects.ede".
When ede.el is loaded, it calls ede-load-cache, which
find-file-noselects ede-project-placeholder-cache-file. The
buffer-file-name of that ends up being "c:/Documents and
Settings/hannuko/.projects.ede". At the end of ede-load-cache it
tries to get-file-buffer ede-project-placeholder-cache-file so that
it can close the buffer. That fails, because buffer-file-name of
the buffer does not match exactly (as the documentation of
get-file-buffer says) ede-project-placeholder-cache-file.
So the buffer is left open and not only that, it is left as the
current buffer. This means that for the rest of ede.el's execution
buffer local variables are those of
ede-project-placeholder-cache-file buffer. Including
default-directory. At the end of ede.el ede-speedbar-file-setup is
called. It should be autoloaded from ede-speedbar. But since
the only path that pointed to the ede directory was relative and
default-directory is now something else than what it should be,
autoloading fails.
So, I was able to get rid of the problem by fixing my HOME
environment variable. Nevertheless, I think something should be
done about this. Perhaps get-file-buffer and/or expand-file-name
should be changed but then again, I believe buffer-file-name of a
loaded file can be different from what is given to
find-file-noselect for other reasons as well (see
find-file-visit-truename), so I'd also modify ede-load-cache so
that it kills the buffer find-file-noselect returns.
--
Hannu

Thanks for the detailed description! That was very helpful.
I did what you suggest, and store the buffer in a variable during
ede-load-cache. I also wrapped the whole thing in a (save-excursion
...) for good measure. I also found that this wasn't needed during a
byte-compile, so it won't call ede-load-cache in batch mode.
Hopefully, all these precautions will solve this class of problem. I
really appreciate you discovering the reasons for this bug. I clearly
would never have been able to find it since I run Linux and the file
system doesn't work that way.
The anon CVS version of ede.el should be updating shortly.
Thanks
Eric
>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> If you find out what it is, let us know. Thanks!
>
>This sure was "fun" to debug. The cause and effect chain goes like
>this:
>
>I have set HOME to 'c:\documents and settings\hannuko' in my
>environment. The directory is actually named 'c:\Documents and
>Settings\hannuko' but since Windows is case-insensitive (well, to
>an extent anyway), it has never caused any trouble (this far).
>
>ede-project-placeholder-cache-file in ede.el is set to to
>(expand-file-name "~/.projects.ede") and ~/ is expanded using $HOME
>so the result is "c:/documents and settings/hannuko/.projects.ede".
>When ede.el is loaded, it calls ede-load-cache, which
>find-file-noselects ede-project-placeholder-cache-file. The
>buffer-file-name of that ends up being "c:/Documents and
>Settings/hannuko/.projects.ede". At the end of ede-load-cache it
>tries to get-file-buffer ede-project-placeholder-cache-file so that
>it can close the buffer. That fails, because buffer-file-name of
>the buffer does not match exactly (as the documentation of
>get-file-buffer says) ede-project-placeholder-cache-file.
>
>So the buffer is left open and not only that, it is left as the
>current buffer. This means that for the rest of ede.el's execution
>buffer local variables are those of
>ede-project-placeholder-cache-file buffer. Including
>default-directory. At the end of ede.el ede-speedbar-file-setup is
>called. It should be autoloaded from ede-speedbar. But since
>the only path that pointed to the ede directory was relative and
>default-directory is now something else than what it should be,
>autoloading fails.
>
>So, I was able to get rid of the problem by fixing my HOME
>environment variable. Nevertheless, I think something should be
>done about this. Perhaps get-file-buffer and/or expand-file-name
>should be changed but then again, I believe buffer-file-name of a
>loaded file can be different from what is given to
>find-file-noselect for other reasons as well (see
>find-file-visit-truename), so I'd also modify ede-load-cache so
>that it kills the buffer find-file-noselect returns.
>