Skip to content
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

Adding an option to only highlight namespace-prefixed names #1

Open
anntzer opened this issue Jun 24, 2017 · 9 comments
Open

Adding an option to only highlight namespace-prefixed names #1

anntzer opened this issue Jun 24, 2017 · 9 comments

Comments

@anntzer
Copy link

anntzer commented Jun 24, 2017

Although commenting out cppSTLfunction helps avoiding "too colorful" highlighting, there are still a lot of possibilities for extraneous highlights, e.g. the cppSTLtype "path".

Would it be possible to add a flag to only highlight names that are prefixed by their namespace (that would probably need to use a syntax match)? Or perhaps extra points if the "using" directive is configurable, e.g. the user can note in their vimrc "treat fs as the std::filesystem namespace, so highlight fs::path but not path"?

Thanks.

@anntzer
Copy link
Author

anntzer commented Aug 18, 2017

Something like

syntax region cppSTLscoped start='\(std\)\@3<=::\<' end='\>' contains=cppSTLtype

syntax keyword cppSTLtype allocator contained
syntax keyword cppSTLtype auto_ptr contained
syntax keyword cppSTLtype basic_filebuf contained
...

(with separate groups for each namespace if we want to actually check the namespace, or with a single container group just checking for a preceding ::) works.

@bfrg
Copy link
Owner

bfrg commented Oct 6, 2017

@anntzer I gave up on such complicated syntax highlighting long time ago. I didn't really need it anyway. Have you tried color_coded?

@anntzer
Copy link
Author

anntzer commented Oct 6, 2017

The main problem I have with color_coded (and other similar tools) is the need to maintain a .color_coded file. My use case is often python extension modules, where the build flags are generated by setup.py and often requires shelling out to pkg-config anyways. In fact the include paths are likely to be different from one environment to another, so a static .color_coded will just not be enough.

@bfrg
Copy link
Owner

bfrg commented Oct 6, 2017

There's YCM-Generator that also generates .color_coded files.

@anntzer
Copy link
Author

anntzer commented Oct 6, 2017

It does not support setuptools (https://github.com/rdnetto/YCM-Generator#requirements-and-limitations). Even if I were to write it manually, .color_coded is necessarily a static list of flags, which is not sufficient (pkg-config actually returns different paths on different build systems for me).
If .color_coded was actually able to interpolate subcommands (or run some $scriptlanguage) then I would be able to manually work around it, but right now it's not the case.

@bfrg
Copy link
Owner

bfrg commented Jan 20, 2018

Have you looked at the alternatives clighter8 or chromatica.nvim? Both are written in python.
There is also taghighlight, which highlights keywords based on a ctags file.

@anntzer
Copy link
Author

anntzer commented Jan 20, 2018

From a quick look, all the compiler-based projects suffer from the same issue (already mentioned above): they require a static list of compile flags (which may or may not be autogenerated via cmake/bear/etc.). This does not handle the (my) case where your compilation options are e.g. $(CXX) $(pkg-config --cflags pkg) ...: good old makefiles are not dead yet.

TagHighlight may or may not work, haven't looked too much into it.

@bart9h
Copy link

bart9h commented Jun 20, 2020

I also find it annoying to have variables like "hours", and "path" highlighted like they were special.
Maybe a simpler solution would be an option to not highlight these unless there is a leading "::".

@bfrg bfrg reopened this Jun 20, 2020
@bfrg bfrg removed the wontfix label Jun 20, 2020
@bfrg
Copy link
Owner

bfrg commented Jun 24, 2020

I am not completely against it, but with Vim's currently shipped c.vim syntax file it just won't work most of the time.

What you asked for could be accomplished with something like:

syntax match cppSTLscoped "::" nextgroup=cppSTLtype
syntax keyword cppSTLtype contained hours path vector
highlight default link cppSTLtype Type

Now when hours, path or vector appear after a :: they will be highlighted as Type. The contained (alternatively we could also write containedin=cppSTLscoped) makes sure that these keywords are highlighted only when contained in another syntax group and not on their own.

But the problem is the ALLBUT option in the following syntax declaration in Vim's default c.vim syntax file:
https://github.com/vim/vim/blob/67fbdfefd26a237831c3838f799d3e6198c8a34a/runtime/syntax/c.vim#L161-L162

It basically says that any syntax group contained inside parentheses will be highlighted. See :help syn-contains for more details. This means, cppSTLtype will be highlighted when appearing inside parentheses, even without the preceding ::. For example, path will be highlighted in both foo(path) and foo(std::path).

A workaround is to clear the already declared syntax group cParen and redefine it with cppSTLtype:

syntax clear cParen
syntax region cParen transparent start='(' end=')' 
    \ contains=ALLBUT,@cParenGroup,cCppParen,cErrInBracket,cCppBracket,@cStringGroup,@Spell,cppSTLtype

Now cppSTLtype is highlighted only when appearing after a ::.

When you look at the shipped c.vim syntax file, cParen is declared multiple times, depending on the file type, the C++ standard, and whether or not the user wants curly or bracket errors highlighted. I am very hesitant to copy/paste all those lines just for the sake of cppSTLtype. And I haven't found another way yet.

There is already a request to fix this ALLBUT behavior, see vim/vim#1265.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants