universal-ctags/ctags

A maintained ctags implementation

Universal Ctags

Universal Ctags (abbreviated as u-ctags) is a maintained implementation of ctags. ctags generates an index (or tag) file of language objects found in source files for programming languages. This index makes it easy for text editors and other tools to locate the indexed items.

Exuberant Ctags (e-ctags) maintained by Darren Hiebert, the ancestor of Universal Ctags, improved traditional ctags with multi-language support, the ability for the user to define new languages searched by regular expressions (called optlib in Universal Ctags), and the ability to generate emacs-style TAGS files. But the activity of the project unfortunately stalled.

Universal Ctags has the objective of continuing the development of Exuberant Ctags. Reza Jelveh [email protected] initially created a personal fork of Exuberant Ctags on GitHub. As interest and participation grew, it was decided to move development to a dedicated project as Universal Ctags. The goal of this project is to maintain a common/unified working space where people interested in making ctags better can work together.

Some of the major features of Universal Ctags are:

• more numbers of improved language support
  • new extended C/C++ language parser, etc.
• fully extended optlib (a feature to define a new language parser from a command line)
• interactive mode (experimental)

The latest build and package

If you want to try the latest Universal Ctags without building it yourself...

Windows

Daily builds are available at the ctags-win32 project. Go to the releases page to download zip packages.

Unix-like

Nightly builds are available at the ctags-nightly-build project. Go to the releases page to download tarball archives.

Mac

Recent builds are available via the universal-ctags Homebrew formula.

Snap

Go to ctags-snap and clone the ctags-snap repo. Then, follow instructions to build the snap package of Universal Ctags. Snapcraft will automatically fetch the source code from GitHub.

How to build and install

To build with Autotools (Autoconf and Automake) on GNU/Linux, OSX, or Windows 10 WSL,

    $ git clone https://github.com/universal-ctags/ctags.git
    $ cd ctags
    $ ./autogen.sh
    $ ./configure  # use --prefix=/where/you/want to override installation directory, defaults to /usr/local
    $ make
    $ make install # may require extra privileges depending on where to install

GNU make is assumed as the make command.

See docs/autotools.rst for more information.

To build on Windows, see docs/windows.rst for more information.

To build on OSX, see docs/osx.rst for more information.

Manual

The primary documents of Universal Ctags are man pages. Users should first consult the ctags(1), and other man pages if necessary.

Universal Ctags Hacking Guide, which also includes the man pages, is primarily for developers and provides additional information to the man pages, including experimental features.

See also */README.md on this repository.

Differences from exuberant-ctags

You may be interested in how Universal Ctags is different from Exuberant Ctags. See ctags-incompatibilities(7) and Introduced changes for details.

The most significant incompatible changes:

• Universal Ctags doesn't load ~/.ctags and ./.ctags at starting up time. Instead, it loads ~/.ctags.d/*.ctags and ./.ctags.d/*.ctags.

• Universal Ctags is more strict about characters that can be used in kind letters and kind names than Exuberant-ctags.

  • The letter must be an alphabetical character ([a-zA-EG-Z]). F is reserved for file kind.

  • The first character of the name must be alphabetic, and the rest characters must be alphanumeric ([a-zA-Z][a-zA-Z0-9]*).

  The detailed background is explained in #1737.

  If you want to reuse your .ctags written for Exuberant-ctags, you must review kind letters and names defined with --regex-<LANG>=... options. When updating the definitions, using --kinddef-<LANG>=... option is appreciated.

CVE-2022-4515

It is not affected to Universal Ctags. It was fixed in e00c55d7a0204dc1d0ae316141323959e1e16162 in 2016. Thanks to the reporter.

Pull-requests are welcome!

ctags's Issues

add an option to enable valgrind to testing.mak

Add dual-pass capability

Looking at some omni-completion functions in vim I understood that in order to identify the class of a certain object those functions need to parse the file until the object declaration is found. Since ctags already does this type of work, why not implement this parsing in it?

This is how I see it:

1. Parse all files as usual.
2. From the list of tags identify the class-like [1] tags and populate keyword hash table with it.
3. Re-start parsing of all files.
4. The parser skips initialization phase and starts parsing the files directly.
5. Each new entry would need a special string identifying its class (similarly to signature).

There are more details that need to be looked into, but by using something similar to this we should end up with a complete tag list of the files including object declarations.
This should be specially useful when we have a libctags!

[1] Verilog, for example, has multiple tag types that can be used similarly to object declarations.

Advertise fishman/ctags

make ctags a library

"Library" in ctags may have 3 aspects:

1. reading tags file,
2. backend language parser, and
3. running ctags.

The scope is this issue is "3. running ctags."
We have to research Geany.

Decreasing global variables will be the initial step.

Better project name?

I think it would make sense to try to come up with a better name for this project. Naming it after a specific person makes it sound like a hobby pet project, not something that strives to improve on and ultimately replace a widely-adopted tool. It would also make things a bit awkward if the original maintainer decides to leave the project for some reason. Give the additional features being implemented, especially the external commands, how about something like "universal ctags"?

Build currently failing on os x lion: 'environ' undeclared

The build is currently failing (on os x lion):

./configure
make install
...
gcc -I. -I. -DHAVE_CONFIG_H  -DDATADIR=\"/tmp/share/ctags\" -DPKGCONFDIR=\"/tmp/etc/ctags\" -DPKGLIBEXECDIR=\"/tmp/libexec/ctags\" -g -O2 -Wall -c main.c
main.c: In function ‘sanitizeEnviron’:
main.c:536: error: ‘environ’ undeclared (first use in this function)
main.c:536: error: (Each undeclared identifier is reported only once
main.c:536: error: for each function it appears in.)
make: *** [main.o] Error 1

rewrite Units

help target is needed.

Utilize travis-ci

I read a lot of posts on the internet where people complain that people should not make everything Github specific, but since this project is, at least for now, hosted on Github, I would like to see a README file that Github can parse and post at the bottom of the main page.

If such a file were to exist I would love see some buttons added. For example, I'd love to see this project on Travis, and even waffle. The steam has really picked up here and I'd like to keep track of the progress and even contribute.

Please add ada language support from rumca-js/ctags

Please add ada language support from rumca-js/ctags github repository

Use XDG dirs spec for data/config

It would be great if the configuration and other data used by fishman-ctags used the XDG base dir spec instead of putting everything into the home directory. This would keep it in line with other more modern software and would prevent polluting the home directory.

Error command nmake

When I make with command nmake -f mk_mvc.mak in Windows 7 (x86)
I get this error:

strlist.obj : error LNK2019: unresolved external symbol _fnmatch referenced in function _fileNameMatched
ctags.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\bin\cl.EXE"' : return code '0x2'
Stop.

thanks.

path and directiries for optlib and xcmd

@majutsushi, forgive me if I'm impolite.
Are you have interested in improving ctags?
We, fishman-ctags developers, are interested in your wiki page:

https://github.com/majutsushi/tagbar/wiki

fishman-ctags has ability to use the contents of .ctags and command line as a first class library with a mechanism called optlib. In my opinion it is better for users that your wiki contents are part of ctags and
made runnable.

Technically I, who designed and implmented optlib mechanisum, can import code from your wiki page.
However, it is ... not so ... good.

First of all I want feedback for what I implemented from other person than myself.
In addition I'm not sure the copyright and license term about the contents of wiki.

So I wonder whether you have interests writing an optlib file.
If your answer was yes, could you look at
https://github.com/fishman/ctags/blob/master/docs/f-news.rst
https://github.com/fishman/ctags/blob/master/docs/f-optlib.rst
and
https://github.com/fishman/ctags/blob/master/docs/f-units.rst
?

Questions are welcome.
Thank you very much for reading this.

Matlab disabled

Just to open this for discussion: why is matlab parser being disabled to overcome the mapping conflict with objective c?
Why not use --langmap or --language-force?

coffeetags not found?

Hi,

I don't use coffeescript and so I don't have to have coffeetags installed.

I get this error when I run "ctags --help"

$MY_USR_LOCAL//libexec/ctags/drivers/coffeetags: line 31: coffeetags: command not found

How can I make ctags not look for coffeetags?

Thanks.

badinput: Infinite loop and crashes in Ada parser

% make -f testing.mak FUZZ_LANGUAGE=Ada fuzz
Fuzz-testing: Ada
Fuzz testing failure: lang: Ada input: Test/1880687.js
Fuzz testing failure: lang: Ada input: Test/bug2888482.js
Fuzz testing failure: lang: Ada input: Test/bug814263.java
Fuzz testing failure: lang: Ada input: Test/ingres_procedures.sql
Fuzz testing failure: lang: Ada input: Test/keyword_abstract.cs
Fuzz testing failure: lang: Ada input: Test/keyword_protected.cs
Fuzz testing failure: lang: Ada input: Test/keyword_virtual.cs
Fuzz testing failure: lang: Ada input: Test/no_terminator.js
/bin/sh: line 4: 16112 Segmentation fault timeout -s INT 10 ./ctags --language-force="${lang}" -o - "${input}" > /dev/null 2>&1
Fuzz testing failure: lang: Ada input: Test/ocaml_empty.ml

rspec describe blocks whose titles include `:` are not discovered

The matcher for describe blocks is imprecise.

Including a : in this list causes other errors (incorrect nesting). I tested this by rebuilding with such a change. Probably a regex matcher is needed somewhere.

Pardon I didn't research further.

Observation "make -f testing.mak" under Windows

I just did some testing and more or less managed to get the testing suite to work. Here is how I tested:

Build ctags with the gcc that came with CodeBlocks. This results in a ctags.exe I copied this file to ctags.ref.exe Then I started my cygwin bash.

There I started make -f testing.mak. It ran but there was one big problem. The mingw/Windows build ctags.ref.exe generates tags files with CRLF line ending, but the provided expected.ctags files have LFs. Therefore all the tests failed.

After adding this line at line 136 of testing.mak most tests passed.
dos2unix -q "$$expectedtmp" "$$output" ; \

These next tests fail or skipped, but I haven't had time to investigate this any further yet.

Testing Units/conflib-recursive...FAILED: differences left in Units/conflib-recursive.d/DIFF.TMP
Testing Units/nolang-modeline-emacs-after-shbang...FAILED: differences left in Units/nolang-modeline-emacs-after-shbang.d/DIFF.TMP
Testing Units/nolang-shebang-python3...FAILED: differences left in Units/nolang-shebang-python3.d/DIFF.TMP
Testing Units/option-add-alias...FAILED: differences left in Units/option-add-alias.d/DIFF.TMP
Testing Units/php-whitespaces...FAILED: differences left in Units/php-whitespaces.d/DIFF.TMP

These tests are skipped, but I don't think that is much of a problem.

No Eiffel library source found for testing
No Linux kernel source found for testing

Another small problem is that the clean-test target doesn't delete the ctags.ref.exe

use pygments as a parser

Like yoshizow/global-pygments-plugin, can we use pygments as a parser?

Units test that require "regex" are skipped

Test that require "regex" are skipped under Windows

Testing Units/conflib-simple  skipped (required feature regex is not available)

But ./ctags --list-features mentions regex

$ ./ctags --list-features
win32
wildcards
regex
internal-sort

I assume this happened after commit 688ba25

"Badly formed language map" error with `--langmap=c:.c.x` (regression to exuberant)

Running ./ctags --langmap=c:.c.x (as given in the man page) results in:

ctags: Badly formed language map for C language

This works with the original ctags, but fails with this version.

./ctags --version
Exuberant Ctags Development, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Sep 17 2014, 22:37:04
  Addresses: <[email protected]>, http://ctags.sourceforge.net
  Optional compiled features: +wildcards, +regex, +option-directory

FWIW, I've a similar setting in ~/.ctags for this, and noticed that this version of ctags does not like it.
It even aborts when invoked with just --version.

Segmentation fault with vim file in parseCommand (when no command name is given)

ctags segfaults with the following vim file, where it seems to expect a command name:

cat > test-ctags.vim <<EOF
com! -complete=custom
EOF

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
parseCommand (line=0x0) at vim.c:345
345     if ( (int) *cp == '\\' )
(gdb) bt
#0  parseCommand (line=0x0) at vim.c:345
#1  0x000000000042e10f in parseCommand (line=<optimized out>, line@entry=0x6a4dd0 "") at vim.c:431
#2  0x000000000042edf8 in parseVimLine (line=0x6a4dd0 "") at vim.c:598
#3  parseVimFile (line=0x6a4dd0 "") at vim.c:631
#4  findVimTags () at vim.c:731
#5  0x0000000000421ed8 in createTagsForFile (passCount=<optimized out>, language=44, fileName=0x7fffffffc4b0 "test-ctags.vim") at parse.c:1416
#6  createTagsWithFallback (language=44, fileName=0x7fffffffc4b0 "test-ctags.vim") at parse.c:1439
#7  parseFile (fileName=fileName@entry=0x7fffffffc4b0 "test-ctags.vim") at parse.c:1476
#8  0x0000000000418b45 in createTagsForEntry (entryName=0x7fffffffc4b0 "test-ctags.vim") at main.c:303
#9  0x0000000000403080 in createTagsForArgs (args=0x66d120) at main.c:348
#10 makeTags (args=0x66d120) at main.c:494
#11 main (argc=<optimized out>, argv=<optimized out>) at main.c:563

I've noticed this, because Exuberant ctags crashed when handling the checkout of https://github.com/c9s/vimomni.vim/blob/master/test.vim, and then hoped it would be fixed here already.

Units tests fail, files missing

At this moment 2 Units test fail. Files are missing:

Testing Units/ada-function cp: cannot stat 'Units/ada-function.d/expected.tags': No such file or directory
diff: Units/ada-function.d/EXPECTED.TMP: No such file or directory
FAILED
differences left in Units/ada-function.d/DIFF.TMP
cmdline: ./ctags --options=NONE --libexec-dir=libexec --libexec-dir=+Units/ada-function.d --data-dir=data --data-dir=+Units/ada-function.d -o - --options=Units/ada-function.d/args.ctags Units/ada-function.d/input.broken
Testing Units/ada-protected cp: cannot stat 'Units/ada-protected.d/expected.tags': No such file or directory
diff: Units/ada-protected.d/EXPECTED.TMP: No such file or directory
FAILED
differences left in Units/ada-protected.d/DIFF.TMP
cmdline: ./ctags --options=NONE --libexec-dir=libexec --libexec-dir=+Units/ada-protected.d --data-dir=data --data-dir=+Units/ada-protected.d -o - Units/ada-protected.d/input.adb

--ruby-kinds option not honored in ruby.c

ctags: Unknown option: -p

Trying to compile and install it on OS X Lion 10.7.1

$ ./ctags
ctags: Unknown option: -p

Making --regex-<LANG> library

Now we can put --regex- options to separate files under /etc/ctags.conf.d directory. So we can put these options as library into our .tar.gz release.

TODO:

• Introduce /usr/lib/ctags.conf.d or something which takes precedence over /etc/ctags.conf.d.
  Our library should go /usr/lib/ctags.conf.d. /etc/ctags.conf.d can be used when an administrator wants overriding our library. systemd is used this scheme.
• update make install
  we must consider multiple platforms.
• Gather good regexp defs
  e.g. https://github.com/fishman/dot_files/blob/master/ctags/.ctags

MinGW compilation works, but no files parsed

I compiled ctags with the gcc that comes with CodeBlocks 13:11. It creates an executable, but it doesn't recognize any source files to parse. I've created a CodeBlock's project as well as a built with the mk_mingw.mak, result for both are the same.

Debugging into the code I found the problem, but am unsure about a possible solution.

fileNameMatched() in strlist.c doesn't work for win32 builds anymore. The problem is that win32 doesn't have fnmatch(). Therefore strcasecmp() is used and the filename (pascal.c) doesn't match the pattern (*.c) that is used.

I have build the original SVN and everything works as expected. I have no clue what has changed in the code.

I have a working fnmatch.[ch] lying here that could solve the problem. I have that to solve another problem with pattern matching in the original ctags. I have to try it out for this repo.

vim-command-loop.patch from Debian

I've looked at Debian's patches to exuberant-ctags, and the following might be interesting for you:

From http://anonscm.debian.org/cgit/users/cjwatson/exuberant-ctags.git/tree/debian/patches/vim-command-loop.patch

From 15b3c591abd3b0e4334f9fba19a9b75330b33c26 Mon Sep 17 00:00:00 2001
From: Colin Watson <[email protected]>
Date: Sat, 15 Feb 2014 22:47:02 +0000
Subject: Fix infinite loop parsing vim commands

This happens if a non-alphanumeric character other than whitespace or '-' is
found before the first alphanumeric character after 'command'.

Bug: http://sourceforge.net/tracker/index.php?func=detail&aid=3214129&group_id=6556&atid=106556
Bug-Ubuntu: https://bugs.launchpad.net/bugs/736367
Forwarded: no
Last-Update: 2011-03-17

Patch-Name: vim-command-loop.patch

---
 vim.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/vim.c b/vim.c
index 4e6fba8..d17a1ba 100644
--- a/vim.c
+++ b/vim.c
@@ -405,7 +405,9 @@ static boolean parseCommand (const unsigned char *line)
      while (*cp && !isspace ((int) *cp))
        ++cp;
    }
-   } while ( *cp &&  !isalnum ((int) *cp) );
+       else
+           break;
+   } while ( *cp );

  if ( ! *cp )
  {

More patches are available at http://anonscm.debian.org/cgit/users/cjwatson/exuberant-ctags.git/tree/debian/patches/, but only http://anonscm.debian.org/cgit/users/cjwatson/exuberant-ctags.git/tree/debian/patches/python-disable-imports.patch seems to be missing, and I'm not sure if it's a good one.

Use "master" branch instead of "deploy"?!

Is there a reason why you're using "deploy" instead of "master"?

I found myself several times trying to "git checkout master".

Before announcing the project, it would make sense to cleanup the available branches (if necessary), and document how they're being used.

Rearrange build process and directory organization

As I wrote #63 I'm thinking rearrange the directory organization of source tree.
When thinking about the directory organization, we have to think about build process.

The discussion of this issue will continue, so I will start on my private branch.

The initial question is about platforms we support. Do you want to maintain code for
VAX, vms, amiga, os2 and riscos? I don't want.

Test units with valgrind-3.7.0

When running make -f testing.mak VG=1 test.units all tests fail when using valgrind-3.7.0, as available in Debian Stable 7.6.
According to STDERR.TMP:

valgrind: Bad option: --show-leak-kinds=all
valgrind: Use --help for more information or consult the user manual.

Convert Test/ to Units/*

Tests/* are unuseful because they don't define expected output.

Consider adding better PHP support from zargener/ctags

It's here

[ada, oldC] setjmp/longjmp related memory leaks

I found setjmp/longjmp are used widely in parsers.
valgrind reports the memory leaks related to them.
I guess longjmp is trigged when reading unexpected EOF.
Incomplete source code may make memory leaks.
These leaks will be a problem when ctags is used as a library in the future.

We have to introduce Trash based destructions in those parsers.

Is this an official mirror of https://sourceforge.net/projects/ctags/

Looking at the brew formula for installing ctags it is pointing at the sourceforge repo, and I saw a post on the sourceforge list that there was a proposal to use this repo as the new codebase. So, is this an official mirror, or has the codebase been migrated here, or what's going on?

Thanks,
Matt Smith

use an external command as a parser

Like --regex-= option introduce --cmd-= option.

Some people wrote their own tag generator for a language they are interested in.
e.g. https://github.com/lukaszkorecki/CoffeeTags
Good news is that the format of tags file generated by those generators is compatible with format defined at Exuberant Ctags project.

fishman ctags can be onestop unified front end for those generators.
If we use pipe to communicate with external generators, readtags is good place to start.

add android build support

should config.h.in be in the repo?

shouldn't it be removed? i just added an autogen.sh as that is what people are used to.

if i'd put the following inside it would modify the config.h.in

{ctags} % cat autogen.sh

!/bin/sh

echo "Running aclocal..."; aclocal $ACLOCAL_FLAGS -I m4 || exit 1
echo "Running autoheader..."; autoheader || exit 1
echo "Running autoconf..."; autoconf || exit 1

BILLBOARD for developers

Please, add your name, background and interests docs/f-developers.rst If you are
interested in contributing to fishman-ctags steadily. So we can
dispatch a task and/or an issue to perper person!

introduce sub parser

Consider running ctags against a source tree that uses autotools as its build system.

Which parser should be used for foo.h.in?

Of course C (or objc) parser should be used first of all.
Is it enough?
How about @Package@ or something in the file?
@foo@ is place holder used in autotools. I hope these are also tagged by ctags.
I would like to run the second priority parser(sub parser)something "template-of-configure-output".
The sub parser is activated for files globbed "*.in".

Suprisingly ctags has enough ability to run ,multi-path parser. We can use this function to run sub-parser.

Fails to compile on OS X Lion

./configure
make

results in:

gcc -o ctags args.o ant.o asm.o asp.o awk.o basic.o beta.o c.o css.o cobol.o dosbatch.o eiffel.o entry.o erlang.o falcon.o flex.o fortran.o get.o html.o jscript.o keyword.o lisp.o lregex.o lua.o main.o make.o objc.o ocaml.o options.o parse.o pascal.o perl.o php.o python.o read.o rexx.o routines.o ruby.o scheme.o sh.o slang.o sml.o sort.o sql.o strlist.o tcl.o tex.o verilog.o vhdl.o vim.o yacc.o vstring.o
Undefined symbols for architecture x86_64:
"_ObjCParser", referenced from:
_BuiltInParsers in parse.o
"_ObjCppParser", referenced from:
_BuiltInParsers in parse.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [ctags] Error 1

Test/objectivec_implementation.m fails

Tags generated from methods that have an opening brace on a new line always link to the first method in the file.

If the opening brace is on the same line as the method, methods that span multiple lines like in the test file will still return the incorrect location.

ctags --langmap=ObjectiveC:.m.h ./Test/objectivec_implementation.m

tests: ignore user's config

I'm seeing a lot of test failures, which is related to my own config being used.

I've tried to address this with the following patch, but this does not seem to help enough, and I am unsure if this is the proper way to do it:

diff --git i/testing.mak w/testing.mak
index 547125a..4e12557 100644
--- i/testing.mak
+++ w/testing.mak
@@ -123,14 +123,15 @@ test.units: $(CTAGS_TEST)
                \
                expected="$$t"/expected.tags; \
                expectedtmp="$$t"/EXPECTED.TMP; \
-               args="$$t"/args.ctags; \
+               options="$$t"/args.ctags; \
+                       test -f "$$options" || options="/dev/null"; \
                filter="$$t"/filter; \
                output="$$t"/OUTPUT.TMP; \
                diff="$$t"/DIFF.TMP; \
                \
                echo -n "Testing $${name}..."; \
                \
-               $(VALGRIND) $(CTAGS_TEST) --data-dir=Data --data-dir=+$$t -o - $$(test -f "$${args}" && echo "--options=$${args}") "$$input" |  \
+               $(VALGRIND) $(CTAGS_TEST) --data-dir=Data --data-dir=+$$t -o - --options=$${options} "$$input" |        \
                if test -x "$$filter"; then "$$filter"; else cat; fi > "$${output}";    \
                cp "$$expected" "$$expectedtmp"; \
                $(call DIFF_BASE,"$$expectedtmp","$$output","$$diff"); \

regression: getFileLanguage logic is reversed

The code used to look like this:

extern langType getFileLanguage (const char *const fileName)
{
    langType language = Option.language;
    if (language == LANG_AUTO)
    {
        language = getExtensionLanguage (fileExtension (fileName));
        if (language == LANG_IGNORE)
            language = getPatternLanguage (fileName);
#ifdef SYS_INTERPRETER
        if (language == LANG_IGNORE)
        {
            fileStatus *status = eStat (fileName);
            if (status->isExecutable)
                language = getInterpreterLanguage (fileName);
        }
#endif
    }
    return language;
}

The original logic is simple:

• check file extension; if that fails,
• check pattern; if that fails,
• look for some clues inside the file

The current version looks in the file first. In other words, every file passed to ctags is opened and in most cases read from both ends! This is very expensive. .o files are parsed for modelines (see pull request #122 ) -- it's not necessary. The code should be reversed to check the extension first.

@masatake, I realize that you added some logic for languages that share the same extention, in which case you added an election mechanism. I do not see why this means that the expensive checks should be done first.

Comments inline with properties breaks css.c parser

When there's a comment inline with a property nothing after that selector and property is parsed into tags. For example, try this:

border: 1px solid #b7c7d2; /* won't work with rounded corners, but looks best for non js */

Any ideas on how to fix it?

Thanks,
Wes

can't compile on Windows

When I compile on Visual Studio 2010, it show error below

options.obj : error LNK2019: unresolved external symbol _asprintf referenced in function _parseConfigurationFileOptionsInDirectory

Fix memory leaks around command and options parser

Very noise. This must be fixed.

[yamato@localhost]~/var/ctags-github% make -f testing.mak VG=1
...
Testing Units/conflib-recursive...==10951== 8 bytes in 1 blocks are definitely lost in loss record 1 of 3
==10951== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10951== by 0x431710: eMalloc (routines.c:238)
==10951== by 0x42493F: parseLongOption (options.c:611)
==10951== by 0x424A0F: cArgRead (options.c:634)
==10951== by 0x424D02: cArgForth (options.c:737)
==10951== by 0x426E8F: parseOption (options.c:1849)
==10951== by 0x426EB5: parseOptions (options.c:1857)
==10951== by 0x41FDE9: main (main.c:560)
==10951==
==10951== 8 bytes in 1 blocks are definitely lost in loss record 2 of 3
==10951== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10951== by 0x431710: eMalloc (routines.c:238)
==10951== by 0x42493F: parseLongOption (options.c:611)
==10951== by 0x424A0F: cArgRead (options.c:634)
==10951== by 0x424BCE: cArgNewFromLineFile (options.c:687)
==10951== by 0x426FCF: parseFileOptions (options.c:1882)
==10951== by 0x426334: processOptionFile (options.c:1411)
==10951== by 0x426938: processParametricOption (options.c:1659)
==10951== by 0x426B04: processLongOption (options.c:1714)
==10951== by 0x426E4C: parseOption (options.c:1841)
==10951== by 0x426EB5: parseOptions (options.c:1857)
==10951== by 0x41FDE9: main (main.c:560)
==10951==
==10951== 55 bytes in 5 blocks are definitely lost in loss record 3 of 3
==10951== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10951== by 0x431710: eMalloc (routines.c:238)
==10951== by 0x42493F: parseLongOption (options.c:611)
==10951== by 0x424A0F: cArgRead (options.c:634)
==10951== by 0x424BCE: cArgNewFromLineFile (options.c:687)
==10951== by 0x426FCF: parseFileOptions (options.c:1882)
==10951== by 0x427216: parseConfigurationFileOptionsInDirectoryWithLeafname (options.c:1935)
==10951== by 0x4274BF: parseAllConfigurationFilesOptionsInDirectory (options.c:2015)
==10951== by 0x427476: parseAllConfigurationFilesOptionsInDirectory (options.c:2013)
==10951== by 0x426343: processOptionFile (options.c:1412)
==10951== by 0x426938: processParametricOption (options.c:1659)
==10951== by 0x426B04: processLongOption (options.c:1714)
==10951==
Passed

Build process on MSYS

@ffes, I would like to fix the issue you wrote in f-wndows.rst.

I need to see config.status, config.h and the output of make.
I'm not sure these files can be attached to this comment area.
If they cannot, could you send them to me, [email protected]?

SQL parser always produces fully-qualified tags

I use tags to aid me browse through a large Toad dump of Oracle schema. There are large packages; they contains cursors, procedures, and so on. sql.c only creates fully qualified tags, so if the package is PACKAGE and cursor is CURSOR, the tag created is PACKAGE.CURSOR. The code:

static void makeSqlTag (tokenInfo *const token, const sqlKind kind)
{
    vString *   fulltag;

    if (SqlKinds [kind].enabled)
    {
        /*
         * If a scope has been added to the token, change the token
         * string to include the scope when making the tag.
         */
        if ( vStringLength(token->scope) > 0 )
        {
            fulltag = vStringNew ();
            vStringCopy(fulltag, token->scope);
            vStringCatS (fulltag, ".");
            vStringCatS (fulltag, vStringValue(token->string));
            vStringTerminate(fulltag);
            vStringCopy(token->string, fulltag);
            vStringDelete (fulltag);
        }
        makeConstTag (token, kind);
    }
}

However, inside the package, the cursor is referred to by the short name, simply CURSOR. This makes it impossible to jump to the cursor definition. This seems like a bug to me.

P.S. To work around this issue, I do

perl -ne 'print; s/^.+?\.// and print' tags | LC_ALL=C sort > all-tags && mv all-tags tags

avoid infinite loop

--timeout option or something to avoid a parser jumps into infiinite loop.

Project files for MS VS2013?

I have (and use) project files for Microsoft Visual Studio 2013. These allow VS2013 users to build and debug ctags from within the IDE.

I have placed them in the win32 directory.

Should I push those files (and some extra lines to .gitignore and f-windows.rst)?