Now, the real problem I see with this approach is that no perfect
formatting (which is not the same as indentation) can be done without
actually parsing the input.
Complete parsing of LilyPond input is _impossible_ without LilyPond
itself. For example you need to format LilyPond code _inside_ Scheme
code (remember the #{ construct used in define-music-function)
So a standard formatting engine can only be written inside LilyPond, or
at least using LilyPond to generate metadata describing the structure of
the input.
Bert
Martin Tarenskeen wrote:
On Wed, 21 Oct 2009, Graham Percival wrote:
- it would be nice to have an option to replace the file directly
instead of
having to copy/paste the resulting file
Definitely!
Done in latest version. Use -m (--modify)
Be careful: This version overwrites the original file without making a
backup ( infile.ly~ )first. Maybe I should add that in the next version.
- scheme code is not handled (or indented uniformly)
Yes, scheme code should be formatted in the scheme way.
I know very very little about scheme. Some example lilypond files with
much scheme code might help.
- if within brackets there are tabs after the code and before the
end-bracket they are replaced by a bunch of blanks
Hmm, I'm not certain how often this would come into play.
I use tabs sometimes for indenting lines, but I haven't seen anyone
using tabs in the middle of a line of lilypond code
- in my programming style i prefer to have the endbracket aligned
with the
code above - maybe with an additional option this could be solved!?
I'd argue against this -- the point of a unified style /
indentation scheme is that it's *standard*.
...
I don't think we should have many options at all.
I agree
B
One more item to consider: whitespace at the ends of lines should
be stripped.
I thought I already did that ? I'll look in to it.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
