I am working on a system of markups which allows to specify more
flexible formatting rules. WE are using it for things like multi-line
embedded scores, mixing them with markup lines, rules about what things
/ combinations of things should not start / end a line, also there are
rules like "no line
On Sun, May 2, 2010 at 6:19 PM, David Kastrup wrote:
>> For one reason or another, whenever I review code from you it degrades
>> into a fight. I am not quite sure why this always happens.
>
> Because you don't bother taking the contributions of other people
> seriously. You don't read the code
Han-Wen Nienhuys writes:
> I apologise - I opened the page again, and expected it to always show
> the latest patch set, which it didn't obviously. That, coupled with a
> lengthy explanation of about using state machines made assume
> erroneously that you did not change the .ll code
The explanat
On Sun, May 02, 2010 at 06:10:21PM +0100, Trevor Daniels wrote:
>
> Carl Sorensen wrote Sunday, May 02, 2010 5:49 PM
>
>> On 5/2/10 4:45 AM, "Mark Polesky" wrote:
>>
>>> * Use bar-checks (`|') only when barring is unclear.
>>
>> I think we should always use bar-checks when the piece is more than o
Graham Percival wrote:
>> If anyone is up to it, I'd like someone to look over the
>> patch to see if I've made anything worse.
>
> I started looking, and saw some questionable stuff. I'll
> take a longer look later today, after I wake up and have
> coffee.
(the patch is at http://codereview.apps
On Sun, May 2, 2010 at 2:14 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Sun, May 2, 2010 at 8:04 AM, wrote:
>>>
>>> The tokens _are_ pushed one by one in the desired order. So it makes
>>> no sense to allocate additional storage just to do the same job.
>>
>> This is not about
Han-Wen Nienhuys writes:
> ideally, this would be broken up in two separate blocks of code, so we
> dont have one 70 line block of code, which suggests that something
> much more complicated is going on.
There were _37_ lines of code (please don't count comment lines
_against_ me) that do a more
Han-Wen Nienhuys writes:
> On Sun, May 2, 2010 at 8:04 AM, wrote:
>>
>> The tokens _are_ pushed one by one in the desired order. So it makes
>> no sense to allocate additional storage just to do the same job.
>
> This is not about saving storage. This block of code does 2 things:
>
> - transla
Carl Sorensen wrote Sunday, May 02, 2010 5:49 PM
On 5/2/10 4:45 AM, "Mark Polesky" wrote:
* Use bar-checks (`|') only when barring is unclear.
I think we should always use bar-checks when the piece is more
than one bar
long. That's a good habit to get into; we ought to start it right
f
On 5/2/10 4:45 AM, "Mark Polesky" wrote:
> * Use bar-checks (`|') only when barring is unclear.
I think we should always use bar-checks when the piece is more than one bar
long. That's a good habit to get into; we ought to start it right from the
first.
Thanks,
Carl
__
On Sun, May 2, 2010 at 8:04 AM, wrote:
>
> http://codereview.appspot.com/969046/diff/7001/8002
> File lily/lexer.ll (right):
>
> http://codereview.appspot.com/969046/diff/7001/8002#newcode545
> lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS.
> On 2010/05/01 19:56:08, hanwenn wrote:
>>
>>
On Sun, May 02, 2010 at 12:15:17PM +0100, Trevor Daniels wrote:
>
> Also need to specify default indenting is 2 spaces.
That's a pre-GDP rule. I'm sure it's in the CG already.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
ht
On Sun, May 02, 2010 at 03:45:49AM -0700, Mark Polesky wrote:
> So I guess I'm working towards a more formal standard for
> LilyPond code formatting.
1) wait for GLISS.
2) write/edit a scheme or python program to do this.
3) can we get bloody 2.14 out the bloody door before starting yet
another bl
Hi Mark
The only rule I disagree with is
* Use `\clef treble' instead of `\clef "treble"', etc.
The quotes are required for G_8 so should be present
on all for consistency and to avoid confusion.
Also need to specify default indenting is 2 spaces.
Trevor
- Original Message -
From:
http://codereview.appspot.com/969046/diff/7001/8002
File lily/lexer.ll (right):
http://codereview.appspot.com/969046/diff/7001/8002#newcode545
lily/lexer.ll:545: // loop will be EXPECT_NO_MORE_ARGS.
On 2010/05/01 19:56:08, hanwenn wrote:
wouldnt it be clearer to have a function
void trans
So I guess I'm working towards a more formal standard for
LilyPond code formatting. I combed through the LM
attempting to improve the ly code that's already there. In
the process I gleaned what I think are some reasonable
standards (some of which are already in CG 4.3.4 -- see
below).
If anyone
16 matches
Mail list logo
