[PATCH] Added LanguageStandard::LS_JavaScript to gate all JS-specific parsing.

[Alexander Kornienko]

On Thu, Nov 21, 2013 at 8:19 PM, Manuel Klimek <klimek at google.com> wrote:

> On Thu, Nov 21, 2013 at 8:12 PM, Daniel Jasper <djasper at google.com> wrote:
>
>> Yes. A style option makes perfect sense. I am just (moderately) against
>> implementing a filename-based detection in ClangFormat.cpp.
>>
>
> I see. Yea, might not be super useful, true...
>

It might be useful for default styles: one can just invoke clang-format
-style=google test.js, and get a sane result. And I don't think it will
ever make sense to format .js files in C++ mode. But I don't feel strongly
either.


>
>>
>>
>> On Thu, Nov 21, 2013 at 11:11 AM, Manuel Klimek <klimek at google.com>wrote:
>>
>>> On Thu, Nov 21, 2013 at 8:05 PM, Daniel Jasper <djasper at google.com>wrote:
>>>
>>>> I think JS and C++ will almost always be in different sub-directories.
>>>> So different .clang-format files are the way to go..
>>>>
>>>
>>> That would be an argument for putting it in as a style option, right?
>>>
>>>
>>>>
>>>>
>>>> On Thu, Nov 21, 2013 at 10:45 AM, Manuel Klimek <klimek at google.com>wrote:
>>>>
>>>>> On Thu, Nov 21, 2013 at 7:38 PM, Daniel Jasper <djasper at google.com>wrote:
>>>>>
>>>>>>
>>>>>>   After thinking some more, I guess my main reason is that I strongly
>>>>>> doubt
>>>>>>   that we'll ever have a JavaScript style and a C++ style that are
>>>>>> identical
>>>>>>   in all aspects other than the LanguageStandard.. So, the detection
>>>>>> based on
>>>>>>   the file extension inside clang-format will likely be redundant..
>>>>>>
>>>>>
>>>>> I think this would be useful for mixed open source projects (or
>>>>> companies without an existing style guide).
>>>>>  One interesting point is that our configuration is very "repo"
>>>>> centric, and there are enough mixed repos out there - how would we want to
>>>>> support this without major setup effort required for every engineer
>>>>> contributing to a project...
>>>>>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/6875e73e/attachment.html>