Config verification and colorless output

[Knyffen]

I've created a vim Neomake maker for verifying the integrity of my config file (shared for the curious).

let g:neomake_keymapper_enabled_makers = ['keymapper']
let g:neomake_keymapper_maker = {
    \ 'exe': 'keymapper',
    \ 'args': [],
    \ 'output_stream': 'stderr',
    \ 'append_file': 0,
    \ 'errorformat':
        \ "%E%m in line %l," .
        \ "%CLoading configuration failed," .
        \ "%C",
    \ }

Although it kinda works now it has some performance issues since keymapper is started and then killed, so I've added two flags --no-color and --check for respectively removing color from stderr output and for exiting right after parsing the config file.

I have pretty bad naming sense, so feel free to rename some of my variables if you find it bad. :P

I will link the commits after I've figured out how pull requests work.

[houmain]

Does the color interfere with the error message parsing? Or don't you like colors?

[Knyffen]

The color is mostly just terribly annoying for keeping a clean syntax. As currently it only detects a single error at a time, it can be worked around (as in the shown vim config), but since the color interferes with the next line creates a terrible mess.

Invalid macro name 'Virtual1' in line 1
Loading configuration failed


compared to

Invalid macro name 'Virtual1' in line 1
Loading configuration failed

Edit: By "worked around", I mean that I can parse the entire error message as a single message, but it isn't reasonable to parse each line individually.

[houmain]

Maybe I should rather remove the color output instead. But I will add the --check option, thanks.

[Knyffen]

Thank you for the quick response :-)

[Knyffen]

Heh, I think I just realized why vim "lags". It is probably because whenever I save my config, my keymapper background service blocks all input while it updates itself (unrelated to vim). Not that it changes anything as --check is still useful, but it is a kind of funny/stupid observation since I was wildly confused as to what caused the "lag".

[houmain]

Yes, right. The configuration reloading should not cause a reinitialization of the devices...

[houmain]

Yes, right. The configuration reloading should not cause a reinitialization of the devices...

This is fixed with commit 3b81fbbfee8cca4edc7a1652f749f4424a364162.