On Mon, Apr 25, 2011 at 05:25:43PM +0200, Lech Lorens wrote:
> ... the real issue was with the following piece of code (which follows
> the coding style assumed during the development of Vim):
>
> #v+
> /* comment */
> void
> func(int a
> #if defined(FOO)
> , int b
> , int c
> #endif
> )
> {
> }
> #v-
I agree.
This looks like a bug.
With "ts" in cinoptions, "void" should be indented, not "func".
>
> which looks much better when indented as follows:
>
> #v+
> /* comment */
> void
> func(int a
> #if defined(FOO)
> , int b
> , int c
> #endif
> )
> {
> }
> #v-
I agree that it looks better.
To get this indentation set your cinoptions=(0,t0
No need for a patch, if that's all you want.
> While after applying my patch Vim's behaviour is still imperfect, I'd
> argue that it's better.
If I understand correctly, your patch assumes that:
1. The problem is caused by the pre-processing directive.
2. The "ts" option keeps return type in the first column.
Number 2 above is an incorrect assumption.
The "ts" means: indent the return type by a shiftwidth.
The "t0" means: leave return type in the first column (unindented).
Number 1 above may be true, but it's not a necessary condition.
When I remove all the preprocessing directives I get the wrong
indentation.
/* cinoptions=(0,ts <=> void should be indented by a shiftwidth */
void
func(int a
, int b
, int c
)
{
}
The following works as expected.
I don't use this style, but that is what "ts" means.
/* cinoptions=(0,ts <=> void should be indented by a shiftwidth */
void
func(int a, int b, int c)
{
}
The problem seems to be not putting all arguments on one line.
But than I tried this format and it worked correctly.
/* cinoptions=(0,ts <=> void should be indented by a shiftwidth */
void
func(int a,
int b,
int c)
{
}
Now, it seems the comma placement caused the problem.
Then I found out that this does not work correctly either:
/* cinoptions=(0,ts <=> void should be indented by a shiftwidth */
void
func(int a,
int b,
int c
)
{
}
So, the closing parenthesis on a separate line breaks indentation too.
We have multiple ways to trigger this bug without pre-processing
directive. I don't know how much is the above style used, but since the
"ts" option supports it, I agree that it should be fixed. I think we
have some test cases above to start with.
:-)
> With regard to the placement of the comma, in the sources of Vim there
> are 312 places where the comma is the first non-space character on the
> line.
As I said in the previous post, I agree that placing the comma on the
next line is an acceptable and commonly used stylistic exception to get
the pre-processing conditionals working correctly. It was necessary in
the context you used it.
Regards,
Zvezdan
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
