Yea, integrating options probably isn't necessary for llvm developers, but i think it would be *huge* for driving adoption externally.  Same with bundling the tool with the plugin so that it could be distributed standalone, perhaps even from the vs extensions gallery<br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 14, 2016 at 3:14 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 12, 2016 at 6:58 PM, Zachary Turner via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> I was thinking about some ways to improve clang-format, and possibly even<br>
> add clang-tidy to the list of things our VS plugin supports.  Perhaps even<br>
> merge them into a single plugin.  But you know, I'm a windows person, and I<br>
> want a UI.  I don't want to just click a button and have it use some<br>
> settings that are on disk that I edited by hand, I'd like to be able to edit<br>
> the settings themselves through a nice UI, like everything in VS.<br>
><br>
> This is kind of difficult if the plugin shells out to an external tool<br>
> without linking against it, because it doesn't have any knowledge of what<br>
> specific options and features the version it's calling might support in<br>
> order to build the appropriate UI to set them.  On the other hand, if it<br>
> links against the tool, this all becomes very easy, because the plugin can<br>
> share types and data structures with the tool itself.  And it also means<br>
> that someone could download the plugin without installing LLVM, as a<br>
> standalone tool, greatly reducing the barrier to entry for people wanting to<br>
> try out the tool.<br>
><br>
> Here's a quick mockup of what my ideal UI would look like and what I have in<br>
> mind: <a href="http://imgur.com/a/p3XBv" rel="noreferrer" target="_blank">http://imgur.com/a/p3XBv</a><br>
><br>
> But again, it's hard to maintain this kind of thing if the VS plugin has to<br>
> rely on an external tool to do the formatting, since it would have to know<br>
> about every possible set of options for every version as the software<br>
> improves.  So in order to do this this way, we'd need to probably build<br>
> clang-format and/or clang-tidy as a DLL and bundle them with the plugin,<br>
> which could link against it.<br>
><br>
> Not really asking anyone else to do the work so much as I am asking if<br>
> people think this would be cool and/or something they'd like to see.<br>
> Personally I think it would be a great way to get clang-format and<br>
> clang-tidy onto more peoples' systems, particularly those people who are not<br>
> currently using clang on Windows, since this would be standalone and work<br>
> out of the box while providing a familiar user interface to what people are<br>
> used to.<br>
><br>
> Thoughts?<br>
<br>
I would *love* to see clang-tidy exposed as a plugin within Visual<br>
Studio. The existing clang-format integration we already have is<br>
basically the only reason I use clang-format -- I don't want to drop<br>
into a command line from my editor unless I absolutely have to, so<br>
integrating clang-tidy makes it far more likely to check code early<br>
and often. The tight integration of the options with the editor would<br>
be really nice, but not critical for my particular usage (the defaults<br>
for both tools are fine for my needs).<br>
<br>
~Aaron<br>
<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
</blockquote></div>