[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: S&S indentation maintainership.
From:       mwoehlke <mwoehlke () tibco ! com>
Date:       2006-09-12 14:55:28
Message-ID: ee6hp0$i5n$1 () sea ! gmane ! org
[Download RAW message or body]

Tim Hutt wrote:
> Hi, I recently started fixing things that annoy me in the S&S indentation 
> style, and would like to take over maintainership of it.
> 
> My plans include:
> 
> 1) Make it less aggressive - change the trigger characters to just "};:" 
> from "}{)/:;#n" (by the way what are the # and n for? It says something about 
> c# regions but as I don't know c# I can't work it out.)

I would have thought '#' was used for preprocessor, in which case the 
expected procedure is a: to outdent fully (column 0), and b: to ignore 
lines starting with '#' when calculating indent.

Are you (or have you already) going to fix it so it ignores '()'s in 
comments? I have a lot of trouble with this ATM. (Or maybe the solution 
is fixing the wrong auto-indentation of comments.)

> 2) Fix enums - currently they indent like this:
> 
> enum Colours
> {
>         Red,
>                 Blue,
>                 Green,
> };

Yes, please :-)

Oh, and right now I get case's like this:
   switch ( foo ) {
     case bar:
       first_line_is_ok();
     second_line_is_wrong();
     so_are_following_lines();
     break;
   }

> 3) Possibly change function implementations to indent like this:
> 
> void foo()
> <tab>

Seems like that would be OK. Btw, how do you handle multi-line function 
headers? There are at least a couple ways to do this; here are a few I 
would love to see supported (all of these are distinct and so could be 
detected). I think you would key on the line starting at column 0 to 
decide it is a function.

foo(int arg)
{...}

bar(long l,
     short s,
     void* p)
{...}

(this one needs an option for # spaces to indent arguments, which can be 
zero)
fubar(
  char* t
  int n
)
- or -
fubar
(
  char* t
  int n
)

I realize that these are not necessarily common standards, so they're 
meant as 'food for thought', i.e. things to think about how the indenter 
will handle them.


And there's the classic problem:

assert(long_function_name(long_arg_name,
                           another_arg));

... that currently wants to indent (incorrectly):
assert(long_function_name(long_arg_name,
        another_arg));



-- 
Matthew
Ok, so the quotes aren't entirely original.

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]