Import diff parser from geany

[masatake]

No description provided.

[b4n]

if there is "new file" now, this should probably rather be "modified file (m)", what do you think?

[masatake]

@b4n, thank you for the great suggestions.
Updated.

[vhda]

Need to update the VS project files with entries for the added files.
We should really resolve #478 to have this feedback automatically.

[vhda]

Could you avoid using spaces in the long kind names? Could you instead use a single word in the long name and include a description containing the long name with space?
Apparently some tools might not be able to correctly parse extended information in the format modified file:path/to/file. This is true at least for Vim's Tagbar plugin.

[masatake]

format.rst doesn't say about spaces in value slot of extra fields:

A tagfield has a name, a colon, and a value: "name:value".

* The name consist only out of alphabetical characters.  Upper and lower case
  are allowed.  Lower case is recommended.  Case matters ("kind:" and "Kind:
  are different tagfields).

* The value may be empty.
  It cannot contain a <Tab>.

  - When a value contains a "\\t", this stands for a <Tab>.
  - When a value contains a "\\r", this stands for a <CR>.
  - When a value contains a "\\n", this stands for a <NL>.
  - When a value contains a "\\\\", this stands for a single '\\' character.

  Other use of the backslash character is reserved for future expansion.
  Warning: When a tagfield value holds an MS-DOS file name, the backslashes
  must be doubled!

Actually ruby parser uses a space in the slot:

static kindOption RubyKinds [] = {
...
    { TRUE, 'F', "singleton method", "singleton methods" },

Once the rule, "don't use space in values in extra fields" is introduced, we have to force the same rule to the regex paresrs and xcmd parsers. So we must be careful here. Of course applications are important.

@majutsushi, can I ask you a question about tagbar?
@vhda wrote your Tagbar plugin doesn't allow spaces(not tabs) in kind fields.
Isn't it possible to relax the restriction?

[masatake]

I will update the VS project file.

[masatake]

I see. It becomes issue when enabling scope information.

   {tagfield}   See below. 

A tagfield has a name, a colon, and a value: "name:value".
- The name consist only out of alphabetical characters.  Upper and lower case
  are allowed.  Lower case is recommended.  Case matters ("kind:" and "Kind:
  are different tagfields).

We should fix other parers. We should add Assertion to reject "alphabetical characters".
modifiedFile can be used.

[vhda]

Exactly. I think the other parsers do not have scope, so it's not a big issue.

[masatake]

...diff parser can be fixed easily but what we should do about ruby parser?
About regex parsers, I have introduce assertion or ...

typedef struct sKindOption {
    boolean enabled;          /* are tags for kind enabled? */
    int letter;               /* kind letter */
    const char* name;         /* kind name */
    const char* description;  /* displayed in --help output */
} kindOption;

A value for a name field should be generated from the value for the associated description.
How about xcmd....

After making kind names in diff parser caml case, I will merge this.

[masatake]

I will rethink about 3 compeonets of a kind: letter, name, and description.

[masatake]

I research this area a bit. Following parsers and their kinds violates "alphabetical characters" rule.

Fortran
    block data
Java
    enum constant
OCaml
    Record field
Perl
    subroutine declaration
Ruby
    singleton method
Vera
    system header
    local header

Should I fix all? For following the rule, we have to convert them to camel case strings.
Do you want?

I myself think we can allow characters other than tab character. Instead we should write it in docs/format.rst. a tab should be rejected with Assert.

exuberant ctags already introduced a space in kind name:

static kindOption JavaKinds [] = {
    { TRUE,  'c', "class",         "classes"},
    { TRUE,  'e', "enum constant", "enum constants"},

@vhda, you suggest me to use "new, modified, deleted". However I would like to use nouns.
If people want something short, one should use --field=k(single letter).

I wonder why exuberant ctags violates the rules defined in FORMAT. As far as I know the same person worked on the both products...

I wanted to work only the implementation, ctags. However, we may have to work on FORMAT.

[masatake]

preservim/tagbar#288

I asked a question about this issue to the tagbar developer.

I recognized exuberant ctags itself violates the spec defined in FORMAT file.
So we have to refine the specification.

[masatake]

I will merge my commits to reduce the issues.
I will reopen this issue after getting the comment from @majutsushi.