From: Aaron Son Date: 2003-10-11T10:20:15+09:00 Subject: Re: Project suggestion: Ruby code indenter On 2003-10-11, Nikolai Weibull wrote: > * Gavin Sinclair [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