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.
>>> 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
>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,
>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.