uncrustify | Code beautifier - Firstly take a look at the CONTRIBUTING

It seems that the clean filter is applied before diff. Is that correct?

Yes. In at least some cases it must be. Consider, for instance, what happens if the smudge filter consists of, say, "double every character" and the clean filter consists of "remove the doubling"—or, if that seems too peculiar, if the smudge filter consists of "translate into some alternate character set" and the clean filter translates back.

A git diff to compare the work-tree against an actual commit must either run the smudge filter on the commit's content, or run the clean filter on the work-tree's content. Or it might even run both, with the output going to temporary files. (I'm pretty sure I tested this once, long ago, and found that the approach Git used was to run the clean filter, rather than the smudge filter. But see Cyker's comment, which suggests it runs both filters and then diffs smudged results.)

Is it possible to disable this? Would it be a good idea?

See above—at best you might have a "run only the smudge filter" option (but there is none).

Note that what's in the index is already clean, by definition. Cleaning happens on the transition from work-tree to index; smudging happen on the transition from index to work-tree.

Existing commits are strictly read-only and extracting a commit into the index makes no changes. Hence, while the index contents are clean by definition, if the clean filter itself has changed, they may not match what you would get by re-running the filter.

I would like a solution where autoformat is applied to the staging area, that is only the hunks that were staged. Isn't clean filter an appropriate solution?

This does not work the way you are thinking.

Running git add does not apply diff hunks to the index copy: running git add copies the entire work-tree file into the index. The whole thing gets cleaned.

Running git add -p also does not actually apply diff hunks to the index copy, because it literally can't. Instead, git add -p extracts the index copy to a temporary file, applies a diff hunk to the temporary file, and then copies the entire temporary file (with applied hunk) into the index, running that through the clean filter. Once again the whole thing gets cleaned—it's just that "the whole thing" is a temporary file built by patching the smudged index copy.

In other words, the index copy of each file is an entity unto itself, independent of the HEAD commit copy and the work-tree copy. Git starts out, at git checkout time, by just copying the commit copy of the file directly into the index (no changes, no filters), then copies the index copy of the file into the work-tree (smudge filter). At git add time, Git runs the clean filter on the work-tree file (or the patched result) and stuffs that into the index.¹

¹Technically, the index holds not the files themselves, but rather their content hashes. Adding a file consists of writing the file into the repository! The hash ID of the resulting blob object goes into the index. The index entry keeps the blob from being garbage-collected, if the index is the only place the blob is used (if the blob matches some committed blob then it's safe from the Grim Collector).

It looks like the problem was having ls_code_width set to true. Once I set it to false, uncrustify now seems to try to maintain groupings.

No, this is not one of the options.

Such a thing would be more of a refactoring, than a simple tweak to spacing (which is mostly what this tool does).

There's no open feature request for this at present, either; feel free to create one.

After about an hour of trial and error, the fix was to explicitly specify the extension in the shell script.

• Make sure uncrustify is installed on your computer, and accessible from CLI
• In the settings for atom-beautify, go under the C++ section and type uncrustify.cfg as a Config Path
• Place the config file name uncrustify.cfg in the root folder
• Try beautifying your code, it should be using your config file now

With an empty config file this does not happen so this behavior is caused by a option that you added in the config file that you are using (most likely one of the nl_* options).

Post a link to your file.

Both of this options are causing this behavior:

The package directory is

• Windows: C:\Users\\.atom\packages\atom-beautify\src\beautifiers\uncrustify

Uncrustify is run via index.coffee, resulting in arguments like:

Per CDanU's comment, the answer is: don't set indent_continue.

Why not try: