RE: [Bug-indent] Re: status of indent

[Mark Moore]

Charlie and some David,

I agree that indent could and should be more actively developed.  If either
of you decide to maintain the source, I'd be more than happy to contribute.
My preference would be flex/bison, and cpp, but I'd be happy to contribute
whichever way you decide to go.

BTW, Debian has an active indent development effort (see
http://packages.debian.org/stable/source/indent).  Santiago Vila,
address@hidden, is the maintainer, and their current release is 2.2.9-5
as of 2003-10-31.

I don't monitor this list, so CC me at address@hidden (nuke
the SPAM).



> "Matt Ball" <address@hidden> wrote in message
> address@hidden">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 ;-)


Whether it's religiously better to host the development at savannah.gnu.org,
or sf.net, you should probably redirect from one to the other.  Since
savannah makes it so easy, it's probably easier to host at SF (IMHO).


> 
> > 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 ?

A derivative of C++.


> 
> Are you going to to preprocessing ?

No.


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

God, I hope not!  Reformatting the comments could be one of the more
powerful features.


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

Format alternate clauses independently. If the parser doesn't agree at the
closing endif, use the first alternative (and optionally emit a warning).


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

C is a subset of C++.  Other "C-like" languages should work EQUALLY well
depending on your defn of "like."

Keep in mind that *most* languages do not include a preprocessor.  Even C++
deprecates its use (although it's almost always used in practice).  Java,
javascript/ecmascript, and C# have no such notion.  They simply have their
defined grammars.


> 
> 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.

I agree wholeheartedly that indent should *not* look outside the given
source file by default.  For any decent code, a person can read it without
resorting to the header.  So should indent.

On the other hand, it would probably be a very useful feature to allow the
user to specify the include paths the same way they do for gcc and have
indent chew on the entire compilation unit (preprocessor and all).


> 
> > - 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 ?

Because it's likely the two constructs would be formatted differently.


> 
> > - 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).

>>>>>  Awesome!!  <<<<<


> 
> Cheers
> 
> Chqrlie.