ctags-users — Discussions regarding use of ctags

Re: [Ctags] ctags unable to recognize non standard C function declaration

[JohnJiming L. <jjl...@gm...>]

The C language parser actually parses the code.  It doesn’t use regex’s.  If you want to fix the issue outside of ctags, I think you would have to preprocess the file to remove the __THROW.

John

> On Mar 3, 2021, at 2:45 PM, Peng Yu <pen...@gm...> wrote:
> 
> Hi,
> 
> https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/socket/sys/socket.h#L215
> 
> ctags is unable to recognize function declaration like the above one
> because there is a throw at the end. How does ctags recognize a
> function declaration? Is there an equivalent regex or something
> similar so that I can fix the bug outside ctags in order to recognize
> the function declaration?
> 
> $ ctags --c-kinds=+p -R -o - | grep '^setsockopt\>' | wc -l
> 0
> 
> -- 
> Regards,
> Peng
> 
> 
> _______________________________________________
> Ctags-users mailing list
> Cta...@li...
> https://lists.sourceforge.net/lists/listinfo/ctags-users

[Ctags] ctags unable to recognize non standard C function declaration

[Peng Yu <pen...@gm...>]

Hi,

https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/socket/sys/socket.h#L215

ctags is unable to recognize function declaration like the above one
because there is a throw at the end. How does ctags recognize a
function declaration? Is there an equivalent regex or something
similar so that I can fix the bug outside ctags in order to recognize
the function declaration?

$ ctags --c-kinds=+p -R -o - | grep '^setsockopt\>' | wc -l
0

-- 
Regards,
Peng

[Ctags] Need help to extract function information from c header

[Sourabh j. <jai...@gm...>]

Hello All,

I am using ctags to extract the information form c header in the format
given below.
Format:
*function_name:return_type:signature*

I have used the following command:
ctags -x --c-kinds=pf  --_xformat="%N:%{typeref}:%{signature}" abc.h

The problem with this command is it does consider struct keyword as a part
of typeref.

For example a function defined in abc.h

*struct foo function_name (int a, int b);*

The above mentioned command gives me:

*function_name:foo:(int a, int b)*


What I want is:

*function_name:struct foo:(int a, int b)*

I am using Universal Ctags 0.0.0(44a0e97).

Is there any way to extract desired information in the mentioned format?

Any suggestion would be much appreciated.

Thanks and Regards,
Sourabh Jain

[Ctags] Definitions of lua functions inside nested modules

[Doron B. <dor...@gm...>]

Hi all, I have a question regarding modulated lua scripts, allow me to
explain:

Let's say I have a lua script called `myscript.lua` and it has a line
like this:

	local foo = require('foo')

Inside `foo/`, I have the file `init.lua` which is loaded by the
interpreter in the line above. In addition, `foo/init.lua` loads by
itself a lot of other files like `foo/bla.lua` and `foo/baz/init.lua`
and `foo/baz/bar.lua`.  Thus, functions inside `foo/baz/init.lua` and
`foo/baz/bar.lua` (e.g `baz.example_function()` and
`bar.other_function()`) are being called in `myscript.lua` like this:

	foo.baz.example_function()
	foo.baz.bar.other_function()

The problem is, that when I run `ctags .` I can see in the generated
`tags` file has entries like:

	baz.example_function	foo/baz/init.lua	/^function baz.example_function()$/;"	f
	bar.other_function	foo/baz/bar.lua	/^function bar.other_function()$/;"	f

While I edit `myscript.lua` and my cursor is positioned on
`foo.baz.example_function()`, I want to jump to the definition of
`baz.example_function()` which is located in the file
`foo/baz/init.lua`, my text editor is telling me it can't find it.

I understand why it can't find the definition -- because the correct
definition in the `tags` file is for `baz.example_function` -- without
the preceding `foo.`. If I manually add the preceding `foo.` to the
definition I can easily jump to `foo/baz/init.lua`.

**My question is this:** How do I tell `ctags` to write this preceding
`foo.` automatically in the `tags` file?

Help will be much appreciated, thanks.

[Ctags] ctags generating corrupt tags file

[Jean J. <jea...@gm...>]

Hi all

Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Oct  7 2014, 13:52:37

After generating a tag file, tag lookup fails:

:tag Tr...
E431: Format error in tags file "tags"
Before byte 51

The file starts like this:

"""

    // strip json vulnerability protection prefix
    data = data.replace(JSON_PROTECTION_PREFIX, .useApplyAsync
src/Orchard.Web/Modules/Orchard.Resources/Assets/Js/Angular/angular.js
   /^var JSON_PROTECTION_PREFIX = \/^\\)\\]\\}',?\\n\/;$/;"    f
    data = data.replace(JSON_PROTECTION_PREFIX, .useApplyAsync
src/Orchard.Web/Modules/Orchard.Resources/Scripts/angular.js    /^var
JSON_PROTECTION_PREFIX = \/^\\)\\]\\}',?\\n\/;$/;"    f
  if (isString(data)) {
!    lib/typescript/tsc.js    /^        "^": 44 \/* CaretToken *\/,$/;"    p
!    src/Orchard.Web/Modules/Amba.ImagePowerTools/Scripts/angular-last.js
   /^    '|':function(self, locals, a,b){return b(self, locals)(self,
locals, a(self, locals));},$/;"    m    class:OPERATORS
!=    lib/typescript/tsc.js    /^        "==": 27 \/*
EqualsEqualsToken *\/,$/;"    p
!=    src/Orchard.Web/Modules/Amba.ImagePowerTools/Scripts/angular-last.js
   /^    '==':function(self, locals, a,b){return a(self,
locals)==b(self, locals);},$/;"    m    class:OPERATORS
!==    lib/typescript/tsc.js    /^        "===": 29 \/*
EqualsEqualsEqualsToken *\/,$/;"    p
!==    src/Orchard.Web/Modules/Amba.ImagePowerTools/Scripts/angular-last.js
   /^    '===':function(self, locals, a, b){return a(self,
locals)===b(self, locals);},$/;"    m    class:OPERATORS
!_TAG_FILE_FORMAT    2    /extended format; --format=1 will not append
;" to lines/
!_TAG_FILE_SORTED    1    /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHOR    Darren Hiebert    /dhi...@us.../
!_TAG_PROGRAM_NAME    Exuberant Ctags    //
!_TAG_PROGRAM_URL    http://ctags.sourceforge.net    /official site/
!_TAG_PROGRAM_VERSION    5.9~svn20110310    //
"    lib/typescript/tsc.js    /^        "\\n": "\\\\n",$/;"    p
class:escapedCharsMap
"""

When I delete everything before `!_TAG_FILE_FORMAT` it works fine.
Is this a bug? Is there a workaround?

-- 
jean                                              . .. .... //\\\oo///\\

Re: [Ctags] Define (--langdef) cmake Type with CMakeLists.txt Literal Name

[Ümit K. <umi...@gm...>]

Hi,

Sorry for bugging but I think I've found my answer: write it like
--langmap=cmake:(CMakeLists.txt). Maybe the problem was I didn't come
across a decent documentation about it. In here
http://ctags.sourceforge.net/ctags.html --langmap section is not clear
enough for this issue. We might need to add an exact sample for how to do.

Best Regards,


On 30 January 2017 at 14:45, Ümit Kablan <umi...@gm...> wrote:

> Hi,
>
> I recently tried to introduce --langdef for cmake type with regex's for
> functions and variables. Although it was easy to introduce filename with
> .cmake extension, I couldn't define CMakeLists.txt in any way described in
> help/man page. Could you advice me how?
>
> BTW, for those with stackoverflow account, please see
> https://stackoverflow.com/questions/41931807/add-cmakeli
> sts-txt-pattern-to-ctags-langmap for reputations ;-)
>
> Best Regards,
>
> --
> Ümit
>



-- 
Ümit

[Ctags] Define (--langdef) cmake Type with CMakeLists.txt Literal Name

[Ümit K. <umi...@gm...>]

Hi,

I recently tried to introduce --langdef for cmake type with regex's for
functions and variables. Although it was easy to introduce filename with
.cmake extension, I couldn't define CMakeLists.txt in any way described in
help/man page. Could you advice me how?

BTW, for those with stackoverflow account, please see
https://stackoverflow.com/questions/41931807/add-cmakelists-txt-pattern-to-
ctags-langmap for reputations ;-)

Best Regards,

-- 
Ümit

[Ctags] ctags -x --python-kinds=-v does not exclude tag entries for variables

[<gt...@at...>]

Hi:

i am using ctags 5.8, and can't get --python-kinds=-v to supress tag entries for variables. 

Sorry if this is a very bad error on my part.
[gthaker@omro ~]$ uname -a
Linux omro 2.6.32-573.18.1.el6.x86_64 #1 SMP Wed Jan 6 11:20:49 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

[gthaker@omro ~]$ which ctags
/usr/bin/ctags

[gthaker@omro ~]$ ctags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Jan  4 2010, 07:52:03
  Addresses: , http://ctags.sourceforge.net
  Optional compiled features: +wildcards, +regex

[gthaker@omro ~]$ cat -n foo.py
     1    
     2    x = 'hello'
     3    
     4    def foo():
     5        return 3
     6    
[gthaker@omro ~]$ ctags -x foo.py
foo              function      4 foo.py           def foo():
x                variable      2 foo.py           x = 'hello'
[gthaker@omro ~]$ ctags -x --python-kinds=-v foo.py
foo              function      4 foo.py           def foo():
x                variable      2 foo.py           x = 'hello'

I expected that w/ --python-kinds=-v  I would only get 1 tag entry, that for the function.

Re: [Ctags] CTAGS bugs?

[<dan...@ma...>]

For some reason my mail software cutted the links. Here the links, again:

[0] http://ctags.sourceforge.net/

[1] http://stackoverflow.com/questions/8961020/no-omnicompletion-for-python-class-members-in-vim

> dan...@ma... hat am 15. April 2016 um 22:23 geschrieben:
> 
> 
>     Hey there,
> 
>     where should CTAGS bugs be reported? On the sourceforge project page [0] Email the author does not work for me and Bug reporting generates 404's for me.
> 
>     I would like to report a bug with Python in CTAGS: instance variables (e.g. self.someVar) are not recognized. Just static/class variables/attributes. This problem is described at [1], to give an example. Every instance variable (self.someVar) is simply ignored by CTAGS. Using the "workaround" described at [1] is possible, but messes up the code, because it requires to blindly add static variables for every instance variable.
> 
>     best wishes,
> 
>     Daniel
> 


 

----------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
Ctags-users mailing list
Cta...@li...
https://lists.sourceforge.net/lists/listinfo/ctags-users

[Ctags] CTAGS bugs?

[<dan...@ma...>]

Hey there,

where should CTAGS bugs be reported? On the sourceforge project page [0] Email the author does not work for me and Bug reporting generates 404's for me.

I would like to report a bug with Python in CTAGS: instance variables (e.g. self.someVar) are not recognized. Just static/class variables/attributes. This problem is described at [1], to give an example. Every instance variable (self.someVar) is simply ignored by CTAGS. Using the "workaround" described at [1] is possible, but messes up the code, because it requires to blindly add static variables for every instance variable.

best wishes,

Daniel

[Ctags] cannot get complete function prototype

[Linda T. <lthadeus@Brocade.com>]

Hi,
I tried ctags -x --c-kinds=p --fields=+S main.h, but it just doesn't print the whole list of arguments extended in multiple lines. But, it works for single line function prototypes. What should I do? Any Suggestions?

Thanks & Regards,
Linda Thadeus

[Ctags] Best way to include multiple directory trees.

[Todd B. <be...@gm...>]

I searched the mailing list archives and Google and did not find anything
at all useful.

This is the solution I came up with.  Is there anything better?

I use a file list file with the -R (recursive) option, so the command:

ctags -R -L tags_files

With these two lines in the file tags_files:
-----
.
/usr/include/linux
----

I get tags for the project in the current directory and for the linux
kernel.

Thanks for any suggestions.

-Todd

-- 
Todd Bezenek <http://www.linkedin.com/in/toddbezenek/>, MScCS, MScEE
be...@gm...
Bitcoin:  17tZKR9dkEbEg1YEXiM16kZL8bXg55FDbk

A people hire A people, B people hire C people.
  --Jim Gray <http://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)>

[Ctags] Ctags with +wildcard on Windows

[Jia S. <j5...@li...>]

Hi,

Did any one know where to get Ctags with compiled feature "+wildcard" on 
windows?

Thanks.

/Steve

[Ctags] apply preprocessor to assembly files

[Jan D. <dol...@fe...>]

Hi,
I'm new to ctags and I'm using it in multi-architecture project
containing assembly files. Assembly file includes header files and is
preprocessed.

In assembly file there are labels surrounded by macros, like this
    SYM (label):
    SYM (label2):

SYM is intended to prepend or append something to labels.

When I run ctags on that file I get bunch of SYM instead of required
preprocessed labels.

Is there an easy way how to make ctags work the way I want? If there is
necessity of code to be written I might try to write the code for that.
Could you please give me any advice or suggestions? How complicated
would it be to add this feature?

Thanks,
Jan Dolezal

[Ctags] Shebang with python3 instead of python

[Martin U. <de...@ma...>]

Hi everyone,

I have a lot of scripts that start with either `#!/usr/bin/python2` or
`#!/usr/bin/python3`. They have no file extension and marked executable.

ctags recognizes `#!/usr/bin/python`, but neither of the above.

How can I make ctags recognize `python2` as Python?


Regards

Martin

Re: [Ctags] Website down?

[Darren H. <Darren@DarrenHiebert.com>]

The ctags web site is back up now.

Darren

On Oct 23, 2012, at 4:25 PM, Elias Pschernig <eli...@gm...> wrote:

> On Tue, 23 Oct 2012 13:44:44 -0700
> vito <vit...@gm...> wrote:
> 
>> Hi Can't get the web page http://ctags.sourceforge.net/
>> :(
> 
> All of SourceForge has been on and off all day:
> http://sourceforge.net/blog/category/sitestatus/
> 
> Looks like they are having a major outage, but they are working on it. 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Ctags-users mailing list
> Cta...@li...
> https://lists.sourceforge.net/lists/listinfo/ctags-users

Re: [Ctags] Website down?

[Elias P. <eli...@gm...>]

On Tue, 23 Oct 2012 13:44:44 -0700
vito <vit...@gm...> wrote:

> Hi Can't get the web page http://ctags.sourceforge.net/
> :(

All of SourceForge has been on and off all day:
http://sourceforge.net/blog/category/sitestatus/

Looks like they are having a major outage, but they are working on it. 

[Ctags] Website down?

[vito <vit...@gm...>]

Hi Can't get the web page http://ctags.sourceforge.net/
:(

Re: [Ctags] Ctags generates absolute instead of relative paths

[David C. <dav...@fr...>]

> Anyway, I seem to remember noticing that ctags would get
> confused by the symlinks in such a tree and generate absolute paths.

If your issue is specific to symlinks, then the below is probably
irrelevant, but I also have been a little confused about the effect of the
option --tag-relative, where I would get absolute paths, even with
--tag-relative=yes. Conversely, I would get relative paths, even with
--tag-relative=no.

In fact it turns out (as the manual says), that absolute paths are used in
the TAGS file, if absolute paths are used in the list of source files
provided to ctags. Therefore in this case --tag-relative=yes has no effect.

Also (but the manual doesn't explicitly say that), paths in the list of
source files appear unchanged in the TAGS file, if --tag-relative=no is
used. Therefore in this case, you can get relative paths (if you supply
relative paths), even with --tag-relative=no.

Perhaps the above behaviour is desirable for a good reason. Nevertheless,
you can always force relative or absolute paths depending on --tag-relative,
by replacing the following two lines in setSourceFileParameters()

	if (! Option.tagRelative || isAbsolutePath (vStringValue
(fileName)))
		File.source.tagPath = eStrdup (vStringValue (fileName));

with

	if (! Option.tagRelative )
		File.source.tagPath = absoluteFilename (vStringValue
(fileName))

Note that this strategy is not infallible.
E.g. on windows, if the TAGS file and the source files are located on
different drives, then you'll get absolute paths even with
--tag-relative=yes, because there is no way to express paths relatively in
this case.

Re: [Ctags] Ctags generates absolute instead of relative paths

[Kaz K. <ka...@ky...>]

I might have run into a similar, possibly related issue when I
worked on an embedded Linux distro.

For compiling many projects, including kernels, I used symbolic link
farms generated by the crusty old "lndir" tool from the XWindow
project.

A link farm is a cloned directory structure which is populated by
individual symlinks to files in the original directory structure.
So you can compile a project in one place while the source is
in another place (and that place can even be read-only).
This works even if the makefiles of that project are oblivious to the
idea of a separate build directory.

Anyway, I seem to remember noticing that ctags would get
confused by the symlinks in such a tree and generate absolute paths.

Re: [Ctags] Ctags generates absolute instead of relative paths

[David C. <dav...@fr...>]

 

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:dav...@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.

 

David.

 

  _____  

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

 

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@DarrenHiebert.com] 
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:





 

 

Re: [Ctags] Ctags generates absolute instead of relative paths

[David C. <dav...@fr...>]

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@DarrenHiebert.com] 
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@DarrenHiebert.com] 
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:






 

 

Re: [Ctags] Ctags generates absolute instead of relative paths

[Darren H. <Darren@DarrenHiebert.com>]

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@DarrenHiebert.com] 
> 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:
> 
> 
>  

Re: [Ctags] Ctags generates absolute instead of relative paths

[David C. <dav...@fr...>]

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@DarrenHiebert.com] 
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:





 

Re: [Ctags] Ctags generates absolute instead of relative paths

[David C. <dav...@fr...>]

 

> I believe emacs is to blame.. But I would like to know is, what could
explain the behaviour ?
> Is ctags sensitive to specific environment variables which can have such
an effect ? Can a different line ending character have such an effect ?
Anything else ?

 

Let me rephrase the question, and be more specific.

 

With the simple command "ctags -e -R", i'm guessing that ctags internally
builds the list of files to be processed.

 

With the -e option, ctags should only use relative paths in the TAGS files.

However, some other criterion somehow takes precedence over the -e option,
which causes ctags to use absolute paths. What can that criterion be ?

Even with "ctags -e -R --tag-relative=yes" I'm seeing the same behaviour
(absolute paths)

 

Perhaps emacs is to blame for wrongly configuring "external" parameters
(e.g. environment variables), but all I'm asking is, what are the parameters
that ctags internally looks at, to make a decision about relative / absolute
paths ?