GNU bug report logs - #1158
23.0.60; vc mode not working under newest Emacs.app

Previous Next

Full log

Message #43 received at 1158 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Neo Lee" <neo.lee <at> gmail.com>
To: "Glenn Morris" <rgm <at> gnu.org>
Subject: Re: bug#1158: 23.0.60; vc mode not working under newest Emacs.app
Date: Thu, 16 Oct 2008 16:05:21 +0800

[Message part 1 (text/plain, inline)]

On Thu, Oct 16, 2008 at 1:58 PM, Glenn Morris <rgm <at> gnu.org> wrote:

>
> It is surprising that a change in configure options could affect such
> a thing.
>
>
> What happens if you start with `emacs -Q', and open the README file
> from the directory where you checked out the CVS trunk?
>
> If you repeat the experiment, but do M-x toggle-debug-on-error before
> opening README, do you get any backtrace?
>
> What does
>
> M-: (executable-find "cvs")
>
> return?
>
> What does
>
> M-: (vc-cvs-registered "/path/to/emacs/cvs/README")
>
> return?
>
>
> What does
>
> M-x list-load-path-shadows
>
> say?
>

I've got some new discovery about this problem. After installing Emacs.app
in my Application folder, I start Emacs.app from terminal by:

> % /Applications/Emacs.app/Contents/MacOS/Emacs


It runs like a charm, even with my full customization (includes slime, ecb,
ruby & rails mode, as well as lots of other modes). But if I launch it by
click the Emacs icon on the Application folder, vc-mode will be in the weird
situation as I described before, no matter I load my .emacs or not. I guess
this could direct us to some correct way to solve this problem.

To make thing clearer, I removed my .emacs, launched Emacs.app from
Application folder, and did the following tests:

1. C-x C-f ~/Code/Emacs/emacs/README
It opened, with the cvs mode correctly activated. I play the vc-* commands
for a while, seems everything is OK.

2. C-x C-f ~/Ruby19/src/load.c
It opened, with "Loading vc-svn...done" message in the mini buffer, but all
vc-* commands not working (feedback "No fileset is available here."
message).

3. Running diagnosis evaluation as you instructed:

M-: (executable-find "svn") says:

"/usr/bin/svn"


Which is NOT the correct path of my svn. In my working MacBook Pro, the SVN
from Leopard installation is in /usr/bin, but the working SVN installation
is in /opt/local/bin/ (from MacPorts). Here is some information about my
SVNs:

$ whereis svn

/usr/bin/svn

$ which svn

/opt/local/bin/svn

$ /usr/bin/svn --version

svn, version 1.4.4 (r25188) compiled Sep 23 2007, 22:32:34

$ svn --version

svn, version 1.5.3 (r33570) compiled Oct 11 2008, 10:20:01


Furthermore,

M-: (vc-svn-registered "~/Ruby19/src/load.c") says:

nil


M-x list-load-path-shadows says (in mini buffer):

Checking 1 files in /Applications/Emacs.app/Contents/Resources/site-lisp...

Checking 587 files in /Applications/Emacs.app/Contents/Resources/lisp...

Checking 58 files in /Applications/Emacs.app/Contents/Resources/lisp/url...

Checking 90 files in
> /Applications/Emacs.app/Contents/Resources/lisp/textmodes...

Checking 166 files in
> /Applications/Emacs.app/Contents/Resources/lisp/progmodes...

Checking 57 files in /Applications/Emacs.app/Contents/Resources/lisp/play...

Checking 62 files in /Applications/Emacs.app/Contents/Resources/lisp/org...

Checking 29 files in
> /Applications/Emacs.app/Contents/Resources/lisp/obsolete...

Checking 49 files in /Applications/Emacs.app/Contents/Resources/lisp/nxml...

Checking 1 files in
> /Applications/Emacs.app/Contents/Resources/lisp/nxml/char-name...

Checking 108 files in /Applications/Emacs.app/Contents/Resources/lisp/net...

Checking 48 files in /Applications/Emacs.app/Contents/Resources/lisp/mh-e...

Checking 88 files in /Applications/Emacs.app/Contents/Resources/lisp/mail...

Checking 58 files in
> /Applications/Emacs.app/Contents/Resources/lisp/language...

Checking 64 files in
> /Applications/Emacs.app/Contents/Resources/lisp/international...

Checking 264 files in
> /Applications/Emacs.app/Contents/Resources/lisp/gnus...

Checking 58 files in
> /Applications/Emacs.app/Contents/Resources/lisp/eshell...

Checking 70 files in /Applications/Emacs.app/Contents/Resources/lisp/erc...

Checking 52 files in
> /Applications/Emacs.app/Contents/Resources/lisp/emulation...

Checking 128 files in
> /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp...

Checking 57 files in
> /Applications/Emacs.app/Contents/Resources/lisp/calendar...

Checking 87 files in /Applications/Emacs.app/Contents/Resources/lisp/calc...

Checking 1 files in /Applications/Emacs.app/Contents/Resources/leim...


> and finally in *Shadow* buffer:

No Emacs Lisp load-path shadowings were found


I did all these tests on git, and gave similar results, which has no reason
to be repeated here.
NOTE: My git is built from cloned source and installed in /usr/local/bin.

$ whereis git

$ which git

/usr/local/bin/git


And when I start Emacs.app from terminal, it gives correct path.

Actually I do not know what the list-load-path-shadows exactly is, so I just
list all I saw. But from all the information listed above, I guess the whole
problem is something about the search path, and the key is the way Mac OS X
launches GUI application from Finder (my PATH setting in .zshrc bypassed,
which I consider as a common mistake, but I've never noticed).

I now know how to workaround my problem, but if any suggestion or other
helpful information about this issue, please let me know. Thanks a lot for
your response.


-- 
No, I will not fix your computer!

neo.lee <at> gmail.com

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.