Arguments starting with a capital letter have the wrong color

[shiro-42]

Default params of type String make the next params have a wrong color.

type Mutation {
  users(
    foo: String = "bar"
    " Here baz as wrong colors "
    baz: String
  ): UserConnection
}

Vim Version

NVIM v0.2.0
Build type: Release
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/super/clang -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNDEBUG -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -I/tmp/neovim-20170707-80027-1bg0wcx/neovim-0.2.0/build/config -I/tmp/neovim-20170707-80027-1bg0wcx/neovim-0.2.0/src -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/opt/gettext/include -I/usr/include -I/tmp/neovim-20170707-80027-1bg0wcx/neovim-0.2.0/build/src/nvim/auto -I/tmp/neovim-20170707-80027-1bg0wcx/neovim-0.2.0/build/include
Compiled by brew@Sierra-2.local

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/Cellar/neovim/0.2.0_1/share/nvim"

[jparise]

I see that this is highlighted incorrectly here in the GitHub markdown renderer, but I'm not seeing the problem in vim 8.1 (or neovim 0.2.2) when I try it locally. Both foo and bar are detected as graphqlFold -> graphqlName and highlighted accordingly:

Is your example extracted from a larger schema file that might help me reproduce the problem you're seeing? Could you identity which syntax group is being assigned to baz?

[shiro-42]

I don't know how to get the syntax group but the problem is when the key starts with an uppercase

[jparise]

Could you include a screenshot of what you're seeing? All of the "keys" in your example are in lowercase, so that's the part that I'm misunderstanding.

It's true that a word starting with an uppercase letter (e.g. String) will be identified as a type name and not an argument name, which is how I've implemented the GraphQL style convention rules.

You can follow the suggestions here to identify the syntax group: http://vim.wikia.com/wiki/Identify_the_syntax_highlighting_group_used_at_the_cursor

[shiro-42]

I am seeing this :

using the helper of the first answer here https://stackoverflow.com/questions/9464844/how-to-get-group-name-of-highlighting-under-cursor-in-vim

I get ['graphqlFold', 'graphqlConstant']

[jparise]

That is actually the intended (although not ideal) behavior. The syntax grammar isn't advanced enough to determine where constants, etc. are allowed so it assumes anything in ALL_CAPS is a constant and highlights it accordingly.

The GraphQL convention is to use camelCase to name parameters. Is there a reason why that convention isn't something you're able to follow?

[shiro-42]

my usecase is I'm directly mapping the arguments to a node modules so I can't choose to have camelCase for some arguments, but since it's not in the Graphql convention I don't know if it's still an issue.

[jparise]

Got it. Let's leave this issue open in case we come up with a nice way to implement a more strict grammar, but I'm afraid it's not a high priority.

[jparise]

I think the correct way to address this is to ultimately remove the "global" graphqlConstant syntax definition in favor of more specific definitions for enumeration values.

I already handled directive location names in #40.