On 2012/10/30 06:05:57, dak wrote:
Actually, I would be perfectly fine with binning both \violin.1
as well as \"violin1".
That should be fine. No-one has indicated they would actually use
either of these. (But I do use "vn1mvt2" with $vn1mvt2 )
http://codereview.appspot.com/6778055/
___
On Mon, 29 Oct 2012 22:43:34 -0700, wrote:
if that is a real concern to you and not just a mock complaint,
Of course these are mock complaints; you gave me so much to mock.
This should be fine, after adding the start-condition in the scanner.
___
Actually, I would be perfectly fine with binning both \violin.1 as well
as \"violin1". I am just afraid it would be a bit like taking candy
from a baby.
But if people are fine with the prospect of waiting until \violin1,
\violin 1, \violin $(1+1) will all work, then that's likely the cleanest
so
On 2012/10/30 04:06:18, Keith wrote:
Well, David has pointed out some shortcomings, but I am not sure if
they are
practical problems.
A "practical problem" presumably is one the user can be bothered about.
I never claimed that problem class here. Users are not interested in
language design o
On 2012/10/29 10:05:30, dak wrote:
Keith's proposal would not imply that violin . $(+ 1 1) would
be the same as violin.2 and not even violin . 2 would work here.
I didn't think we wanted such things.
Nor do we want
\paper { short-indent = 3\cm }
to subtract 'indent' from 'short'. We are si
Well, David has pointed out some shortcomings, but I am not sure if they
are practical problems.
The strings in
"violin1" = c2 { "\violin1" }
must be literal strings, whereas most other places we can
build strings in Scheme. So the instrumentName setting here works, but
the corresponding var
Trevor Daniels treda.co.uk> writes:
> David Kastrup wrote Sunday, October 28, 2012 4:34 PM
>
> > http://code.google.com/p/lilypond/issues/detail?id=2934>.
> >
> > If we are going through with this one, it means that the
> > override/revert/overrideProperty syntax presented to users is
> > funda
2012/10/27 David Nalesnik :
> On Fri, Oct 26, 2012 at 6:13 PM, Thomas Morley
> wrote:
>
>>> Also: rather than simply translating the dashed-line stencil command,
>>> it might be nice to ensure that you can't get that ugly dot at the end
>>> of the line or having it end with a space.when you haven'
Am 29.10.2012 14:29, schrieb David Kastrup:
Marc Hohl writes:
Am 29.10.2012 11:05, schrieb d...@gnu.org:
[...]
I can wave around my long-term plans which would allow for just writing
\violin1 by allowing arrays of violins (I have something in a branch
right now, but without further syntax ch
Francisco Vila writes:
> 2012/10/29 David Kastrup :
>>
>> Hi, I am planning to upload the following changes
>
> I think you forgot to specify the actual changes.
git send-email chose to put them in a followup to the first mail. Sorry
for that; I'll have to check the available options more close
2012/10/29 David Kastrup :
>
> Hi, I am planning to upload the following changes
I think you forgot to specify the actual changes.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gn
Hi, I am planning to upload the following changes entry to stable/2.16
and will likely keep this setup for future releases of 2.16.x. Any
objections? Since this is not relative to master, the normal Rietveld
procedures including patchy won't likely work, so I am sending this
directly to the deve
---
Documentation/changes.tely | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index 83db4ea..b59ee7e 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -35,11 +35,28 @@ Se
David,
Have you noticed http://code.google.com/p/lilypond/issues/detail?id=2935 a
critical regression?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6742057/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (left):
http://codereview.appspot.com/6742057/diff/1/Documentation/notation/changing-defaults.itely#oldcode2192
Documentation/notation/changing-defaults
Marc Hohl writes:
> Am 29.10.2012 11:05, schrieb d...@gnu.org:
>> [...]
>>
>> I can wave around my long-term plans which would allow for just writing
>> \violin1 by allowing arrays of violins (I have something in a branch
>> right now, but without further syntax changes I am working on it is not
Am 29.10.2012 11:05, schrieb d...@gnu.org:
[...]
I can wave around my long-term plans which would allow for just writing
\violin1 by allowing arrays of violins (I have something in a branch
right now, but without further syntax changes I am working on it is not
really fitting seamlessly into Lil
On 2012/10/29 06:20:17, lemzwerg wrote:
LGTM. Nice idea. I'm not sure whether this fits into the large
picture w.r.t.
syntax normalization as envisioned by David, but at least for me it
looks
reasonable.
Well, I replied on the Google code review as well.
In a manner, this is the kind of
On 2012/10/29 08:10:53, J_lowe wrote:
Setting to patch-review as I need some more competent devs to look
over this new
re-arrangement and suggest better/alternative definitions of the
commands (if
needed).
(better) @lilypond examples will come later
This is a work in progress to then he
Werner LEMBERG writes:
>>> there is still the big convert-to-single-path-override patch
>>> pending, how available in dev/syntax and discussed in
>>> http://code.google.com/p/lilypond/issues/detail?id=2934>.
>
> Everything looks fine! Thanks for your efforts. Am I right that
>
> \override foo
Setting to patch-review as I need some more competent devs to look over
this new re-arrangement and suggest better/alternative definitions of
the commands (if needed).
(better) @lilypond examples will come later
This is a work in progress to then help get some consistency and
accuracy for the ne
Thanks Janek, done and pushed with your syntax change.
http://codereview.appspot.com/6761045/diff/6001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/6761045/diff/6001/Documentation/notation/pitches.itely#newcode1183
Documen
22 matches
Mail list logo
