Re: Project suggestion: Ruby code indenter

On 2003-10-11, Nikolai Weibull <[e-mail]> wrote:
> * Gavin Sinclair <[e-mail]> [Oct, 11 2003 01:50]:
>>
> [me asking if it would be like indent(1)]
>>
>> Precisely like indent.  Say it were called 'rindent', then from
>> within Vim (or any editor; that's the point) you can run
>>
>>   :%!rindent
>>
>> and have it done nicely.  Obviously you're still going to use your
>> editor's indenting features as you type and want to correct small
>> blocks.
>>
> OK.  The good thing with Ruby, over C, for this kind of thing is that
> most people seem to keep to a rather similar way of 'type-setting'
> their programs.  We could perhaps use this to our advantage somehow.
>>
>> Also, Nikolai, I thought this would be perfect for you, as you have
>> already done it in VimL :-* and are gearing up to do it in pcpEdit in
>> Ruby ;)
>>
> Haha, OK.  I'll see what I can do.  I've always wondered if it would
> be possible to do this kind of thing with a yacc/racc or such similar.
> pcpEdit heh.  That will not be the official name ;-).  I'm thinking of
> 'ned', for Nikolai EDitor, or simply the name Ned (as in Flanders) in
> tribute of editors such as Sam, Wily, and family.  Other, more
> silly/stupid names were scamacs (emacs spelled backwards prepended to
> emacs, with e's removed) and scam-e (emacs spelled backwards).  And
> also, I haven't decided on Ruby yet, but yes, it will probably be Ruby
> actually.  I think it can work rather well.  

You mention yacc/racc, and I was curious as to your opinions on the
subject of an indent like program and the best way to approach it.

Due to the limitations of editors and the like, real-time indentation
calculation is inherently error prone because we're working with a
subset of the file and the more accuracy we want in the heuristics of the
indentation, the more complex our scripts which are responsible for said
indentation become.

One way to approach the problem when writing an external program which
is responsible for re-indenting a file would be to parse the file into a
kind of verbose abstract syntax tree and then write the tree back out
using straight forward rules regarding indentation and white space.
This has straight-forward advantages and disadvantages, as well as
consequences which I'm probably overlooking.  The major advantage that I
see is that the resulting file could be almost prefect given that we had
a parser for the complete grammar.  One of the disadvantages would be
that things like same-line comments would probably get converted to
full-line comments or vice-versa more often than desirable.  I'm also
not sure about the relative performances of the two methods...on one
hand parsing the entire file into a syntax tree is processor intensive
and requires memory space for the tree (although the file could be
parsed incrementally I suppose, writing out the nodes that we're
currently at as long as they're "closed", meaning they would no longer
affect the indentation of elements to come), whereas parsing regarding a
large set of regular expressions requires running the buffer of text
through multiple regexes, etc.

Personally, I think grammars and parsers are pretty fun/neat, so writing
an indent-like program using them would probably be more interesting
than writing one using a sequence of regular expressions similar to
writing a syntax file.  What's the normal way of doing this (i.e. how
are indent and astyle implemented) and what do you think would be the
best?  Any advantages or disadvantages of the methods that I'm not
seeing?

--Aaron