-
Notifications
You must be signed in to change notification settings - Fork 630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[INCOMPATIBLE][SELF INCOMPATIBLE] main,Tmain: revise acceptable characters for kind letters and kind names #1737
[INCOMPATIBLE][SELF INCOMPATIBLE] main,Tmain: revise acceptable characters for kind letters and kind names #1737
Conversation
5aed46f
to
3206355
Compare
3206355
to
a984689
Compare
I must update ctags-incompatibilities.7.rst.in, too. |
The kinds of HTML parser includes number letter ([0-9]) in their name:
Though HTML parser doesn't do so but the name of kind can be used in scope field in abbreviated form.
This is o.k. However,
this abbreviated from violates a rule written in format.rst:
tag.c in vim uses "isalpha". For a kind letter, use isalpha for recognizing it. This is simple. We should not use a number character as a kind letter. For a kind name, use isalpha for recognizing it. However, vim checks the only the first character of the kind name. The rest of characters can be any. The exception is Using "heading1" in HTML parser doesn't cause a trouble in vim users as far as they don't use extra plugins. I wonder what I should do. Maybe accepting "[a-zA-Z][a-zA-Z0-9]*" as a kind name is better. About "kind letter", the code is updated. ctags-optlib.7 man page is updated. ctags-incompatible.7 must be updated. About "kind name", all are not ready. About the other named things like field, I will write in #1711. Comments are really welcome. |
a984689
to
e72b772
Compare
All documents are updated. Kind letters and kind names related incompatibilities are documented. |
e72b772
to
c4fb195
Compare
I have to clean up the initial comment and I have to ask people reviewing the man pages. |
c4fb195
to
cf3f2a5
Compare
@ploxiln, thank you very much. I will reflect your comment to the changes. |
I reflected all the suggestions from @ploxiln. I will rebase this branch to master. |
f251174
to
7300417
Compare
Rebased. When merging, I will squash all "!squash" commits. |
I forgot updating the expected output of test cases. |
|
7300417
to
03cc742
Compare
Codecov Report
@@ Coverage Diff @@
## master #1737 +/- ##
==========================================
+ Coverage 86% 86.01% +<.01%
==========================================
Files 175 175
Lines 35161 35177 +16
==========================================
+ Hits 30240 30257 +17
+ Misses 4921 4920 -1
Continue to review full report at Codecov.
|
Adding the description of this change to README.md is needed because the impact is so big. |
…alpha char as a kind letter Exuberant-ctags accepts any character given via --regex-<lang>=/pattern/name/L,... option. Universal-ctags accepted isalnum character given via --regex-<lang>=/pattern/name/L,... option and --kinddef-<lang>=L,... option. Though what kind of character we can use as kind letter is not written in FORMAT file, vim accepts only "isalpha" char as kind letter. So ctags should not allow users to define a kind using non-isalpha char. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…rong kind letter Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…ical char as the first letter in a kind name SELF-INCOMPATIBLE aspect: When defining a kind with --kinddef-<LANG>, Universal-ctags accepted both an alphabetical and a numerical characters as the initial letter. With this change, Universal-ctags accepts only an alphabetical. INCOMPATIBLE aspect: Universal-ctags accepts numerical characters as the rest letters (other than initial letter) in a kind name. This violates the tags v2 format. This commit documents it as an EXCEPTION. We must convert the EXCEPTION to planed v3 format. Exuberant-ctags doesn't have --kinddef-<LANG>. However, a kind can be defined with --regex-<LANG>. This commit doesn't deal with the option. Re-wording is suggsted by @ploxiln. Revising the error message is suggested by @ploxiln. A wrong sentence is pointed out by @ploxiln. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…ANG> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…n kind name defined with --regex-<LANG> This change has big impact. As far as browsing .ctags files in github, people users whitespace in kind names defined with --regex-<LANG>. This change rejects them. A kind name is used for "value" part of tagfield. In this case, there is no trouble in using a whitespace (and characters other than alphabetical char). However, a kind name can be used "name" pat of tagfield when printing scope field. In this case, using characters other than alphabetical char in the kind can be a cause of trouble. (After long thinking I decide to add an exception; using a numerical char as parts of the body of a kind name is allowed. Here "body" means non-initial letters of the kind name.) Revising the error message is suggested by @ploxiln. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…ies.7 Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Wrong English usage is pointed out by @ploxiln. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
03cc742
to
e6d75a1
Compare
(This initial comment is completely rewritten after updating the changes.)
Neither whitespace characters nor characters other than [a-zA-Z0-9] are not allowed as a kind name defined with --regex- option.
A kind definition consists of three parts: a letter, a name, and a description.
--kinddef- and --regex- options are for defining a kind.
The pull request changes the acceptable characters for defining a kind.
If merging this pull request, ctags accepts alphabetical characters
other than 'F' as a kind letter: [a-zA-EG-Z] in a regex. ctags
accepts alphabetical characters as the first character of a kind
name. ctags accepts alphabetical and numerical characters as the rest
characters.
Exuberant-ctags accepts any characters. As the result Exuberant-ctags
can generate a broken tags file.
Here is an example of generating a broken tags file:
With --regex-C, a kind with a kind letter '|' and a kind name "|||||" is defined.
v2 tags format expects alphabetical characters for a kind name which uses in
value parts of a tagfield. '|' in "|||||" violates this. The v2 tags format
doesn't say much about kind letters. However, as far as reading the tags file
loader of vim, only alphabetical characters are acceptable.
Universal-ctags with this pull request, ctags can generate a tag file
following the v2 tags format with one exception. Universal-ctags
allows using numerical characters in a kind name unless it is used as
the initial character of the name. This compromise is for acceptable
heading1, heading2, and heading3 kinds of HTML parser. I guess there
will be more cases that users (and developers) want to use numerical characters
in their kind name. Though, accepting numerical characters violates
the v2 tags format, the tags file loader of vim accepts a name as
far as the name starts from an alphabetical character. In other hands,
vim rejects a symbol character like '|'.
Close #597.