Am Sunday 14 August 2011, 17:31:11 schrieb David Kastrup:
> a) a revert will only cancel the last _matching_ override, and the match
>includes the complete specified property path, _and_ the prospective
>use of \once. \revert will not cancel \once\override and vice versa.
> b) At the end o
Janek Warchoł writes:
> LGTM.
> (sorry that i don't have anything more constructive to say)
I am working on the code (in C++) right now. Since I'll be driving to
an accordionist meeting tomorrow lasting till Sunday and since I am away
work-related for the following three days, this will still t
Once again i'm reviving an old thread, but since i was involved in
discussions with David before i disappeared, i'd like to give my
feedback on this.
2011/8/14 David Kastrup :
> there are the proposed semantics. At least for the
> latter, I would want to get some sort of feedback.
>
> The semanti
"Trevor Daniels" writes:
> David Kastrup wrote Sunday, August 14, 2011 8:11 PM
>
>
>> "Trevor Daniels" writes:
>>
>>> I think we need to clarify a few things first.
>>>
>>> You wrote
>>>
I have no clear view about \set yet. It would seem to me that
\unset
should be equivalent to
David Kastrup wrote Sunday, August 14, 2011 8:11 PM
"Trevor Daniels" writes:
I think we need to clarify a few things first.
You wrote
I have no clear view about \set yet. It would seem to me that
\unset
should be equivalent to \revert, and \set should be equivalent
to
\revert+\overrid
"Trevor Daniels" writes:
> David
>
> I think we need to clarify a few things first.
>
> You wrote
>
>> The semantics can be summarized as follows:
>>
>> a) a revert will only cancel the last _matching_ override, and the
>> match
>> includes the complete specified property path, _and_ the
>> pro
David
I think we need to clarify a few things first.
You wrote
The semantics can be summarized as follows:
a) a revert will only cancel the last _matching_ override, and the
match
includes the complete specified property path, _and_ the
prospective
use of \once. \revert will not cance
Graham Percival writes:
> On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote:
>> Werner LEMBERG writes:
>>
>> > Unfortunately, I have nothing useful to say.
>>
>> Well, there is the code (obviously bound to be streamlined before
>> implementation) and there are the proposed semantic
On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote:
> Werner LEMBERG writes:
>
> > Unfortunately, I have nothing useful to say.
>
> Well, there is the code (obviously bound to be streamlined before
> implementation) and there are the proposed semantics. At least for the
> latter, I w
Werner LEMBERG writes:
>> Well David,
>>
>> I should not want to let you implement this in the current form
>> without any feedback from the developer list. [...]
>
> :-)
>
> Unfortunately, I have nothing useful to say.
Well, there is the code (obviously bound to be streamlined before
implemen
> Well David,
>
> I should not want to let you implement this in the current form
> without any feedback from the developer list. [...]
:-)
Unfortunately, I have nothing useful to say.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.
David Kastrup writes:
> I don't think that anything close to a sensible implementation can be
> significantly simpler or significantly more efficient. There are some
> things that may be nicer to do in C, and some shortcuts that may be
> taken. But as a functional sketch, this should more or le
12 matches
Mail list logo
