Dev indent align braces

[pboettch]

No description provided.

[pboettch]

@blueyed I made my hands dirty on the indent file. This version seems to work, except for when using bracket-comments. Please give it a try and tell me what you think and why not adding more test-cases.

[blueyed]

I think this might be a good default - resulting in fewer changes in diffs (when the command/function changes). OTOH that's also not so common in CMake I guess.

[pboettch]

Defaulting to 1 you mean?

[blueyed]

Yes.
That seems to be the current behavior also, right?

[pboettch]

Yes, though it doesn't work correctly in all cases. Will be defaulted to 1 (or the variable name will change).

[blueyed]

@pboettch
Awesome. Will start to test drive this.

Some remark (which might not really apply): it is possible to also use syntax highlight / hl groups, so that e.g. comments can be skipped etc (see https://github.com/Vimjas/vim-python-pep8-indent/blob/master/indent/python.vim).

[pboettch]

What do you mean by getting comments skipped? Should comments always be aligned to the zero-column for you?

[blueyed]

I've meant that syntax can be used in expressions with searchpairpos for example.
It does not seem to be necessary really since there are only line comments (easier to handle/check).
But it should ignore any opening parenthesis in a comment.

[pboettch]

Cmake has sectional comments as well (#[[ ]]), see #14 .

Parens in comments can be a problem. I'll check whether it works or not.

[pboettch]

It seems to work, unless aligned comments are unwanted:

add_custom_command(tout # )
                   #add_custom_command(
                   hallo
                   )

[pboettch]

I added an option for users to select whether they want comment to be aligned a 0.

Also I tested parens in line-comments to see whether it breaks. It seems not to.

I'll merge this branch to master soon. Thanks for your initial work and thus making me learn vim-indent.

[blueyed]

With this commit it does not indent the endif correctly anymore:

Thanks for the quick fix! :)

[pboettch]

Thanks for finding.

[blueyed]

It does not handle the following (multiline string):

message(STATUS "foo
  bar")
  set(foo 1)

1. set() should get no indent (with o after the second line, or == on the line itself
2. the second line's indent should be kept as-is

That's a problem on master though already.

[pboettch]

Hard to solve this one. I basically didn't change the regexes which were already there. But they would need to be fixed in order to have something respecting multiline strings and intra-line-comments.

Resulting in a complete parser of the CMake-language.

[pboettch]

Actually it's not that bad. The while-you-type indent fails, but when re-indenting the whole block I get:

if(HALLO)
    message(STATUS "foo
    bar")
    set(foo)
    set(foo 1)
endif()

[blueyed]

It messes with the initial indent of the existing multiline string however:

if(HALLO)
    message(STATUS "foo
  bar")
    set(foo)
    set(foo 1)
endif()

This sounds like a good case where using the actual syntax would be useful: i.e. the line with the multiline comment has types "cmakeString cmakeArguments" - and lines starting with "cmakeString" could be left as-is. Ref: https://github.com/Vimjas/vim-python-pep8-indent/blob/dac91047444e5c907226b1cae39bb3ce428bc441/indent/python.vim#L112-L133

Resulting in a complete parser of the CMake-language.

That is kind of what the syntax provides already luckily.. :)