[cfe-dev] clang-format custom format specification

[Kyle Knoepfel via cfe-dev]

David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy.  Once we settle on a format, I expect the .clang-format to be included in the source-code repository, and this problem can be a non-issue.  Until we get there, however, this would be a very helpful safety mechanism.  

That said, I'm very cognizant of the XY problem, and do not want to be a perpetrator of it.

Thanks for your response,
Kyle

> On Sep 15, 2020, at 3:14 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> "clang-format for each input file will try to find the .clang-format
> file located in the closest parent directory of the input file." - so
> it shouldn't matter which directory you invoke the command from. If
> you have the .clang-format file in the parent of the file you want to
> format, it should always get that format.
> 
> Perhaps there's something broken in your setup that's causing that
> behavior not to work?
> 
> On Mon, Sep 14, 2020 at 5:47 PM Kyle Knoepfel via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> 
>> Forgive me if this has already been discussed.
>> 
>> I work on projects with different formatting guidelines.  For simple cases, it is simple to embed the .clang-format file in the correct (parent) directory, run `clang-format -style=file ...` and everyone's happy.  However, it is easy to get into a situation where the wrong format is applied, especially if you accidentally invoke the command from the wrong directory.
>> 
>> Would Clang be opposed to a command line invocation such as:
>> 
>> clang-format -style=custom:my-projects-format ...
>> 
>> where a field in the .clang-format file would have the value 'my-projects-format', thus attributing the file to the format name?  If a user specified something like -style=custom:my-unsupported-format, and such a format name could not be discovered in the .clang-format file, then it would be a hard failure, not letting a silent error slip by.
>> 
>> Thanks for your input.  If it is favorable, then I'm happy to explore implementing it.
>> 
>> Kyle Knoepfel
>> 
>> Software framework group leader, Fermilab
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev