[cfe-dev] Clang-format / clang-tidy VS plugin

Tue Aug 16 20:54:01 PDT 2016

It is not exactly windows ecosystem, it is IDE ecosystem.
Clion for example have something like this:
https://www.jetbrains.com/help/clion/2016.1/configuring-code-style.html

So it allows you to modify some basic settings and also import setting from
file.

Having something like this would be awesome.

2016-08-16 20:49 GMT-07:00 Zachary Turner via cfe-dev <
cfe-dev at lists.llvm.org>:

> Pretty much this. Having a clang format file checked in is a great way to
> share settings among a team. It also unlocks the full power of the tool,
> whereas a UI may only sometimes expose a subset of that.
>
> But any time someone has to manually edit a file, or go online to look up
> documentation and figure out syntax and rules or whatnot, it's going to be
> a detractor.
>
> For better or worse, that's just the Windows ecosystem..
>
> An integration that used the .clang-format files as the underlying
> serialization format but exposed the resulting set of options through a
> rich UI would be the best of both worlds.
>
> I don't know how easy this will be , or even if it's possible. The visual
> studio project system expects settings to be defined at the project level,
> and at the file level every setting can be either inherited (default) or
> overridden. That doesn't line up perfectly with the clang format model of
> overriding at a directory level. If someone changes a setting at the
> project level, what does that mean for the style file? Same goes for
> modifying a setting at the file level.
>
> We could probably solve these problems by giving clang format the ability
> to override settings per file, but that's obviously more work.
>
> Now I remember why i put the settings in global options in the mockup :-/.
> It's hard at the project level
>
> On Tue, Aug 16, 2016 at 8:26 PM Michael Lewis <don.apoch at gmail.com> wrote:
>
>> The Windows lifestyle, for what it's worth, would prefer to have a GUI
>> for modifying the .clang-format settings but still serialize them as always.
>>
>> This way you get the accessibility without losing the strengths of having
>> a versionable file on disk.
>>
>> Speaking as a virtually all-Windows dev, I would be exceedingly happy to
>> get better clang-format support in VS. Writing a VS plugin isn't hard, for
>> what it's worth, and can totally offer a fully dynamic editor for the
>> settings stored on disk. I can definitely say that such a plugin would be
>> very popular even among programmers who don't build (primarily) with clang.
>>
>> - Mike
>>
>>
>> On Aug 16, 2016 8:05 PM, "Manuel Klimek via cfe-dev" <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Aug 16, 2016, 10:49 PM Zachary Turner via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> That is one idea that I considered, but from what I understand of how
>>>> to implement options UI in Visual Studio (I have never actually done this,
>>>> but looked at it for an hour or so once upon a time) the options and values
>>>> need to be statically defined in order to create the UI property sheet.  ie
>>>> you can't build one of these sheets dynamically, because the UI is
>>>> generated when Visual Studio loads your extension by reading some XML.
>>>> It's possible my understanding is wrong though.
>>>>
>>>> I agree that per-project and per-file settings would be nice.  I'll
>>>> have to think about this some more though, as you would want a tight
>>>> integration with what people normally expect with the project system, such
>>>> as being able to override settings on a per file basis.  This also means
>>>> figuring out how to make this interoperate (if at all) with existing
>>>> .clang-format settings files on disk.
>>>>
>>>
>>> That's why we have the files on disk. Do you think people on Windows
>>> would not want to just check in a .clang-format file and use style=file?
>>>
>>>
>>>> On Tue, Aug 16, 2016 at 12:41 PM Yury Mikhaylov <
>>>> yury.mikhaylov at gmail.com> wrote:
>>>>
>>>>> Can't we just ask clang-format to dump all options that its parser
>>>>> understands and use that info to populate property sheet in MSVC? Something
>>>>> similar to what -dump-config does now.
>>>>>
>>>>> I have also noticed that your mock-up shows the prop sheet in the
>>>>> system-wide settings. Won't it be better to keep them on per-project basis?
>>>>> Maybe even parse/regenerate .clang-format file in the project folder to
>>>>> allow versioning?
>>>>>
>>>>> - Yury
>>>>> On Fri, Aug 12, 2016 at 3:58 PM, Zachary Turner via cfe-dev <
>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> I was thinking about some ways to improve clang-format, and possibly
>>>>>> even add clang-tidy to the list of things our VS plugin supports.  Perhaps
>>>>>> even merge them into a single plugin.  But you know, I'm a windows person,
>>>>>> and I want a UI.  I don't want to just click a button and have it use some
>>>>>> settings that are on disk that I edited by hand, I'd like to be able to
>>>>>> edit the settings themselves through a nice UI, like everything in VS.
>>>>>>
>>>>>> This is kind of difficult if the plugin shells out to an external
>>>>>> tool without linking against it, because it doesn't have any knowledge of
>>>>>> what specific options and features the version it's calling might support
>>>>>> in order to build the appropriate UI to set them.  On the other hand, if it
>>>>>> links against the tool, this all becomes very easy, because the plugin can
>>>>>> share types and data structures with the tool itself.  And it also means
>>>>>> that someone could download the plugin without installing LLVM, as a
>>>>>> standalone tool, greatly reducing the barrier to entry for people wanting
>>>>>> to try out the tool.
>>>>>>
>>>>>> Here's a quick mockup of what my ideal UI would look like and what I
>>>>>> have in mind: http://imgur.com/a/p3XBv
>>>>>>
>>>>>> But again, it's hard to maintain this kind of thing if the VS plugin
>>>>>> has to rely on an external tool to do the formatting, since it would have
>>>>>> to know about every possible set of options for every version as the
>>>>>> software improves.  So in order to do this this way, we'd need to probably
>>>>>> build clang-format and/or clang-tidy as a DLL and bundle them with the
>>>>>> plugin, which could link against it.
>>>>>>
>>>>>> Not really asking anyone else to do the work so much as I am asking
>>>>>> if people think this would be cool and/or something they'd like to see.
>>>>>> Personally I think it would be a great way to get clang-format and
>>>>>> clang-tidy onto more peoples' systems, particularly those people who are
>>>>>> not currently using clang on Windows, since this would be standalone and
>>>>>> work out of the box while providing a familiar user interface to what
>>>>>> people are used to.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>
>>>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160816/94d3adbc/attachment.html>