On 17/01/2008, Jim Blandy <jimb@codesourcery.com> wrote:
>
> "Rob Quill" <rob.quill at gmail.com> writes:
> > On 17/01/2008, Jim Blandy <jimb@codesourcery.com> wrote:
> >> Also, please be sure that the indentation follows the GNU coding
> >> conventions.  Substatements should be indented by two spaces.
> >> (c-exp.y is not a great place to look for examples, since it's a mess,
> >> but look at, say, frame.c.)
> >>
> >> From looking at your patch as it arrived through my mailer, it seemed
> >> that the code block for the new $in_scope grammar rule was not
> >> indented in the same way as the other blocks.  These should all be
> >> consistent.
> >
> > Hey,
> >
> > Sorry about getting the formatting consistently wrong. I've
> > reformatted it and it looks to me like it matches the other cases,
> > although it is hard to tell where to use tabs and where to use spaces,
> > and I'm never sure it's right as what if I have a different tab size
> > to you etc. I tried putting it through indent, but that just made a
> > mess, although as a rule is it OK to use that if it is a C file?
>
> I'm told Open Source projects avoid tabs, but it seems that GDB
> permits them, with tab stops every 8 columns.  The GNU coding
> standards don't say much about tab use or width, beyond saying that
> error messages that include line and column numbers should assume tab
> stops every 8 columns when computing column numbers.
>
> We don't generally use indent; if you look through the mailing list
> archives, you can see the arguments.  I can only remember the
> arguments that made sense to me, so I'm not sure I can accurately
> explain the reasoning.  :)
>
> If you use GNU Emacs C mode with the default settings, then TAB, C-j,
> and C-M-q will do the right thing.
>
> > +                       if (!have_full_symbols () && !have_partial_symbols ())
> > +                             error ("No symbol table is loaded.  Use the \"file\" command.");
>
> Too much indentation?

Well, you would think so, but I've changed the tab spacing in vim to 8
and the way I have formatted it matches how everything else is
formatted.

> > +
> > +                       /* Otherwise, prepare to write out the value */
> > +                       int_type = builtin_type (current_gdbarch)->builtin_int;
> > +                       write_exp_elt_opcode (OP_LONG);
> > +                       write_exp_elt_type (int_type);
> > +
> > +                       min_symbol =
> > +                         lookup_minimal_symbol (copy_name($3.stoken), NULL, NULL);
> > +                       if ($3.sym || min_symbol)
> > +                         write_exp_elt_longcst ((LONGEST) 1);
> > +                       else
> > +                         write_exp_elt_longcst ((LONGEST) 0);
>
>
>
> > +
> > +                       write_exp_elt_opcode (OP_LONG); }
>
> Closing brace should get its own line, since the opening brace did.

This is what I thought too, but if you look at the rest of the file
(for example the case for "exp : exp ARROW name") the open brace
always starts on a new line and always ends on the same line.

>
> > @@ -1678,6 +1704,9 @@ yylex ()
> >    /* Catch specific keywords.  Should be done with a data structure.  */
> >    switch (namelen)
> >      {
> > +     case 9:
> > +       if (strncmp (tokstart, "$in_scope", 9) == 0)
> > +     return IN_SCOPE;
> >      case 8:
> >        if (strncmp (tokstart, "unsigned", 8) == 0)
> >       return UNSIGNED;
>
> When I view this (again, with 8-column tab stops), the 'case' is not
> lined up with the other cases, and the 'return' is not indented two
> spaces within the 'if'.

Sorry, missed that. I've attached the fixed copy. I believe that the
amount of indentation matches the layout of the current file, and that
even though it looks like a lot in the context of the patch, all the
other grammar rules in the file use the same large amount of
indentation.

Rob