Graham Percival gra...@percival-music.ca writes:
On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote:
Jan believes that code formatting standards should be no more restrictive
than the GNU standards.
By the way, if somebody has a compelling argument why we should
differ from the
2) many programmers view code style in a highly personal,
quasi-religious manner.
...
...Han-Wen and Jan have different views...
Foe me its a matter of blocking the whitespace to to present the code in a
way that makes it easier to understand. This is not easy to do with any
automated tool.
Op vrijdag 13-11-2009 om 17:45 uur [tijdzone +], schreef Graham
Percival:
On Fri, Nov 13, 2009 at 04:59:20PM -, Trevor Daniels wrote:
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
interesting. is that really the GNU style? maybe I should check.
Or
Graham Percival wrote:
I'm afraid that you won't get many positive responses until you
look at the previous discussion about this issue. Again, the main
developers have been bitten by people in the past asking many
questions, spending hours explaining things to them, but then
ultimately giving
Graham Percival wrote:
1) running astyle will change lines of code. This makes the
history harder to look at... if we want to know who wrote a
particular line (say, there seems to be a bug here; hey Joe, why
did you write if (x = 3) ?), then it will appear that *you*
were the last person to
Yes, code formatting involves fascism.
- Someone, a lead architect should decide upon rules.
- Then a tool must be used to force these rules. It shouldn't be the
tool's rules, but the tool should support the rules defined by the lead
developer.
- You should NOT run it on all existing files.
-
On Fri, Nov 13, 2009 at 10:44:54AM -0500, Chris Snyder wrote:
Graham Percival wrote:
1) running astyle will change lines of code. This makes the
history harder to look at... if we want to know who wrote a
particular line (say, there seems to be a bug here; hey Joe, why
did you write if (x =
(sorry if it's a duplicate; email problems)
On Fri, Nov 13, 2009 at 10:44:54AM -0500, Chris Snyder wrote:
Graham Percival wrote:
1) running astyle will change lines of code. This makes the
history harder to look at... if we want to know who wrote a
particular line (say, there seems to be a
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't get done by itself.
Yes, I do think it's ridiculous. As I understand,
On Fri, Nov 13, 2009 at 04:59:20PM -, Trevor Daniels wrote:
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't get done by
Forget the tool. Astyle is very configurable, but we still could need
our own formatter (though I wouldn't like that).
Developing C++ code on Windows is practically impossible, but can be
well done with the VirtualBox pc for which I host the ISO (see the CG :))
So it doesn't matter whether the
Graham Percival wrote:
Whatever. You're giving up. All this time I've spent trying to
help you on this was wasted. I'm sure that more experienced
developers list are either laughing at me, or shaking
their heads sadly... oh that Graham, he's trying to help the
beginners, but he still doesn't
On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face this difficulty.
This job won't
The rules are already defined (albeit unsatisfactorily in my opinion):
Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
format one or more files? Emacs runs on Windows too, and
On Fri, Nov 13, 2009 at 08:01:41PM +0100, Werner LEMBERG wrote:
The rules are already defined (albeit unsatisfactorily in my opinion):
Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is
Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit :
The rules are already defined (albeit unsatisfactorily in my opinion):
Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
On Fri, Nov 13, 2009 at 01:17:43PM -0500, Chris Snyder wrote:
You're approaching this as if it's a technical issue. As of now, it's
not. I don't have the standing in the community to resolve the social
issues that must be dealt with first.
... you didn't learn anything from the long email
On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote:
Jan believes that code formatting standards should be no more restrictive
than the GNU standards.
By the way, if somebody has a compelling argument why we should
differ from the GNU standards, I'm willing to go up against Jan.
But
2009/11/13 Graham Percival gra...@percival-music.ca:
If you could choose one such example, and add it somewhere to the
CG similar to this:
http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
(bottom of the page)
that would be awesome.
It's already there in section
On 11/13/09 12:39 PM, Graham Percival gra...@percival-music.ca wrote:
On Fri, Nov 13, 2009 at 08:18:04PM +0100, Nicolas Sceaux wrote:
Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit :
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command
Hi Carl and list,
Carl Sorensen wrote:
On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
I know that you're thinking this is ridiculous, but unless
somebody does it, newbies will continue to face
On Fri, Nov 13, 2009 at 07:46:59PM +, Neil Puttock wrote:
2009/11/13 Graham Percival gra...@percival-music.ca:
If you could choose one such example, and add it somewhere to the
CG similar to this:
http://lilypond.org/doc/v2.13/Documentation/contributor/Sectioning-commands
(bottom of
2009/11/13 Graham Percival gra...@percival-music.ca:
Would it be worth adapting _ as an alternative to spaces inside
illustrations inside comments, just to avoid this problem?
Stating that the code style is whatever emacs does, as long as
you manually revert its formatting in areas X Y and Z
On 11/13/09 4:36 PM, Neil Puttock n.putt...@gmail.com wrote:
2009/11/13 Graham Percival gra...@percival-music.ca:
Would it be worth adapting _ as an alternative to spaces inside
illustrations inside comments, just to avoid this problem?
Stating that the code style is whatever emacs does,
On Fri, Nov 13, 2009 at 11:24:15PM +, Ian Hulin wrote:
Hi Carl and list,
Carl Sorensen wrote:
Do whatever emacs does.
In which case we need to understand, note and detail whatever emacs
does in the CG, so users of other editors can set their environment up
not to get into trouble
I'm amused that formatting everything in lily/*.cc with emacs
produces a 127 Kb diff.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 11/13/09 4:24 PM, Ian Hulin i...@hulin.org.uk wrote:
Hi Carl and list,
Carl Sorensen wrote:
On 11/13/09 9:59 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Chris Snyder wrote Friday, November 13, 2009 4:35 PM
Graham Percival wrote:
I know that you're thinking this is
On 11/13/09 4:42 PM, Graham Percival gra...@percival-music.ca wrote:
I'm amused that formatting everything in lily/*.cc with emacs
produces a 127 Kb diff.
Actually, that doesn't sound too bad to me, given the amount of code in
lily/*.cc and the lack of janitorial work we've had on the code.
On Fri, Nov 13, 2009 at 04:52:48PM -0700, Carl Sorensen wrote:
On 11/13/09 4:42 PM, Graham Percival gra...@percival-music.ca wrote:
I'm amused that formatting everything in lily/*.cc with emacs
produces a 127 Kb diff.
Actually, that doesn't sound too bad to me, given the amount of code
2009/11/13 Graham Percival gra...@percival-music.ca:
Oh, and there's lots of
MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
-SCM
+ SCM
My emacs doesn't do this. :)
IIRC, you mentioned this before; I think it's to do with (your) emacs
expecting a colon at the end of the macro (which
2009/11/14 Neil Puttock n.putt...@gmail.com:
IIRC, you mentioned this before; I think it's to do with (your) emacs
expecting a colon at the end of the macro (which isn't strictly
necessary).
D'oh. I mean semicolon of course. :)
___
lilypond-devel
--version
GNU Emacs 21.4.1
I'm guessing that you're on 22 ? Well, only one of those can be
the definitive standard. I guess we should declare emacs 22 to be
this? :(
I want an independent code formatter more and more... :(
(but that doesn't mean that I'll relax my standards (no pun
intended
releases. Seems a silly standard
to me, but then I'm not (yet) a developer.
I want an independent code formatter more and more... :(
(but that doesn't mean that I'll relax my standards (no pun
intended) on this issue)
No. You need an independent standard. A formatter can
come later.
Trevor
[using cc-mode for automatically formatting C++ code of lilypond]
IIRC, you mentioned this before; I think it's to do with (your)
emacs expecting a colon at the end of the macro (which isn't
strictly necessary).
D'oh. I mean semicolon of course. :)
In case we are going to automatically
After the on-going discussion that included talk about formatting, I did
a quick search for automatic code formatters, starting with one for the
C++ code (I think it's reasonable to expect to use a different formatter
for each programming language). I came across one - astyle
it would be easier if someone with push access
to git would do it. Any takers?
Woah there, cowboy. Slow down!
It's not going to be that easy. At a rough guess, I'd say that
the code formatter task will take 10-20 hours. Seriously.
- do we really want separate tools? (no, so is it impossible
2009/11/12 Chris Snyder csny...@adoromusicpub.com:
After the on-going discussion that included talk about formatting, I did a
quick search for automatic code formatters, starting with one for the C++
code (I think it's reasonable to expect to use a different formatter for
each programming
I think that the question is not whether we want to use a code formatter but
which one. Ideally applied automatically when pushing.
Also, is there a tool for c++ like checkstyle and pmd in the java world? That
could check for formatting issues and code smells and bad practices.
Original
38 matches
Mail list logo