<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Sam thanks for the response. Yes, a version of Typz's patch with only absolute- and relative-path support is uncontroversial (from my POV) and it would address the complications I have encountered. Please let me know if there may be a way I could contribute to the progress of the patch....not that I would have the time to work on it. ;)<div class=""><br class=""></div><div class="">Best,</div><div class="">Kyle<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 16, 2020, at 3:05 AM, Sam McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Kyle,<div class=""><br class=""></div><div class="">A similar feature has been proposed: allowing -style to refer to a filename. Could be style=file:<path> which is pretty close...</div><div class="">I guess it's a little clumsier for the user (and a little less work for the style authors) than what you propose. But it's simple, which is worth something - I don't like the idea of adding things to the format file itself to facilitate this.</div><div class="">And it would satisfy your goal around error-reporting: -style=foobar fails with "Invalid value for -style" and a nonexistent file could do the same.</div><div class=""><br class=""></div><div class="">The patch <a href="https://reviews.llvm.org/D50147" class="">https://reviews.llvm.org/D50147</a> got stalled over whether the files should be searched for relative to some predefined search path. I think a version that handled absolute or working-dir-relative paths would be uncontroversial. Would this work for you?<br class=""></div><div class=""><br class=""></div><div class="">cc Typz who wrote that patch and Mydeveloperday who is the most active clang-format maintainer.</div><div class=""><br class=""></div><div class="">Cheers, Sam</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020 at 9:28 AM Kyle Knoepfel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Forgive me if this has already been discussed. <br class="">
<br class="">
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.<br class="">
<br class="">
Would Clang be opposed to a specification like:<br class="">
<br class="">
clang-format -style=custom:my-projects-format ...<br class="">
<br class="">
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.<br class="">
<br class="">
Thanks for your input. If it is favorable, then I'm happy to explore implementing it.<br class="">
<br class="">
Kyle Knoepfel<br class="">
<br class="">
Software framework group leader, Fermilab<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>