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

Don't touch newlines #246

Open
Codym48 opened this issue Feb 26, 2021 · 2 comments
Open

Don't touch newlines #246

Codym48 opened this issue Feb 26, 2021 · 2 comments

Comments

@Codym48
Copy link

Codym48 commented Feb 26, 2021

Is there an option for cmake-format to just leave existing newline characters alone? We'd like to use aspects of the tool to control tabs/spaces, alphabetization of lists, etc., but cannot find suitable settings for other arguments (max_subgroups_hwrap, max_pargs_hwrap, always_wrap, and layout_passes) that produce readable and mergeable code. We'd like to just turn off cmake-format's modification of newlines.

@cheshirekow
Copy link
Owner

We'd like to just turn off cmake-format's modification of newlines.

Hm... consistent linebraking is the foremost feature of cmake-format and it's raison d'être. There is no feature to turn it off currently. Any re-formatting that changes the relative order of tokens (e.g. sorting alphabetically) might get a little squirly. If cmake-format isn't allowed to choose linebreaks, would you just want to the same set of relative token locations but swap the tokens among those slots, so to speak? If the tokens aren't similar in size something that was "newlined well" will get reformatted into something which is not.

@Codym48
Copy link
Author

Codym48 commented Apr 5, 2021

The lists we'd like to alphabetize, primarily to reduce merge conflicts, are all vertical lists of files, directories, and other function arguments. As far as I can tell, the only way to guarantee our file lists are laid out vertically is to set both hwrap arguments to 1, which is the "hammer" that indiscriminately destroys the readability of all other statements, like multi-argument if statements.

Many of the issues we see are already described and acknowledged in #174, #138, and #136.

Rather than define rigid wrapping rules and accept continued maintenance burden of custom function configurations and command-specific settings, we'd like to empower the developers to choose the location of newlines, but use a formatter to enforce proper indentation and spacing and ...

This is how we have ArtisticStyle and yapf configured.

This would certainly allow the input file formatting to influence the output. Does that mean it's incompatible with the cmake-format vision?

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

No branches or pull requests

2 participants