I think all it takes to solve the problem is to replace the following two lines in absoluteDirname()


      if (slashp == NULL)

            res = eStrdup (CurrentDirectory);




      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)





From: David Chappaz [mailto:david.chappaz@free.fr]
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…




From: Darren Hiebert [mailto:Darren@DarrenHiebert.com]
Sent: 19 July 2012 14:59
To: David Chappaz
Cc: 'Ctags Users'
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths




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.




On Jul 19, 2012, at 8:04 AM, David Chappaz wrote:




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,



From: Darren Hiebert [mailto:Darren@DarrenHiebert.com] 
Sent: 17 July 2012 14:13
To: David Chappaz
Cc: Ctags Users
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths




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.




On Jul 11, 2012, at 4:35 AM, David Chappaz wrote: