Janek Warchoł writes:
> On Tue, Sep 4, 2012 at 5:54 PM, Han-Wen Nienhuys wrote:
>>
>>> Isn't this an argument for delimiting the argument list?
>>
>> It is. The disadvantage is that it breaks all existing files.
>
> I think i remember one of the developers saying "we should also care
> for futur
On Tue, Sep 4, 2012 at 6:25 PM, Han-Wen Nienhuys wrote:
Isn't this an argument for delimiting the argument list?
>>>
>>> It is. The disadvantage is that it breaks all existing files.
>>
>> I think i remember one of the developers saying "we should also care
>> for future users, and that's [h
On Tue, Sep 4, 2012 at 3:40 PM, Janek Warchoł wrote:
> On Tue, Sep 4, 2012 at 5:54 PM, Han-Wen Nienhuys wrote:
>>
>>> Isn't this an argument for delimiting the argument list?
>>
>> It is. The disadvantage is that it breaks all existing files.
>
> I think i remember one of the developers saying "w
On Tue, Sep 4, 2012 at 5:54 PM, Han-Wen Nienhuys wrote:
>
>> Isn't this an argument for delimiting the argument list?
>
> It is. The disadvantage is that it breaks all existing files.
I think i remember one of the developers saying "we should also care
for future users, and that's [hopefully] a b
Joe Neeman writes:
> On Tue, Sep 4, 2012 at 1:00 AM, David Kastrup wrote:
>
> The argument list as such would require delimiting to make this
> work independently from advance knowledge about the number of
> elements. Which gets us to Scheme syntax. The enthusiasm of
> peop
On Tue, Sep 4, 2012 at 12:21 PM, Joe Neeman wrote:
>> > With the current syntax, this is certainly true. But if a music
>> > function's arguments were delimited syntactically somehow then we
>> > could parse without interpreting any music functions, right?
>>
>> The argument list as such would req
On Tue, Sep 4, 2012 at 1:00 AM, David Kastrup wrote:
> Joe Neeman writes:
>
> > On Mon, Sep 3, 2012 at 2:46 PM, David Kastrup wrote:
> >
> > Janek Warchoł writes:
> >
> > > On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys
> > wrote:
> > >> To me, a Grand Input Syntax "fixing"
David Kastrup writes:
> Not if we are talking about a _transparent_ format (readable by more
> than humans and LilyPond itself). If we could let LilyPond deal with
> MusicXML for both input and output (which would both be basically
> "untweaked"), we'd cover quite a bit of application area.
and
Werner LEMBERG writes:
>>> Ouch. Sound like something we seriously don't want at all.
>>
>> Right - this means that we seriously don't want to be a music
>> interchange/storage format.
>
> What about a *subset* of LilyPond for this purpose?
It should be reasonably easy to use displayLilyMusic
Joe Neeman writes:
> On Mon, Sep 3, 2012 at 2:46 PM, David Kastrup wrote:
>
> Janek Warchoł writes:
>
> > On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys
> wrote:
> >> To me, a Grand Input Syntax "fixing" of LilyPond, would amount
> to
> >> creating a syntax that
Han-Wen Nienhuys writes:
> On Mon, Sep 3, 2012 at 7:20 PM, Janek Warchoł
> wrote:
>>> Well, one simple consequence would be that one can't define music
>>> functions in a document (their definition is interpretation, their use
>>> is parsing). The use of Scheme would be quite constrained, as r
Han-Wen Nienhuys writes:
> On Mon, Sep 3, 2012 at 7:20 PM, Janek Warchoł
> wrote:
>>> Well, one simple consequence would be that one can't define music
>>> functions in a document (their definition is interpretation, their use
>>> is parsing). The use of Scheme would be quite constrained, as re
On Tue, Sep 4, 2012 at 2:37 AM, Joe Neeman wrote:
>> >> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
>> >> creating a syntax that strictly separates parsing and interpretation.
>> >> This implies not only rethinking a lot of syntax, but also it means
>> >> letting go of some
On Tue, Sep 4, 2012 at 6:37 AM, Werner LEMBERG wrote:
>>> Ouch. Sound like something we seriously don't want at all.
>>
>> Right - this means that we seriously don't want to be a music
>> interchange/storage format.
>
> What about a *subset* of LilyPond for this purpose?
Yeah - if that made sens
On Mon, Sep 3, 2012 at 2:46 PM, David Kastrup wrote:
> Janek Warchoł writes:
>
> > On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys
> wrote:
> >> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
> >> creating a syntax that strictly separates parsing and interpretation.
> >> Thi
>> Ouch. Sound like something we seriously don't want at all.
>
> Right - this means that we seriously don't want to be a music
> interchange/storage format.
What about a *subset* of LilyPond for this purpose?
Werner
___
lilypond-devel mailing l
On Mon, Sep 3, 2012 at 7:20 PM, Janek Warchoł wrote:
>> Well, one simple consequence would be that one can't define music
>> functions in a document (their definition is interpretation, their use
>> is parsing). The use of Scheme would be quite constrained, as reading
>> it is parsing, evaluating
On Mon, Sep 3, 2012 at 11:46 PM, David Kastrup wrote:
> Janek Warchoł writes:
>> This sound like a Right Thing to do, but i'm not knowledgeable enough
>> to know what the results would actually be. Examples appreciated
>> (hopefully some examples will show in other discussions).
>
> Well, one si
Janek Warchoł writes:
> On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys wrote:
>> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
>> creating a syntax that strictly separates parsing and interpretation.
>> This implies not only rethinking a lot of syntax, but also it means
>>
On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys wrote:
> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
> creating a syntax that strictly separates parsing and interpretation.
> This implies not only rethinking a lot of syntax, but also it means
> letting go of some of the fle
>> The real question is whether is a need to do things like
>>
>> ligatures = { \[ s1 \] \[ s1 \] }
>> \new Voice << \melody \ligatures >>
>>
>> you'd have to ask jurgen reuter who wrote basically all the ancient
>> notation support.
>
> It would work to do
>
> ligatures = { s1\[ s1\]\[ <
Han-Wen Nienhuys writes:
> On Mon, Sep 3, 2012 at 9:03 AM, David Kastrup wrote:
>> Graham Percival writes:
>>
>>> On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
creating a syntax that strictly separat
On Mon, Sep 3, 2012 at 9:03 AM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
>>> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
>>> creating a syntax that strictly separates parsing and interpretation.
>>>
Graham Percival writes:
> On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
>> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
>> creating a syntax that strictly separates parsing and interpretation.
>> This implies not only rethinking a lot of syntax, but also
On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
> creating a syntax that strictly separates parsing and interpretation.
> This implies not only rethinking a lot of syntax, but also it means
> letting go of some o
Han-Wen Nienhuys writes:
> On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen wrote:
>> David Kastrup writes:
>>
Maybe the time has finally come to drop convert-ly and implement and
fully supported conversions using LilyPond on music stream level.
>>>
>>> You still need a parser of the
On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen wrote:
> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front en
Keith OHara writes:
> Janek Warchoł gmail.com> writes:
>
>> On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup gnu.org> wrote:
>> > Graham Percival percival-music.ca> writes:
>> >> So far I don't feel that the discussion has been very fruitful.
>> >
>> > And it will not be fruitful in the near futu
Janek Warchoł gmail.com> writes:
> On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup gnu.org> wrote:
> > Graham Percival percival-music.ca> writes:
> >> So far I don't feel that the discussion has been very fruitful.
> >
> > And it will not be fruitful in the near future. One reason is that I am
>
On Sun, Sep 02, 2012 at 12:58:47AM +0200, Janek Warchoł wrote:
> For what it's worth, i'm ok with this discussion (and similar ones)
> happening on devel, as long as we won't loose track of concrete
> proposals (when they will appear, ofc.).
I think the direction we're moving in is to have unstruc
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>> What issues were raised?
>
> Janek and Graham raised the `what is a music function / let's make
> everything postfix' issue.
That's rather vague as an issue description. Sort of the "What is a
preposition / let's make everything a case" iss
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>>> Maybe the time has finally come to drop convert-ly and implement and
>>> fully supported conversions using LilyPond on music stream level.
>>
>> You still need a parser of the appropriate version at the front end.
>
> We have perfectly fine
David Kastrup writes:
>> Maybe the time has finally come to drop convert-ly and implement and
>> fully supported conversions using LilyPond on music stream level.
>
> You still need a parser of the appropriate version at the front end.
We have perfectly fine ly parsers of each available version a
David Kastrup writes:
> What issues were raised?
Janek and Graham raised the `what is a music function / let's make
everything postfix' issue. Han-Wen raised the issue of [nameless]
optional arguments.
>> instead of
>>
>> \relative { a \parenthesize b c }
>>
>> we could have something* like
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>> Using LilyPond for reading LilyPond files (as opposed to parsers written
>> in Python) has the advantage of being rather thorough, and the
>> disadvantage to be tied into a single version (not all that helpful if
>> you want to write somethin
Jan Nieuwenhuizen writes:
> Han-Wen Nienhuys writes:
>
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group function parameters.
>
> If we start doing this, that would solve
Han-Wen Nienhuys writes:
> I have become convinced that optional, unnamed arguments are not a
> happy design decision, in any language. In Lily it's particularly
> problematic, since we don't group function parameters.
If we start doing this, that would solve the several of the issues
raised. It
David Kastrup writes:
> Using LilyPond for reading LilyPond files (as opposed to parsers written
> in Python) has the advantage of being rather thorough, and the
> disadvantage to be tied into a single version (not all that helpful if
> you want to write something like convert-ly).
Maybe the time
On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup wrote:
> Graham Percival writes:
>> So far I don't feel that the discussion has been very fruitful.
>
> And it will not be fruitful in the near future. One reason is that I am
> basically the only one seriously working on the parser right now, and I
Han-Wen Nienhuys gmail.com> writes:
> I am actually supportive of allowing digits in identifiers, it has
> irked me for years that we could not get it to work. I vaguely recall
> you implemented this in 2.16 already, but I guess I am mistaken?
>
If we abuse the syntax, we can write
"vn1M4m34
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>
>> You can also argue that people that know what a duration is, and how to
>> use it will be better served by writing Scheme directly. Because a
>> duration is complex enough in Scheme already.
>
> The whole idea
Han-Wen Nienhuys writes:
> it seems that we are still inventing our syntactically complex
> programming language, which ironically is implemented on top of GUILE
> Scheme.
There is no irony involved. Scheme's syntax is computer-friendly,
LilyPond's syntax is user-friendly. If they did not serv
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>
>>> Vectors don't make sense unless you give a mechanism to map/iterate
>>> over them, ie something along the lines of
>>>
>>> (make-parallel-music (vector->list
>>> (map (lambda (x) (add-new-context "Staff" x))
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
>>
>>> It is reasonably easy to state "this will have to go". However, I have
>>> not so far attempted a replacement since I am still fuzzy on
>>> assignmen
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>> Vectors don't make sense unless you give a mechanism to map/iterate
>> over them, ie something along the lines of
>>
>> (make-parallel-music (vector->list
>> (map (lambda (x) (add-new-context "Staff" x)) violin)))
>
> It would be easy eno
Am 31.08.2012 19:19, schrieb Jan Nieuwenhuizen:
Han-Wen Nienhuys writes:
Manual writers: can we make up our minds here? I've always been
against frivolous syntax for shortcuts (one example in particular is
the "q" for repetition). Why do we put in "q" for users to save some
keystrokes, and at
Graham Percival writes:
> 1. declare the 2.16.0 syntax absolutely frozen (possibly with the
> exception of property names and scheme). Reject absolutely all
> patches to lily/parser.yy
That does not make sense as long as we don't have a reasonably coherent
starting point for freezing.
> 2. hav
On Sat, Sep 1, 2012 at 12:27 PM, David Kastrup wrote:
>>> And you don't want to have him remember different function names for
>>> each argument list variation.
>>
>> Here is another premise that hasn't been agreed on explicitly. I would
>> nowadays hold that it is actually better to have differen
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 5:37 AM, David Kastrup wrote:
>
>> As one example for an analogous use of optional arguments, consider
>>
>> \tweak Accidental #'color #red cis4
>>
>> \tweak has always been a music function. Being able to use a syntax
>> fairly analogous to tha
On Sat, Sep 01, 2012 at 12:07:07PM -0300, Han-Wen Nienhuys wrote:
> This is also the danger of having broad discussions over syntax.
...
> on the basis of how "intuitive" it looks. See also
> http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
Yes, that was the whole reason why I wanted to
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
>
>> It is reasonably easy to state "this will have to go". However, I have
>> not so far attempted a replacement since I am still fuzzy on
>> assignments. Basically I want to have the equivalent of procedures with
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys wrote:
>
\tempo \markup{ Presto } 4. = 172 ~ 188
c1 c
}
>>>
>>> While this might be a mess for the parser to sort out it is perfectly
>>> understandable for a musician trying to write his/her music.
>
>
On Sat, Sep 1, 2012 at 5:37 AM, David Kastrup wrote:
>>> I had to let this sink in for a bit, since I had completely missed
>>> that a patch doing optional music arguments had went in. Had I noticed
>>> in time, I probably would have complained (and we might have ended up
>>> in a flamewar).
>>
>
On Sat, Sep 1, 2012 at 8:11 AM, Graham Percival
wrote:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group
On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys wrote:
>>> \tempo \markup{ Presto } 4. = 172 ~ 188
>>> c1 c
>>> }
>>
>> While this might be a mess for the parser to sort out it is perfectly
>> understandable for a musician trying to write his/her music.
This is also the danger of having broa
On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>>> I have become convinced that optional, unnamed arguments are not a
>>> happy design decision, in any language. In Lily it's particularly
>>> pr
Han-Wen Nienhuys writes:
> I think "a musician" is red herring word. There are many people that
> think that Lily is too complex for "musicians" already, and many
> others (including me) that think that musicians are smart people and
> can learn rules, especially if they are simple and consistent
On Sat, Sep 1, 2012 at 8:57 AM, Trevor Daniels wrote:
>
> Graham Percival wrote Saturday, September 01, 2012 12:11 PM
>
>> I agree; it's a mess. Let's examine David's most hated example:
>>
>> \version "2.15.0"
>> {
>> \tempo 4 = 60
>> c1 c
>> \tempo 4. = 60 ~ 72
>> c1 c
>> \tempo "Andante"
Graham Percival writes:
> On Sat, Sep 01, 2012 at 01:27:23PM +0200, David Kastrup wrote:
>> 172 ~ 188 is an abomination anyway. It would be reasonably
>> straightforward to accept a pair here, like #(172 . 188) or
>> 172/188 which is equivalent.
>
> Straightforward from a programming perspective
Graham Percival wrote Saturday, September 01, 2012 12:11 PM
> I agree; it's a mess. Let's examine David's most hated example:
>
> \version "2.15.0"
> {
> \tempo 4 = 60
> c1 c
> \tempo 4. = 60 ~ 72
> c1 c
> \tempo "Andante"
> c1 c
> \tempo "Allegro" 4 = 120
> c1 c
> \tempo "Allegro" 4 =
On Sat, Sep 01, 2012 at 01:27:23PM +0200, David Kastrup wrote:
> 172 ~ 188 is an abomination anyway. It would be reasonably
> straightforward to accept a pair here, like #(172 . 188) or
> 172/188 which is equivalent.
Straightforward from a programming perspective, but as far as
printed music is c
Graham Percival writes:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group function parameters.
>
> I ag
On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
> I have become convinced that optional, unnamed arguments are not a
> happy design decision, in any language. In Lily it's particularly
> problematic, since we don't group function parameters.
I agree; it's a mess. Let's examine D
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>>> Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in
>>> unreadability; these are the only two languages I know that can have
>>> functions look like statements.
>>
>> Hm? Scheme, C, C++, awk, Lua...
>
> C
David Kastrup writes:
>> Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in
>> unreadability; these are the only two languages I know that can have
>> functions look like statements.
>
> Hm? Scheme, C, C++, awk, Lua...
C Perl Ly
postfix: fo
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup wrote:
Is there a complete proposal of what is on the drawing board? Barring
that, is there a list of (perceived) problems in the current
syntax/parser?
>>>
>>> The possible value
Han-Wen Nienhuys writes:
> On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup wrote:
>>> Is there a complete proposal of what is on the drawing board? Barring
>>> that, is there a list of (perceived) problems in the current
>>> syntax/parser?
>>
>> The possible values for music following a skipped o
On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup wrote:
>> Is there a complete proposal of what is on the drawing board? Barring
>> that, is there a list of (perceived) problems in the current
>> syntax/parser?
>
> The possible values for music following a skipped optional argument are
> constrained
Jan Nieuwenhuizen writes:
> Han-Wen Nienhuys writes:
>
>> Yes, I noticed that - it would be good to make all functions operating
>> on arguments be verbs; similarly, \times could be renamed to something
>> more verby.
>
> Guess what the current proposal is, I think I heard \tuplet (ugh).
>
>>> Wo
Graham Percival writes:
> The basic question is "is it too late to change anything, and can
> we mitigate that pain?". I think it's not too late, particularly
> if the change can be done automatically, and particularly if we
> promise support for the new syntax. Alternatively, if it really
> _i
Han-Wen Nienhuys writes:
> On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
> wrote:
>> That's why I wanted to make sure that proposals are in "good
>> shape" before discussing them on the main list. But there seems
>> to be general consensus that we want to discuss all proposals here
>> anyway
On Fri, Aug 31, 2012 at 01:20:14PM -0300, Han-Wen Nienhuys wrote:
> On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
> wrote:
> Automated readers - I am not very convinced about this. Reading .ly
> correctly implies having a complete scheme interpreter at your
> disposal. Or are we limiting ours
Han-Wen Nienhuys writes:
> Yes, I noticed that - it would be good to make all functions operating
> on arguments be verbs; similarly, \times could be renamed to something
> more verby.
Guess what the current proposal is, I think I heard \tuplet (ugh).
>> Wouldn't it be helpful if from the syntax
On Fri, Aug 31, 2012 at 2:19 PM, Jan Nieuwenhuizen wrote:
> Wouldn't it be helpful if from the syntax one could tell functions from
> postfix operators simple statements?
Yes, it would if we could start from scratch. Sadly, we are not.
We don't have the distinction, because we did not start from
On Fri, Aug 31, 2012 at 2:19 PM, Jan Nieuwenhuizen wrote:
>> Manual writers: can we make up our minds here? I've always been
>> against frivolous syntax for shortcuts (one example in particular is
>> the "q" for repetition). Why do we put in "q" for users to save some
>> keystrokes, and at the t
Han-Wen Nienhuys writes:
> Manual writers: can we make up our minds here? I've always been
> against frivolous syntax for shortcuts (one example in particular is
> the "q" for repetition). Why do we put in "q" for users to save some
> keystrokes, and at the time propose to require a mostly redun
On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
wrote:
> That's why I wanted to make sure that proposals are in "good
> shape" before discussing them on the main list. But there seems
> to be general consensus that we want to discuss all proposals here
> anyway, so I can roll with that.
>
>> For
Han-Wen Nienhuys writes:
> On Wed, Aug 29, 2012 at 10:15 AM, David Kastrup wrote:
>>> For example, one idea was to use postfix notation for (almost)
>>> everything. David pointed out that this would wreck havok on music
>>> functions, and I had to admit that I have no clue what a music
>>> func
On Thu, Aug 30, 2012 at 08:50:35AM -0300, Han-Wen Nienhuys wrote:
> It would be helpful to have a comprehensive overview of what would be changed.
That's why I wanted to make sure that proposals are in "good
shape" before discussing them on the main list. But there seems
to be general consensus t
On Wed, Aug 29, 2012 at 10:15 AM, David Kastrup wrote:
>> For example, one idea was to use postfix notation for (almost)
>> everything. David pointed out that this would wreck havok on music
>> functions, and I had to admit that I have no clue what a music
>> function is. I mean, I know that the
On Thu, Aug 30, 2012 at 1:35 PM, Han-Wen Nienhuys wrote:
> I personally am not inclined to subscribe to yet another list. Also,
> finding the discussion later on will be easier if it happens on
> lilypond-devel.
That's a good point. This actually reminds me of all the situations
when i was looki
On Wed, Aug 29, 2012 at 10:31 AM, Graham Percival
wrote:
> On Wed, Aug 29, 2012 at 03:15:08PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Thoughts? opinions? alternatives that I haven't considered?
>> > These discussions are going to produce a *lot* of emails.
>>
>> And if th
Janek Warchoł writes:
> On Wed, Aug 29, 2012 at 3:15 PM, David Kastrup wrote:
>> Graham Percival writes:
>>
>>> At the Waltrop meeting, Janek proposed a number of interesting but
>>> potentially disruptive changes to the lilypond syntax. On a
>>> personal note, I really like most of them, but
On Wed, Aug 29, 2012 at 3:15 PM, David Kastrup wrote:
> Graham Percival writes:
>
>> At the Waltrop meeting, Janek proposed a number of interesting but
>> potentially disruptive changes to the lilypond syntax. On a
>> personal note, I really like most of them, but it will take a good
>> chunk of
On Wed, Aug 29, 2012 at 03:15:08PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Thoughts? opinions? alternatives that I haven't considered?
> > These discussions are going to produce a *lot* of emails.
>
> And if they come to conclusions, they are going to produce effects on
> e
Graham Percival writes:
> At the Waltrop meeting, Janek proposed a number of interesting but
> potentially disruptive changes to the lilypond syntax. On a
> personal note, I really like most of them, but it will take a good
> chunk of work before they're ready to discuss on the main
> developmen
On Wed, Aug 29, 2012 at 2:10 PM, Graham Percival
wrote:
> At the Waltrop meeting, Janek proposed a number of interesting but
> potentially disruptive changes to the lilypond syntax. On a
> personal note, I really like most of them, [...]
I'm very happy to hear this :)
> I'm not enthusiastic abo
At the Waltrop meeting, Janek proposed a number of interesting but
potentially disruptive changes to the lilypond syntax. On a
personal note, I really like most of them, but it will take a good
chunk of work before they're ready to discuss on the main
development list.
Further complicating issues
88 matches
Mail list logo
