[Bug-indent] Re: status of indent

[Charlie Gordon]

"Matt Ball" <address@hidden> wrote in message
news:address@hidden
> Hi David,

I'm Charlie, but I will give you my thoughts:

> I'm interested in possibly becoming the new maintainer of indent and
> making a version 2.3.0 (or 3.0.0...).  I'll need to spend several weeks
(or
> months) bringing myself up to speed with the code (and making some cleanup
> changes), but after that I should be able to get a new version out,
possible on
> sourceforge.net.  What are your thoughts?

Probably more likely on savannah ;-)

> I've got several ideas, including the following:
>
> - Add support for C++ (and maybe Java later)

Sure, and javascript as well...

> - Change the parser to use lex/yacc (i.e. flex/bison)

Why ?

The C tokens are simple enough that lex/flex is quite overkill, and what
grammar are you going to parse ?

Are you going to to preprocessing ?

What about comments, are you going to strip them out ?

What about ifdef'd sections, are you going to skip them ?

What about C-like languages and variants, what grammar will you enforce ?

Given the type of constructs you want to identify in the unpreprocessed
token stream, a grammar will hardly fit the purpose.  I don't think indent
should even try to make too much sense out of the source code.  It is so
unlikely indent will have the proper include pathes setup right, even the
include files might not be there, not to mention command line definitions,
architecture dependent defines, compiler specific extensions and typedefs...


Forget it, indent should only look at the current file and resort to simple
heuristics for block and statement extraction.

> - Improve the source code analysis so that the -T option isn't necessary
to
> identify typedefs (identify function argument declarations, and assume "A
*B;"
> is a declaration, not a useless multiply statement).

Why even assume it can be a multiply statement ?

> - Add an option to line up similar components of parallel structures (i.e.
> argument declarations, structure initializer tables, bit field ':',
parallel
> assignments, etc)

That would be nice!

Configuration by example would be nice too : give indent a template showing
how exactly you want code to look and make it determine its internal
configuration from the actual formatting of the template.  It shouldn't be
too difficult to implement, and indent could complain about what part of the
template it cannot reproduce.  This template file could be stored locally or
somewhere up the directory tree (a hidden .indent file for example, just
like .cvsignore).

Cheers

Chqrlie.