[cfe-dev] odd character limit while string formatting

[Arvind Dalvi]

The "readme.txt" says otherwise but I did attempt to build it in 2012 and it failed complaining about missing files (not clang-format.exe because I copied it).
Anyways, I have updated my extension to consider _clang-format file. Shall I attach my source zip to this thread (all participants) or send it across to you and Daniel only ?
From: klimek at google.com
Date: Mon, 15 Dec 2014 12:58:58 +0000
Subject: Re: [cfe-dev] odd character limit while string formatting
To: djasper at google.com; arvind.dalvi at outlook.com
CC: rcsaba at gmail.com; cfe-dev at cs.uiuc.edu

Why do you need a full clang build? Afaik the only thing you need is the clang-format binary (whereever you get that from).

On Sun Dec 14 2014 at 1:03:33 PM Daniel Jasper <djasper at google.com> wrote:
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/20141215/4abba970/attachment.html>