Re: Naming _another_ lacking puzzle piece

On Tue, Oct 16, 2012 at 10:21 AM, David Kastrup wrote: > Joe Neeman writes: > > > But now that we are giving a hook into push, I think that the > > non-pushing default of override will cause problems. > > I consider it utterly ludicrous that the mere availability of \temporary > will magically c

Re: Naming _another_ lacking puzzle piece

Joe Neeman writes: > But now that we are giving a hook into push, I think that the > non-pushing default of override will cause problems. I consider it utterly ludicrous that the mere availability of \temporary will magically cause problems with the existing usage of \override, but there is no p

Re: Naming _another_ lacking puzzle piece

On Sun, Oct 14, 2012 at 1:26 PM, David Kastrup wrote: > Joe Neeman writes: > > > On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup wrote: > > > > You are viewing this from the "stack" angle. But that is a complex > > view already. The actual user view is > > > > A. > > \override se

Re: Naming _another_ lacking puzzle piece

Joe Neeman writes: > On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup wrote: > > You are viewing this from the "stack" angle. But that is a complex > view already. The actual user view is > > A. > \override sets a context-specific property value > \revert removes a context

Re: Naming _another_ lacking puzzle piece

On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup wrote: > "Trevor Daniels" writes: > > > A. > > \override does a pop/push > > \revert does a pop > > \temporary\override does a push. > > > > so \temporary\override and \revert are a matching pair. > > More importantly: on an empty stack, any number

Re: Naming _another_ lacking puzzle piece

On Sun, Oct 14, 2012 at 7:56 PM, Phil Holmes wrote: > >> /oneMoment (equivalent to /once, but perhaps a more clear name) modifies a >> property in the current context for one musical moment. Once the musical >> moment has passed, the changes introduced by the /oneMoment evaporate. We >> could ap

Re: possibility of merging \override and \set (was: Naming, _another_ lacking puzzle piece)

On 10/14/2012 07:36 PM, lilypond-devel-requ...@gnu.org wrote: Please, can we get away from thinking in terms of implementation details and instead think of the use cases: 1) Just set a property (grob or context property) to a certain value, don't worry about previous values 2) Set a property to

Re: Naming _another_ lacking puzzle piece

- Original Message - From: "Carl Sorensen" To: "David Kastrup" ; "Trevor Daniels" Cc: Sent: Sunday, October 14, 2012 3:28 PM Subject: Re: Naming _another_ lacking puzzle piece Perhaps now David has put together enough infrastructure that it is time to

Re: possibility of merging \override and \set (was: Naming _another_ lacking puzzle piece)

Sorry, Reinhold - forgot to send to all.. On Sun, Oct 14, 2012 at 6:18 PM, Reinhold Kainhofer wrote: > On 14/10/2012 17:46, Janek Warchoł wrote: >> As for (2), i see that there are three operations that can be >> performed on stack: push, pop and clear. > > Please, can we get away from thinking i

Re: Naming _another_ lacking puzzle piece

On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup wrote: > > You are viewing this from the "stack" angle. But that is a complex > view already. The actual user view is > > A. > \override sets a context-specific property value > \revert removes a context-specific property value > This works reliabl

Re: possibility of merging \override and \set (was: Naming _another_ lacking puzzle piece)

On 14/10/2012 17:46, Janek Warchoł wrote: > As for (2), i see that there are three operations that can be > performed on stack: push, pop and clear. Please, can we get away from thinking in terms of implementation details and instead think of the use cases: 1) Just set a property (grob or contex

Re: Naming _another_ lacking puzzle piece

Carl Sorensen writes: > Two years ago, David and I had a discussion about the existence of /tweak, > /set, and /override. David pointed out the confusing nature of the > different ways of changing properties, and the difficulty of explaining > this to the user. > >

possibility of merging \override and \set (was: Naming _another_ lacking puzzle piece)

Hi, On Sun, Oct 14, 2012 at 4:28 PM, Carl Sorensen wrote: > Two years ago, David and I had a discussion about the existence of /tweak, > /set, and /override. > > > > Perhaps now David has put together enough infrastructure t

Re: Naming _another_ lacking puzzle piece

Two years ago, David and I had a discussion about the existence of /tweak, /set, and /override. David pointed out the confusing nature of the different ways of changing properties, and the difficulty of explaining this to the user.

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > A. > \override does a pop/push > \revert does a pop > \temporary\override does a push. > > so \temporary\override and \revert are a matching pair. More importantly: on an empty stack, any number of \override followed by \revert are a matching "pair". > B > \override

Re: Naming _another_ lacking puzzle piece

David Kastrup wrote Sunday, October 14, 2012 10:56 AM > "Trevor Daniels" writes: > >> David Kastrup wrote Sunday, October 14, 2012 9:21 AM >> >> >>> "Trevor Daniels" writes: >>> I would be happier with this change. Why not just change the action of \override to be push alone? As i

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > James, you wrote Sunday, October 14, 2012 12:05 AM > >> I have a patch coming that is trying to at least document \single >> \hide and \omit. > > Fine - \hide and \omit are quite straightforward. > >> i also have started to use \single to take the opportunity to bette

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > David Kastrup wrote Sunday, October 14, 2012 9:21 AM > > >> "Trevor Daniels" writes: >> >>> I would be happier with this change. Why not just change the action >>> of \override to be push alone? As its current implementation pretty >>> well ensures all the stacks are

Re: Naming _another_ lacking puzzle piece

James, you wrote Sunday, October 14, 2012 12:05 AM > I have a patch coming that is trying to at least document \single > \hide and \omit. Fine - \hide and \omit are quite straightforward. > i also have started to use \single to take the opportunity to better > organize NR 5.3. Hhm. This sect

Re: Naming _another_ lacking puzzle piece

David Kastrup wrote Sunday, October 14, 2012 9:21 AM > "Trevor Daniels" writes: > >> Joe Neeman wrote Sunday, October 14, 2012 12:14 AM >>> >>> In other words, we have a "pop-push" and a "pop". In the context of >>> Reinhold's email, you were suggesting (although perhaps not seriously) >>> add

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > Joe Neeman wrote Sunday, October 14, 2012 12:14 AM >> >> On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup wrote: >> >>> \override overwrites the last definition >>> \revert throws it away/reestablishes the previous if not overwritten. >> >> In other words, we have a

Re: Naming _another_ lacking puzzle piece

Joe Neeman writes: > In other words, we have a "pop-push" and a "pop". In the context of > Reinhold's email, you were suggesting (although perhaps not seriously) > adding a "push". Now, I'm happy to have "push" and "pop," but I think > "pop-push" is a bad interface for a stack. It is not intende

Re: Naming _another_ lacking puzzle piece

Joe Neeman wrote Sunday, October 14, 2012 12:14 AM > > On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup wrote: > >> \override overwrites the last definition >> \revert throws it away/reestablishes the previous if not overwritten. > > In other words, we have a "pop-push" and a "pop". In the cont

Re: Naming _another_ lacking puzzle piece

Reinhold Kainhofer writes: > On 2012-10-13 23:29, David Kastrup wrote: >>> >If you are referring to Werner's and Reinhold's comments, I think you >>> >may not be reading them as the authors intended. In particular, I >>> >believe that Reinhold was merely objecting to the names "push" and >>> >"po

Re: Naming _another_ lacking puzzle piece

Joe Neeman writes: > Ok, that's a good point. It still seems a little strange to me, > though, that > \undo\override Something #'color = #red > will actually reverse the effect of > \override Something #'color = #green There is not really a point in using \undo on single overrides; just use \rev

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup wrote: > Joe Neeman writes: > > > On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup wrote: > > > > > > > > > > No. I am just pissed at the people clamoring for more ignorance, > > more > > > > bugs, and less control. > > > > If you are ref

Re: Naming _another_ lacking puzzle piece

Trevor On 13 October 2012 23:56, Trevor Daniels wrote: > > David Kastrup wrote Saturday, October 13, 2012 10:29 PM > > I wrote > >>>Plus \once and now \temporary. I agree this menagerie is going to >>>be far more confusing to users than the occasional unexpected result >>>after calli

Re: Naming _another_ lacking puzzle piece

> I completely agree that we need a function that changes a property > in a non-destructive way. Me too, in case there was ever a doubt about this. > If we were to completely re-design the lilypond language, I would > suggest \override, \revert and \clear (as push, pop and clear > stack), but th

Re: Naming _another_ lacking puzzle piece

David Kastrup wrote Saturday, October 13, 2012 10:29 PM I wrote >>Plus \once and now \temporary. I agree this menagerie is going to >>be far more confusing to users than the occasional unexpected result >>after calling \crossStaff or \harmonicByFret - which no one has ever >>not

Re: Naming _another_ lacking puzzle piece

On 2012-10-13 22:48, Joe Neeman wrote: If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names "push" and "pop" as being opaque to non-programmers, Exactly. Th

Re: Naming _another_ lacking puzzle piece

On 2012-10-13 23:29, David Kastrup wrote: >If you are referring to Werner's and Reinhold's comments, I think you >may not be reading them as the authors intended. In particular, I >believe that Reinhold was merely objecting to the names "push" and >"pop" as being opaque to non-programmers,

Re: Naming _another_ lacking puzzle piece

Joe Neeman writes: > On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup wrote: > > > > > No. I am just pissed at the people clamoring for more ignorance, > more > > bugs, and less control. > > If you are referring to Werner's and Reinhold's comments, I think you > may not

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup wrote: > > No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I belie

Re: Naming _another_ lacking puzzle piece

Janek Warchoł writes: > On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup wrote: >> Janek Warchoł writes: >>> would it hurt us really much to have multiple overrides >>> "accumulate cruft"? I suppose that in real-life situation there won't >>> be that much cruft accumulated - but i might be compl

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup wrote: > Janek Warchoł writes: >> would it hurt us really much to have multiple overrides >> "accumulate cruft"? I suppose that in real-life situation there won't >> be that much cruft accumulated - but i might be completely wrong. > > \voiceTwo \vo

RE: Naming _another_ lacking puzzle piece

Keith OHara writes: > > I looked for a case in my scores where I wanted a stack, where I wanted to > temporarily override something that I had already overridden, and then put > back my first override. I did not find any. I love having the ability to write a music function that will set desire

Re: Naming _another_ lacking puzzle piece

Keith OHara writes: > David Kastrup gnu.org> writes: >> >> "Trevor Daniels" treda.co.uk> writes: >> >> > I don't understand. Are you suggesting we should not document >> > these new functions? If so, what is the set of commands which >> > should be documented? >> >> I am not suggesting tha

Re: Naming _another_ lacking puzzle piece

David Kastrup gnu.org> writes: > > "Trevor Daniels" treda.co.uk> writes: > > > I don't understand. Are you suggesting we should not document > > these new functions? If so, what is the set of commands which > > should be documented? > > I am not suggesting that. But there is public consent

Re: Naming _another_ lacking puzzle piece

On 12-10-13 10:23 AM, David Kastrup wrote: "Trevor Daniels" writes: David, you wrote Saturday, October 13, 2012 4:26 PM "Trevor Daniels" writes: Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after c

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > David, you wrote Saturday, October 13, 2012 4:26 PM > > >> "Trevor Daniels" writes: >> >>> Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM >>> As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-program

Re: Naming _another_ lacking puzzle piece

David, you wrote Saturday, October 13, 2012 4:26 PM > "Trevor Daniels" writes: > >> Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM >> >>> As for command names, i'd prefer not to name them \pop and \push as >>> this doesn't say anything to non-programmers. To put it differently: >>> i'

Re: Naming _another_ lacking puzzle piece

David Kastrup writes: > It would appear that this behavior was implemented in lily/parser.yy with > > commit 39dd20959c8b3a143cfe41138a5c62749da54079 > Author: Han-Wen Nienhuys > Date: Mon Oct 17 00:04:45 2005 + > > * input/regression/override-nest.ly: new file. > > * python/c

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM > >> As for command names, i'd prefer not to name them \pop and \push as >> this doesn't say anything to non-programmers. To put it differently: >> i'd prefer to solve this problem in a way that doesn't require >>

Re: Naming _another_ lacking puzzle piece

Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM > As for command names, i'd prefer not to name them \pop and \push as > this doesn't say anything to non-programmers. To put it differently: > i'd prefer to solve this problem in a way that doesn't require > *creating new push and pop comman

Re: Naming _another_ lacking puzzle piece

Janek Warchoł writes: > On Sat, Oct 13, 2012 at 2:01 AM, David Kastrup wrote: >> There is a problem with that: in terms of stack operations, \override >> and \revert are not opposing pairs: \override is pop+push (so that >> multiple overrides in a row don't accrue cruft), \revert is pop. So the

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 2:01 AM, David Kastrup wrote: > There is a problem with that: in terms of stack operations, \override > and \revert are not opposing pairs: \override is pop+push (so that > multiple overrides in a row don't accrue cruft), \revert is pop. So the > net effect of this sequenc

Re: Naming _another_ lacking puzzle piece

David Nalesnik writes: > On Sat, Oct 13, 2012 at 8:29 AM, David Kastrup wrote: > > [...] >> >> \override Accidental color = #green >> \override Accidental color = #red >> \push\override Accidental color = #blue >> [...] >> \revert Accidental color >> >> or, if you prefer >> \override Accidental

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 8:29 AM, David Kastrup wrote: [...] > > \override Accidental color = #green > \override Accidental color = #red > \push\override Accidental color = #blue > [...] > \revert Accidental color > > or, if you prefer > \override Accidental color = #green > \override Accidental c

Re: Naming _another_ lacking puzzle piece

David Nalesnik writes: > On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup wrote: >> David Nalesnik writes: > >>> >>> Buildup of unwanted data or no, it would be useful to be able to write >>> something like >>> >>> \toLast Accidental #'color >>> >>> to restore the previous override >> >> But whic

Re: Naming _another_ lacking puzzle piece

David Kastrup writes: > Reinhold Kainhofer writes: > >> On 2012-10-13 09:32, Werner LEMBERG wrote:>> Maybe \push\override >> ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? >>> >>> I think that we either need a cons

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup wrote: > David Nalesnik writes: >> >> Buildup of unwanted data or no, it would be useful to be able to write >> something like >> >> \toLast Accidental #'color >> >> to restore the previous override > > But which is the "previous override" if you ha

Re: Naming _another_ lacking puzzle piece

David Nalesnik writes: > On Sat, Oct 13, 2012 at 6:39 AM, David Kastrup wrote: >> "Phil Holmes" writes: >> >>> Surely this points to the pop operation in \override as being at >>> fault? If \override was simply push, rather than pop-push then the >>> code above would seem to work as intended.

Re: Naming _another_ lacking puzzle piece

Reinhold Kainhofer writes: > On 2012-10-13 09:32, Werner LEMBERG wrote:>> Maybe \push\override > ... but this has the disadvantage that you >>> never actively see a \pop. Hm. Maybe we should rename \undo to >>> \pop then? >> >> I think that we either need a consistent use if \push and \pop, or

Re: Naming _another_ lacking puzzle piece

On Sat, Oct 13, 2012 at 6:39 AM, David Kastrup wrote: > "Phil Holmes" writes: > >> Surely this points to the pop operation in \override as being at >> fault? If \override was simply push, rather than pop-push then the >> code above would seem to work as intended. > > Sure. The idea presumably w

Re: Naming _another_ lacking puzzle piece

On 2012-10-13 09:32, Werner LEMBERG wrote:>> Maybe \push\override ... but this has the disadvantage that you >> never actively see a \pop. Hm. Maybe we should rename \undo to >> \pop then? > > I think that we either need a consistent use if \push and \pop, or we > should refrain using it. Give

Re: Naming _another_ lacking puzzle piece

David Kastrup writes: > "Phil Holmes" writes: > >> Surely this points to the pop operation in \override as being at >> fault? If \override was simply push, rather than pop-push then the >> code above would seem to work as intended. > > Sure. The idea presumably was not to have stack buildup fr

Re: Naming _another_ lacking puzzle piece

"Phil Holmes" writes: > Surely this points to the pop operation in \override as being at > fault? If \override was simply push, rather than pop-push then the > code above would seem to work as intended. Sure. The idea presumably was not to have stack buildup from things like \voiceOne c c \vo

Re: Naming _another_ lacking puzzle piece

- Original Message - From: "David Kastrup" To: "Trevor Daniels" Cc: Sent: Saturday, October 13, 2012 11:25 AM Subject: Re: Naming _another_ lacking puzzle piece "Trevor Daniels" writes: David Kastrup wrote Saturday, October 13, 2012 1:01 AM In ly

Re: Naming _another_ lacking puzzle piece

Werner LEMBERG writes: >> [...] if I write >> >> \omit Accidental >> cis dis cis dis >> \pop\omit Accidental >> >> this looks ugly and not properly matched, and it _is_ not properly >> matched. If there was a non-standard stencil set in that context >> previously, it is gone. >> >> So maybe \

Re: Naming _another_ lacking puzzle piece

> [...] if I write > > \omit Accidental > cis dis cis dis > \pop\omit Accidental > > this looks ugly and not properly matched, and it _is_ not properly > matched. If there was a non-standard stencil set in that context > previously, it is gone. > > So maybe \pop (complemented by \push) is indee

Re: Naming _another_ lacking puzzle piece

"Trevor Daniels" writes: > David Kastrup wrote Saturday, October 13, 2012 1:01 AM >> >> In ly/music-functions-init.ly I see code like the following: >> >> crossStaff = >> #(define-music-function (parser location notes) (ly:music?) >> (_i "Create cross-staff stems") >> #{ >> \override Stem #'

Re: Naming _another_ lacking puzzle piece

David Kastrup wrote Saturday, October 13, 2012 1:01 AM > > In ly/music-functions-init.ly I see code like the following: > > crossStaff = > #(define-music-function (parser location notes) (ly:music?) > (_i "Create cross-staff stems") > #{ > \override Stem #'cross-staff = #cross-staff-connect >

Re: Naming _another_ lacking puzzle piece

Werner LEMBERG writes: >>> I like the name \temporary. Is this of practical use outside of >>> music functions also? >> >> The main point is to restore to a previous state after a temporary >> override. This is of course also useful in music assigned to music >> variables. In the context of a

Re: Naming _another_ lacking puzzle piece

>> I like the name \temporary. Is this of practical use outside of >> music functions also? > > The main point is to restore to a previous state after a temporary > override. This is of course also useful in music assigned to music > variables. In the context of a larger music piece, you can, o

Re: Naming _another_ lacking puzzle piece

Werner LEMBERG writes: >> So we need something like >> >> crossStaff = >> #(define-music-function (parser location notes) (ly:music?) >> (_i "Create cross-staff stems") >> #{ >> \temporary\override Stem #'cross-staff = #cross-staff-connect >> \temporary\override Flag #'style = #'no-flag

Re: Naming _another_ lacking puzzle piece

2012/10/13 David Kastrup : > > In ly/music-functions-init.ly I see code like the following: > > crossStaff = > #(define-music-function (parser location notes) (ly:music?) > (_i "Create cross-staff stems") > #{ > \override Stem #'cross-staff = #cross-staff-connect > \override Flag #'style =

Re: Naming _another_ lacking puzzle piece

> So we need something like > > crossStaff = > #(define-music-function (parser location notes) (ly:music?) > (_i "Create cross-staff stems") > #{ > \temporary\override Stem #'cross-staff = #cross-staff-connect > \temporary\override Flag #'style = #'no-flag > $notes > \revert Stem #'cro

Naming _another_ lacking puzzle piece

In ly/music-functions-init.ly I see code like the following: crossStaff = #(define-music-function (parser location notes) (ly:music?) (_i "Create cross-staff stems") #{ \override Stem #'cross-staff = #cross-staff-connect \override Flag #'style = #'no-flag $notes \revert Stem #'cross-s