I think all it takes to solve the problem is to replace the following two
lines in absoluteDirname()
if (slashp == NULL)
res = eStrdup (CurrentDirectory);
with
if (slashp == NULL)
res = absoluteFilename ( CurrentDirectory );
Perhaps something slightly more sophisticated needs to be done, similarly to
what appears in the "else" statement, but I don't quite understand what the
role of that is.
Perhaps a cosmetic improvement for the windows build would be to use "..\"
in relativeFilename() when building relative paths, instead of "../" (which
windows emacs does not complain about. It's the just mixture of \ and / in
paths which looks a bit odd)
David.
_____
From: David Chappaz [mailto:david.chappaz@...]
Sent: 19 July 2012 16:40
To: 'Darren Hiebert'
Cc: 'Ctags Users'
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths
Hi Darren,
You're right to be confused because I made a mistake !
Here is what (I believe) is the real problem !
In openTagFile(), the default value of TagFile.name does not contain
PATH_SEPARATOR.
Therefore absoluteDirname() never calls absoluteFilename() and the drive
letter in TagFile.directory is not forced to uppercase.
Furthermore, when invoking ctags from a shell, the drive letter in
TagFile.directory (CurrentDirectory) happens to be uppercase so the bug is
invisible.
But for some reason, when invoking ctags from emacs directly (with M-x
shell-command), then the driver letter in TagFile.directory happens to be
lowercase and the bug shows up.
This eventually causes relativeFilename to fail to identify the common part
in the paths, etc, etc.
David.
_____
From: Darren Hiebert [mailto:Darren@...]
Sent: 19 July 2012 14:59
To: David Chappaz
Cc: 'Ctags Users'
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths
David,
I have to thank you for spelunking into the code like this. However, I am
confused by your analysis. If I understood your example correctly, emacs was
invoking ctags from two different contexts, one from a shell started from
emacs, and another from emacs directly. However, in both cases, ctags would
have been started without any file name argument, leaving it generate its
own list from the -R option. Your analysis does not indicate why ctags would
behave differently under the two cases unless the drive letter was sometimes
generated in one case and sometimes in another.
Are you suggesting that etags is invoking ctags with an argument in one
case?
Also, absoluteDirname() calls absoluteFilename() to do it's dirty work, so
it doesn't appear possible for one to generate a drive letter in different
case than the other.
Darren
On Jul 19, 2012, at 8:04 AM, David Chappaz wrote:
Darren,
After investigating more in details, I believe I have found a bug in ctags.
The root cause of the problem I'm seeing is that the routine
absoluteFilename always makes the drive letter uppercase (Windows paths
only).
On the other hand, the routine absoluteDirname does not do the same.
This in turn causes problems in the routine setSourceFileParameters, more
specifically on the line:
relativeFilename (vStringValue (fileName), TagFile.directory)
In effect, relativeFilename compares the two strings, which sometimes differ
from the start (drive letter with a different case).
The net effect is that relativeFilename identifies no common path between
the two strings, and therefore returns absolute paths.
There are several ways to solve the problem (which may be more widespread
than just the above example). I could just suggest my own quick and dirty
fix, but I believe you are in the best position to make a nice and clean
one.
Hope that helps,
David.
_____
From: Darren Hiebert [mailto:Darren@...]
Sent: 17 July 2012 14:13
To: David Chappaz
Cc: Ctags Users
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths
David,
I apologize for not replying sooner, but my "offline life" has become
troublesome and dominating. I won't take up that here.
To your problem: if you simply run the command "ctags -e -R", only relative
file paths will go into the TAGS file. You can bring up the TAGS file in a
suitable editor to verify this (the format of a TAGS file is many entries
separated by a form-feed character, followed by the file path, followed by
subentries for each tags for that file). I presume that you are using a file
list with ctags because you want tags only for a limited list of files?
However, the output of "find" may be sending absolute file names into ctags,
which ctags will respect. Try running just the "find" command without piping
the output to ctags and see what comes out.
Now, if the TAGS file contains relative files, and you are not getting what
you want out of emacs, the problem is with emacs.
Darren
On Jul 11, 2012, at 4:35 AM, David Chappaz wrote:
|