Re: [Bug-indent] Re: indent changes: request for comments

[david ingamells]

Chris,
On your reply, regarding the first point, I think I didn't quite make my 
point clearly. What I meant is that whatever the user has asked to be done 
for function and block braces should also be done to data initialisation 
braces. I see no need for new switches.

Regarding the third point, your example shows clearly what the problem is and 
indent clearly does it wrong.

Both these points will be added to the to-do list.

Thanks again for reporting them and taking the time to clarify.

Regards,
David.

On Friday 21 June 2002 5:10 pm, you wrote:
> Hello,
>
>    Thank you for your email!
>
> >The first and third points you made in April are not yet resolved. The
> >first,
> >namely the handling of the braces in a structure or array initialisation,
> >e.g.
> >
> >struct x_str x =
> >{
> >     1,
> >      2
> >};
> >
> >should, in my opinion be handled the same as function braces as they
> >essentially perform the same role.
>
> You are correct, the braces should be allowed to be on the same line as the
> struct/array initialization itself, or to be moved to the beginning of the
> next line, similar to how "-bl" and "-br" function.
>
> This would likely require a new set of command-line parameters, as some
> individuals would probably prefer the brace be at the end of the
> initialization, rather than the beginning of the next line.
>
> >Regarding your 3rd point, I don't fully understand your example. Could you
> >please send me a before and after example plus the switches you used?
>
> Not a problem. Here's some more info, and I'll elaborate a little.
>
> In the following pre-indent code snippet:
>
>         CliPrintf (this, "\r\n"
>                    "NVRAM Revision       = %d\r\n"
>                    "CLI Revision         = %q\r\n"
>                    "Firmware Revision = %d.%d.%d\r\n",
>                    "Device Version       = %q\r\n"
>                    "Device Build         = %q\r\n"
>                    "Build Date           = %q %q\r\n"
>                    CURRENT_NVRAM_REV,
>                    CURRENT_CLI_REV,
>                    firmware_version[0],
>                    firmware_version[1],
>                    firmware_version[2],
>                    fbVersion,
>                    fbBuildN,
>                    fbDate,
>                    fbTime);
>
> a bit of an inconsistency is exhibited when "honour_newlines" is enabled.
> The parameters are all in the correct column, with the exception of the
> last line:
>
>
>         CliPrintf (this, "\r\n"
>                    "Device Version       = %q\r\n"
>                    "Device Build         = %q\r\n"
>                    "Build Date           = %q %q\r\n"
>                    "NVRAM Revision       = %d\r\n"
>                    "CLI Revision         = %q\r\n"
>                    "Firmware Revision = %d.%d.%d\r\n",
>                    firmware_version[0],
>                    firmware_version[1],
>                    firmware_version[2], fbVersion, fbBuildN, fbDate,
> fbTime);
>
>
> I think I understand why the change occurred; compaction of the parameter
> list probably occurs (as though "honour_newlines" was disabled) until the
> right margin is reached, and _then_ the test of the "honour_newlines" flag
> is performed. If this is the case, the the state of "honour_newlines"
> should be tested before compacting lines.
>
> I don't think a new command-line parameter is required to address this
> behavior, as I believe this is a simple oversight in the logic.
>
> Please let me know what you think, one way or the other.
>
> Thanks,
> Chris
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com

-- 
David Ingamells
address@hidden
+31 (013) 5093388     (home)
+31 615010947 (mobile)