Re: Parser: make optional arguments compatible with lookahead (issue 41720043)

[dak]

On 2013/12/13 06:47:29, lemzwerg wrote:
> https://codereview.appspot.com/41720043/diff/1/lily/parser.yy
> File lily/parser.yy (right):


https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073
> lily/parser.yy:1073: if (!unsmob_music ($$))
> > What's more annoying is that the copy&paste passages often use
spaces
> > instead of tabs, while the global indentation style is supposed to
use
> > tabs.

> This is what I'm referring to.  I find such issues irritating, but
maybe this is
> only me.

> > The inconsistency is somewhat annoying, but in the interest of
letting
> > "git blame" work, gratuitous changes while moving lines around are
not
> > a good idea.

> Yep.  There are more such issues in the file, BTW.  I'm quite unhappy
that  we
> can't fix this easily without obfuscating results of `blame'
command...

One can "fix" indentation in a separate commit not doing other things.
In the particular case of lily/lexer.ll and lily/parser.yy however,
there is no automatic indentation available.  Indentation Linux with
tabs
merely means that you have to manually indent start and end of a syntax
rule and most lines inside of a rule will match that.

Since we have no automatic indentation engine that will work for those
files,
it seems pointless to do reorganizations manually that will not stay
around.

There is a comment at the start of those files essentially expressing
this
rationale.

I have not actively invested thought in the tabs/spaces in this patch:
the
Emacs settings here imply that new code will get tab-spaced, so the
space-spacing definitely stems from copy&paste passages.  Where they are
really copy&paste rather than cut&paste, git will likely not correlate
them anyway, but given the overall state of the file, it seems silly to
try making a large effort.

https://codereview.appspot.com/41720043/