The configuration file blocks parsing

[redguardtoo]

Parsing Javascript:

Content of ~/.ctags:

--langdef=Javascript
--langmap=javascript:.js.ts
--regex-javascript=/^[ \t]*(var|let|const)[ \t]+([[:alnum:]_$]+)[ \t]*=[ \t]*\[/\2/v,variable/

Please note this is a bug related to ctags configuration file. Say I used to use a very old version of Exuberant Ctags which does not support Javascript. So I have to use --langdef=Javascript. Now I switch to Universal Ctags, but I DONOT want to update my ~/.ctags because I possibly be forced to use old Exuberant Ctags again. It's much better the program could ignore the error that Javascript is already defined and CONTINUE parsing.

The cli

$ ctags -x --options="$HOME/.ctags" test.js

The content of input file:

function hello() {}

The tags output you are not satisfied with:

ctags: Language "Javascript" already defined

The tags output you expect:

hello            function      1 test.js          function hello() {}

The version of ctags:

$ ctags --version
Universal Ctags 0.0.0(0c78c0c), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: May 27 2020, 10:53:43
  URL: https://ctags.io/
  Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +packcc

How do you get ctags binary:

Building it locally, via GNU/Linux distribution, as Debian Linux

[masatake]

Understandable but I don't support these use cases.

I will never consider sharing .ctags with e-ctags in u-ctags development.
To avoid sharing, I made u-ctags not read ~/.ctags though there were many objections.

If you use the "already defined" message, I would like you to revise your .ctags file.
The message means u-ctags has a built-in parser for the language and implies it
is good time for thinking about contributing to u-ctags.

I would like to you to try the built-in parser instead of your parser defined in .ctags.
If the built-in parser satisfies you, please remove the parser definition from the .ctags.
If your .ctags becomes empty, uninstalling e-ctags can be an option:-P

If the built-in parser doesn't satisfies you, open a new issue or make a pull request here though I cannot promise you to fix the issue or merge the pull request. This is the only way to extend the life of ctags. If u-ctags doesn't stop when detecting a parser redefinition as you request, we will lose the chance to receive the issue report and/or the pull request. It makes the life of ctags shorten. This is the worst case I would like to avoid.

If you want to add extra regex rules to a built-in parser, there are some choices.
If the rule fits the general purpose, I would like you to report here. It should be built-in.
If not, defining sub parser is one of the way.

I have some regex rules for reading Linux kernel written mainly in C language:

--langdef=LinuxOVS{base=C}
--kinddef-LinuxOVS=p,vportops,virtual port operation
--regex-LinuxOVS=/^static struct vport_ops +([a-z0-9A-Z_]+) +=/\1/p/

--langdef=LinuxXFS{base=C}
--kinddef-LinuxXFS=p,printk,printk functions
--regex-LinuxXFS=/^define_xfs_printk_level\((.*),.*/\1/p/

I don't merge this fragments to u-ctags because I think these rules don't fit the general purpose.
The benefits of this technique is that you can avoid the conflict of kind definitions.
e.g. In the LinuxXFS parser, a kind 'p' is defined. The 'p' kind is already defined in C parser for representing 'prototype'. However, I can use 'p' for my purpose because my 'p' is defined not in C parser; it is defined in a subparser of C.

$ cat /tmp/input.c 
static struct vport_ops vop = {
  //
};

int
main(void)
{
}

$ u-ctags -x --_xformat="%10{name} %10{language}:%{kind}" -o - /tmp/input.c 
       vop          C:variable
       vop   LinuxOVS:vportops
      main          C:function

If you don't want to use the built-in parser, but you want to use the name of the parser,
you can use --_pretend-<NEWLANG>=<OLDLANG> option...but you don't want to know
the detail of u-ctags more. What you want is sharing .ctags beween e-ctags and u-ctags.
Sorry but the answer is "you cannot".

[redguardtoo]

No problem. Thanks for the heads up.

[097115]

@masatake

Sorry for bringing up this old question but just wanted to clarify if you don't mind: if I want to use MY definitions for a language that is already supported, the only option is to use this pretend argument?

Say, I don't like the inbuilt R support (it's just an example, I don't know anything about the actual R support in universal ctags :). So, to $HOME/ctags.d/ I add RR.ctags, which has something like this:

--langdef=RR
--langmap=RR:.R.r
--regex-RR=/^[ \t]*"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t]function/\1/f,Functions/
--regex-RR=/^"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/g,GlobalVars/
--regex-RR=/[ \t]"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/v,FunctionVariables/
--_pretend-RR=R

Right? And this will override the inbuilt R support?

[masatake]

Sorry for bringing up this old question.

Thank you for finding this discussion. I'm interested that there is a person who is interested in --_pretend.

Right? And this will override the inbuilt R support?

YES.

I will show the way to verify the option works.

$ cat input.r
"a" <- function
$ cat rr.ctags 
--langdef=RR
--langmap=RR:.R.r
--regex-RR=/^[ \t]*"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t]function/\1/f,Functions/
--regex-RR=/^"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/g,GlobalVars/
--regex-RR=/[ \t]"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/v,FunctionVariables/
--_pretend-RR=R%                                                                                                                                   $ cat input.r 
"a" <- function
$ cat rr.ctags
--langdef=RR
--langmap=RR:.R.r
--regex-RR=/^[ \t]*"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t]function/\1/f,Functions/
--regex-RR=/^"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/g,GlobalVars/
--regex-RR=/[ \t]"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/v,FunctionVariables/
--_pretend-RR=R
$ u-ctags --fields=+'{language}' --options=rr.ctags -o - input.r                  
a       input.r /^"a" <- function$/;"   f       language:R

You can rewrite the options file more u-ctags way:

--langdef=RR

--map-RR=+.r
--map-RR=+.R

--kinddef-RR=f,Function,Functions
--kinddef-RR=g,GlobalVar,GlobalVars
--kinddef-RR=v,FunctionVariable,FunctionVariables

--regex-RR=/^[ \t]*"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t]function/\1/f/
--regex-RR=/^"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/g/
--regex-RR=/[ \t]"?([.A-Za-z][.A-Za-z0-9_]*)"?[ \t]*<-[ \t][^f][^u][^n][^c][^t][^i][^o][^n]/\1/v/

--_pretend-RR=R

I wonder why you want to use the option. Any interesting application?

[097115]

I will show the way to verify the option works.

Thank you for this reply and for your hints!

I wonder why you want to use the option. Any interesting application?

Not really :)

I just started using universal ctags, and simply wanted to make sure I can have my own definitions for an already defined language -- if I need to. Having this sort of flexibility is nice :)