[cfe-dev] odd character limit while string formatting

Sun Dec 14 04:03:33 PST 2014

CC'd Manuel, who developed the extension.

On Sun, Dec 14, 2014 at 12:46 PM, Arvind Dalvi <arvind.dalvi at outlook.com>
wrote:

> Daniel,
>
> I found out that my extension code developed in VS2013 (and based on
> AStyle source) is source compatible with VS2010. Unfortunately I cannot get
> the original clang-format-vs extension to compile because it requires a
> full build of clang via cmake (at least once). Is there a way to avoid a
> full build of clang ? If no, then somebody else building clang on frequent
> basis can use my extension code and do the necessary merging. Let me know
> where I can copy/attach/upload my extension.
>
>
> On 12-Dec-2014, at 6:39 am, Arvind Dalvi <arvind.dalvi at outlook.com> wrote:
>
> Alright. I will attempt it.
>
> On 11-Dec-2014, at 11:40 pm, Daniel Jasper <djasper at google.com> wrote:
>
> Do you think you could contribute that to the current extension? I don't
> think it is a good idea to create a second one. The source code is in
> <cfe>/tools/clang-format-vs.
>
> On Thu, Dec 11, 2014 at 5:28 PM, Arvind Dalvi <arvind.dalvi at outlook.com>
> wrote:
>
>> I could not see an option to format the document on “save”.
>>
>> On 11-Dec-2014, at 8:47 pm, Daniel Jasper <djasper at google.com> wrote:
>>
>> What's wrong with the extension that we already have (follow the link
>> from "Visual Studio" on http://clang.llvm.org/docs/ClangFormat.html)?
>>
>> On Thu, Dec 11, 2014 at 4:11 PM, Arvind Dalvi <arvind.dalvi at outlook.com>
>> wrote:
>>
>>>  Thanks Daniel for explaining the workings.
>>>
>>> One side note...I created a VS2013 (community edition) extension that
>>> uses clang-format.exe to format C++ and C# documents on request or during
>>> save operation. I have been using it for a week now and it works as
>>> expected. Can I submit my extension to clang community ?
>>>
>>> P.S.
>>> It is based off on AStyle extension source.
>>>
>>> ------------------------------
>>> Date: Mon, 1 Dec 2014 07:54:15 +0100
>>> Subject: Re: [cfe-dev] odd character limit while string formatting
>>> From: djasper at google.com
>>> To: arvind.dalvi at outlook.com
>>> CC: rcsaba at gmail.com; cfe-dev at cs.uiuc.edu
>>>
>>>
>>> clang-format works penalty-based. It considers both versions of this
>>> format (wrapping or not wrapping after the "(") correct. It prefers not to
>>> wrap, i.e. keep "&czString" on the same line. However, it also prefers
>>> not to automatically split string literals and that has a higher penalty.
>>> The reason is that it is more likely that the author has split or not split
>>> the string literal in a way that is preferable knowing the string's
>>> content. So the two short strings actually fit on a line if the line is
>>> wrapped before "&czString". For the second statement, however, the
>>> string needs to be split either way, as the string would not fit onto a
>>> line by itself anyway. Thus, clang-format can wrap it in a way to prefer
>>> keeping "&czString" on the same line.
>>>
>>> To work around this, you can manually break the strings the way you
>>> think they should be broken or reduce the penalty for breaking string
>>> literals (PenaltyBreakString -
>>> http://clang.llvm.org/docs/ClangFormatStyleOptions.html). The latter
>>> might lead to "interesting" behavior in some cases, though.
>>>
>>> The content of the string literal is 63 characters plus quotes plus "L"
>>> plus closing parentheses plus semicolon makes 68 characters. Assuming the
>>> 12 character indent from your first snippet is correct that put the string
>>> right up onto the 80 column limit. Adding a single character means that
>>> clang-format hast to line-wrap the string.
>>>
>>> On Sat, Nov 29, 2014 at 2:39 PM, Arvind Dalvi <arvind.dalvi at outlook.com>
>>> wrote:
>>>
>>> Hi Csaba,
>>>
>>> Yes, it was a single string which was then broken by formatting.
>>>
>>> Original:
>>> RtlInitUnicodeString(&czString, L
>>> "I am going to type a string that will be 63 characters only..\n");
>>>
>>> I have not tried with lesser characters.
>>>
>>> And one more thing, is there a way to format entire document while
>>> saving it ?
>>>
>>> Thanks,
>>> Arvind
>>>
>>> ------------------------------
>>> Date: Sat, 29 Nov 2014 13:17:42 +0100
>>>
>>> Subject: Re: [cfe-dev] odd character limit while string formatting
>>> From: rcsaba at gmail.com
>>> To: arvind.dalvi at outlook.com
>>> CC: cfe-dev at cs.uiuc.edu
>>>
>>> Hi Arvind,
>>>
>>> Are you saying that in all three cases, the original string was in one
>>> piece? (you didn't show us the originals).
>>>
>>> Have you tried with other lengths?
>>>
>>> Csaba
>>>
>>> On Sat, Nov 29, 2014 at 3:02 AM, Arvind Dalvi <arvind.dalvi at outlook.com>
>>> wrote:
>>>
>>> Hi Csaba,
>>>
>>> I agree. But my concern is the way formatting is done. If you look at
>>> the 2nd sample, the formatting looks correct where it has broken the string
>>> in to two and aligned it. Whereas in the case of 1st and 3rd it has not.
>>>
>>> Thanks,
>>> Arvind
>>>
>>> ------------------------------
>>> Date: Fri, 28 Nov 2014 18:59:40 +0100
>>> Subject: Re: [cfe-dev] odd character limit while string formatting
>>> From: rcsaba at gmail.com
>>> To: arvind.dalvi at outlook.com
>>> CC: cfe-dev at cs.uiuc.edu
>>>
>>>
>>> Hi Avind,
>>>
>>> The name of RtlInitUnicodeString is 20 characters long. That, plus a 63
>>> character string will not fit into 80 characters, which is probably set as
>>> the maximum line length.
>>>
>>>
>>> On Fri, Nov 28, 2014 at 1:13 PM, Arvind Dalvi <arvind.dalvi at outlook.com>
>>> wrote:
>>>
>>> I am assuming this list caters to clang-format tool too. If not, do let
>>> me know the concerned list.
>>>
>>> Today I downloaded the clang-format plugin for Visual Studio and
>>> realized that when a function call contains 63-character string, the
>>> formatting of the function call changes. If you look at the samples below,
>>> you would find that 2nd function call got formatted correctly, whereas the
>>> 1st and last pulled the parameters down. Is this expected ? If not, any
>>> setting that i can set to get the 2nd format applied to the 1st and to the
>>> last call ?
>>>
>>> RtlInitUnicodeString(
>>>             &czString,
>>>             L"I am going to type a string that will be 63 characters only..\n");
>>>
>>> RtlInitUnicodeString(&czString, L"I am going to type a string that "
>>>                                 L"will be 64 characters only...\n");
>>>
>>> RtlInitAnsiString(
>>>     azString,
>>>     L"I am going to type a string that will be 63 characters only..\n");
>>>
>>>
>>> Csaba
>>>
>>> --
>>> GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
>>> The Tao of math: The numbers you can count are not the real numbers.
>>> Life is complex, with real and imaginary parts.
>>> "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus
>>> Torvalds
>>> "People disagree with me. I just ignore them." -- Linus Torvalds
>>>
>>>
>>>
>>>
>>> --
>>> GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
>>> The Tao of math: The numbers you can count are not the real numbers.
>>> Life is complex, with real and imaginary parts.
>>> "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus
>>> Torvalds
>>> "People disagree with me. I just ignore them." -- Linus Torvalds
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141214/d9a9ce45/attachment.html>