On Mon, Oct 29, 2012 at 2:29 PM, David Kastrup wrote:
> Marc Hohl writes:
>> I trust you (almost) completely in terms of developing lilypond along
>> a way that is most fruitful for internal consistency and further external
>> enhancements. It is sometimes just hard to see your goals by just
>> t
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
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
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
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.
http://codereview.appspot.com/6493072/
___
lilypond-devel mailing list
lilypond-devel@
David Kastrup wrote Wednesday, September 05, 2012 4:12 PM
> Here is another "cure" for that request: if we can get used to writing
> "violin1" = { ... }
> for defining a name with numbers in it, it would be an obvious syntax
> extension to allow its invocation as
>
> \"violin1"
As this wouldn't
Werner LEMBERG writes:
>> Here is another "cure" for that request: if we can get used to
>> writing
>>
>> "violin1" = { ... }
>>
>> for defining a name with numbers in it, it would be an obvious
>> syntax extension to allow its invocation as
>>
>> \"violin1"
>
> Actually, I think this is quit
> Here is another "cure" for that request: if we can get used to
> writing
>
> "violin1" = { ... }
>
> for defining a name with numbers in it, it would be an obvious
> syntax extension to allow its invocation as
>
> \"violin1"
Actually, I think this is quite nice.
> A somewhat non-obvious di
Bernard Hurley writes:
> On Mon, Sep 03, 2012 at 08:07:07PM +, d...@gnu.org wrote:
>>
>> flex documentation is pretty clear about backing up being very
>> expensive. I don't remember whether it was only expensive when it
>> happens, or whether the expense was more or less a fixed cost. Howe
On Wed, Sep 5, 2012 at 11:51 AM, wrote:
> If it had been up to me, "my" Schemy-dashes and underscores would have
> gone where the sun don't shine. But while trying to create some
> more-or-less consistent syntax according to more-or-less simple rules, I
> try not to break all too many existing u
On 2012/09/05 09:26:12, Keith wrote:
Agreed,
but I'll still pout a couple more times that you get your
Schemy-dashes and
underscores but I still have to refer to the motif from measure
tousend_sechshundert_siebzig
_I_ get my Schemy-dashes? I was _not_, I repeat, _not_ the person who
invente
On Wed, 05 Sep 2012 00:50:27 -0700, wrote:
On 2012/09/05 06:59:16, Keith wrote:
It costs a lot of programmer time to make the extra rules to save that
0.2%,
Not really.
But, but... flex documentation is pretty clear about [getting rid of] backing
up being very expensive :
"Getting rid of
On 2012/09/05 06:59:16, Keith wrote:
While we are thinking about this, I suggest we remove (later) the rule
forbidding backing-up states in the scanner. It made only a 0.2% in
the
worst-case scenario I could think of.
The rule had been violated, giving us the slightly slower scanner, for
a
While we are thinking about this, I suggest we remove (later) the rule
forbidding backing-up states in the scanner. It made only a 0.2% in the
worst-case scenario I could think of.
The rule had been violated, giving us the slightly slower scanner, for
about ten years (I estimate) prior to the wa
On 2012/09/03 20:07:07, dak wrote:
flex documentation is pretty clear about backing up being
very expensive.
My copy is less emphatic about this. Let's set the percussion parts for
the "New World" symphony! Here LilyPond has to read all the notes for
every part in the orchestra, to generate c
On Mon, Sep 03, 2012 at 08:07:07PM +, d...@gnu.org wrote:
>
> flex documentation is pretty clear about backing up being very
> expensive. I don't remember whether it was only expensive when it
> happens, or whether the expense was more or less a fixed cost. However,
> things like a4 are not a
On 2012/09/03 18:08:23, Keith wrote:
The version "digits, but not at the end" lets us read
vn2_meas345ff = \relative c' cis1
by depending on the ability of the scanner to back up.
The input
ceses128_3ap
is a single word, but upon finding the \ in
ceses128_3\p
the scanner has to back u
The version "digits, but not at the end" lets us read
vn2_meas345ff = \relative c' cis1
by depending on the ability of the scanner to back up.
The input
ceses128_3ap
is a single word, but upon finding the \ in
ceses128_3\p
the scanner has to back up to split as
ceses 128 _ 3 \p
http://c
Digits?
As you usually have to define them using quotes, it would be consequent if
you need quotes to recall them, e.g. \\"u_x-32" (because '\"' is allready
special).
ArnoldTheresius
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Allow-digits-
All in all, this creates so many loose ends and problems of the kind I
have been working to get tied up that I can basically start from scratch
with lexer/parser work. I am very strongly opposed to this, and it is
easy to come up with examples that fail for inexplicable reasons because
of the int
On 2012/09/02 11:52:46, dak wrote:
It looks like some _severe_ doctoring around with regard to notenames
was done
to make regtests pass without an actual understanding of the failure
modes,
introducing some half-baked in-between modes that don't have a purpose
apart
from papering over the
Reviewers: dak,
http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly
File input/regression/page-spacing-nonstaff-lines-independent.ly (left):
http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independe
All in all, a large step backwards for making the lexer behave
predictably across modes regarding word and command syntax, connected
with several timing problems when parsing.
It looks like some _severe_ doctoring around with regard to notenames
was done to make regtests pass without an actual un
25 matches
Mail list logo
