Graham Percival 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 GNU standards, I'm
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 che
>> 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
[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 automatic
Graham Percival wrote Saturday, November 14, 2009 12:10 AM
On Sat, Nov 14, 2009 at 12:03:52AM +, Neil Puttock wrote:
2009/11/13 Graham Percival :
> Oh, and there's lots of
> MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
> -SCM
> + SCM
My emacs doesn't do this. :)
Joy of joys..
On Sat, Nov 14, 2009 at 12:03:52AM +, Neil Puttock wrote:
> 2009/11/13 Graham Percival :
>
> > Oh, and there's lots of
> > MAKE_SCHEME_CALLBACK (Axis_group_interface, print, 1)
> > -SCM
> > + SCM
>
> My emacs doesn't do this. :)
Joy of joys...
gperc...@sapphire:~$ emacs --version
GNU Emacs
2009/11/14 Neil Puttock :
> 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 mailing list
lil
2009/11/13 Graham Percival :
> 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 isn't strictly
neces
On Fri, Nov 13, 2009 at 04:52:48PM -0700, Carl Sorensen wrote:
> On 11/13/09 4:42 PM, "Graham Percival" 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 a
On 11/13/09 4:42 PM, "Graham Percival" 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.
Thanks,
Carl
__
On 11/13/09 4:24 PM, "Ian Hulin" wrote:
> Hi Carl and list,
>
> Carl Sorensen wrote:
>>
>>
>> On 11/13/09 9:59 AM, "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", b
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 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
On 11/13/09 4:36 PM, "Neil Puttock" wrote:
> 2009/11/13 Graham Percival :
>
>> 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 rever
2009/11/13 Graham Percival :
> 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" is getting
> really
On Fri, Nov 13, 2009 at 07:46:59PM +, Neil Puttock wrote:
> 2009/11/13 Graham Percival :
>
> > 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)
>
>
Hi Carl and list,
Carl Sorensen wrote:
On 11/13/09 9:59 AM, "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.
Th
On 11/13/09 12:39 PM, "Graham Percival" 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 line (yes, t
2009/11/13 Graham Percival :
> 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 8.5.5 (you added it
On 11/13/09 12:35 PM, "Graham Percival" wrote:
> 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
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 line (yes, this is possible) to
> > format one or more files? Emacs
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
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 emai
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)
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, th
> 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 n
On 11/13/09 9:59 AM, "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 ge
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
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 t
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
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, yo
- which set of options in astyle produces the smallest possible
diff with our existing code?
(don't answer the questions on the list -- go investigate them)
That is not interesting at all, as formatting rules should be introduced
incrementally.
__
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, you're saying, "go
find a tool that makes the code conform t
(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
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
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.
-
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
On Fri, Nov 13, 2009 at 08:41:06AM -0500, Chris Snyder wrote:
> There is one thing that bugs me about this discussion (and others) - it
> seems like sometimes improvements are rejected as being "not good
> enough," even if they're still an incremental improvement. Wouldn't
> running all of th
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 u
message
From: Graham Percival
Sent: 12 Nov 2009 15:03 -08:00
To: Chris Snyder
Cc: lilypond-devel
Subject: Re: Code formatter
On Thu, Nov 12, 2009 at 05:52:30PM -0500, Chris Snyder wrote:
> After the on-going discussion that included talk about formatting, I did
> a quick sear
2009/11/12 Chris Snyder :
> 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 o
On Thu, Nov 12, 2009 at 05:52:30PM -0500, Chris Snyder wrote:
> 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 e
42 matches
Mail list logo
