2014-06-29 6:10 GMT+02:00 Graham Percival gra...@percival-music.ca:
The question to ask is where do you want the burden of producing
properly formatted code?
- a volunteer who runs fixcc.py manually once a year?
(this also produces code reformatting commits which disrupt
git blame)
- an
Janek Warchoł wrote:
If badly formatted = different than what fixcc.py would produce,
i would say that LilyPond often gets badly formatted code - as you
wrote, running fixcc now results in 400 lines of changes.
There's some formatting that's different from what fixcc.py would
produce, but very
of astyle 2.02 vs. 2.04. I support
switching to 2.04.
However, fixcc.py should reject any version other than the
specific version we want. Otherwise, you could run it on your
computer (and push it), then I could run it on my computer (and
push it), then you could do the same thing
Graham Percival wrote:
However, fixcc.py should reject any version other than the
specific version we want. Otherwise, you could run it on your
computer (and push it), then I could run it on my computer (and
push it), then you could do the same thing, and basically we'd end
up with an
2014-06-28 16:53 GMT+02:00 Devon Schudy dsch...@gmail.com:
Graham Percival wrote:
However, fixcc.py should reject any version other than the
specific version we want. Otherwise, you could run it on your
computer (and push it), then I could run it on my computer (and
push it), then you could
On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote:
If badly formatted = different than what fixcc.py would produce,
i would say that LilyPond often gets badly formatted code - as you
wrote, running fixcc now results in 400 lines of changes.
This could, of course, be completely
Janek Warchoł janek.lilyp...@gmail.com writes:
I think we should enourage developers to use fixcc more often, and
then Graham's concern is very valid. I can say that having to move
past 5 code reformattings when doing git blame is pretty annoying,
git blame -w
--
David Kastrup
On 23/06/14 23:52, Federico Bruni wrote:
I can see 2.01 in debian wheezy:
Well when I built lilydev 2 I had to compile astyle from source manually
because the repos were behind from what we wanted (LilyDev at the time
was based on Ubuntu 10.04 but other distros I looked at were all behind
too) so
Hi,
our fixcc scripts says that it requires astyle in version exactly
2.02. However, the latest version is 2.04 and i didn't manage to find
packaged 2.02 version - does anyone know where i could get it? Or
maye we could use 2.04 after all?
I believe that having a tool like fixcc is absolutely
I can see 2.01 in debian wheezy:
https://packages.debian.org/search?keywords=astyle
Il 23/giu/2014 22:52 Janek Warchoł janek.lilyp...@gmail.com ha scritto:
Hi,
our fixcc scripts says that it requires astyle in version exactly
2.02. However, the latest version is 2.04 and i didn't manage to
Janek Warchoł wrote:
our fixcc scripts says that it requires astyle in version exactly
2.02. However, the latest version is 2.04 and i didn't manage to find
packaged 2.02 version - does anyone know where i could get it? Or
maye we could use 2.04 after all?
Sourceforge has all the old
On Mon, Jun 23, 2014 at 09:28:24PM -0400, Devon Schudy wrote:
The cases where 2.04 does worse than 2.02 are minor; I don't think
they're enough that fixcc.py should refuse to use it.
Thanks for the analysis of astyle 2.02 vs. 2.04. I support
switching to 2.04.
However, fixcc.py should reject
12 matches
Mail list logo