Eluze elu...@gmail.com writes:
Jan Nieuwenhuizen wrote
Eluze writes:
please also consider making LP fully case-insensitive
Why consider stupid ideas? While it was a misguided
thing to do with ascii, especially in the era of utf-8
case-insensivity has become an impossible can of worms.
Hi,
On Thu, Mar 21, 2013 at 11:17 PM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
virtually all grob properties are lowercase words separated with
dashes. I think we should get rid of exceptions to this rule and make
all grob properties lowercase [...]:
Hi David,
On Sun, Mar 24, 2013 at 8:15 AM, David Kastrup d...@gnu.org wrote:
Eluze elu...@gmail.com writes:
please also consider making LP fully case-insensitive
We had that discussion a few times already and the reasoning has not
changed. Upper/lowercase is not defined independently from
The axis names are #X and #Y so I am not in favor.
What about changing axis names as well?
I'm all for it.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/03/23 16:38:21, t.daniels_treda.co.uk wrote:
A 'programming error' should be issued only when an internal
inconsistency
in LilyPond's code or data structures is detected. Any such message
should
always result in a bug being reported and tracked. If the problem is
due to
suspect
Werner LEMBERG w...@gnu.org writes:
The axis names are #X and #Y so I am not in favor.
What about changing axis names as well?
I'm all for it.
Not really easy. We have in C++ macros X Y LEFT RIGHT etc, and making
them lowercase would heavily conflict with typical variable names.
Making
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
So LGTM apart from a nitpick.
Trevor
https://codereview.appspot.com/7533046/diff/15001/lily/self-alignment-interface.cc
On 2013/03/24 12:37:14, Trevor Daniels wrote:
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
I don't think your fear is unfounded: there just does not seem to be any
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
File input/regression/instrument-name-x-align.ly (right):
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly#newcode33
On 2013/03/16 20:51:05, dak wrote:
On 2013/03/16 19:19:57, lemzwerg wrote:
LGTM. The combination `\' `\n' `\(' is probably worth a comment in
the
contributors' manual.
If \( was defined, things would be so much easier: one would just put
\( in the
first column. \ newline \n( is the
LGTM bar a nit-pick with the doc-string in define-music-types.scm. Sorry
for the previous message without the draft comment attached.
Cheers, Ian
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm#newcode77
scm/define-music-types.scm:77: \n(no direction specified), and where
@code{y} is an
Suggestion for regression test doc-string.
It's a bit wordier but clearer and shows you're covering cases for other
wide accidentals on the note being fingered like half-flat etc.
Cheers, Ian
https://codereview.appspot.com/7988043/diff/2001/input/regression/fingering-column-snap-radius.ly
File
In the command index of the NR, we have an entry for DS al Fine:
http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index#lilypond-index_cp_letter-D
However, it's not mentioned at all in the manual. Should we delete the
index entry?
--
Phil Holmes
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
I don't think your fear is
I just changed the summary of the commit messages since one commit in
the middle referred to a syntax that was only provided by a commit later
in the sequence. Just a technicality.
https://codereview.appspot.com/7799048/
___
lilypond-devel mailing
Phil Holmes wrote Sunday, March 24, 2013 2:12 PM
In the command index of the NR, we have an entry for DS al Fine:
http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index#lilypond-index_cp_letter-D
However, it's not mentioned at all in the manual. Should we delete the
index
We have in C++ macros X Y LEFT RIGHT etc, and making them lowercase
would heavily conflict with typical variable names.
Yes: cpp stuff should be uppercase.
Making things different between C and Scheme here is definitely an
option.
I think the same: we already substitute `-' in Scheme with
Werner LEMBERG w...@gnu.org writes:
We have in C++ macros X Y LEFT RIGHT etc, and making them lowercase
would heavily conflict with typical variable names.
Yes: cpp stuff should be uppercase.
Making things different between C and Scheme here is definitely an
option.
I think the same: we
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
I don't think your fear is
LGTM.
https://codereview.appspot.com/7949044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I really would not want to see x and y predefined as Scheme
identifiers. It is far too likely that someone will write things
like
x = { c' d' e' f' }
and then everything relying on #x being 0 will go southwards.
Well, this can happen with everything, so I think this argument is a
bit
Werner LEMBERG w...@gnu.org writes:
I really would not want to see x and y predefined as Scheme
identifiers. It is far too likely that someone will write things
like
x = { c' d' e' f' }
and then everything relying on #x being 0 will go southwards.
Well, this can happen with
Patchset 5 warns the user when the extent is empty and stencil isn't.
However, i'm not sure if we should warn about such situations at all;
i haven't found any similar warnings in the codebase. Also, detecting
non-empty stencils with empty extents is quite unrelated to alignment
code.
Please
Maybe we can add some code to prevent the redefinition of `Scheme
constants' (in the broadest sense) like x, y, left, right, #t, #f?
I don't think we can really do this for Scheme, so we'd lose the
Scheme/LilyPond equivalence of variables.
Hmm, so what about a warning:
The variable `foo'
Am 24.03.2013 12:34, schrieb David Kastrup:
Werner LEMBERG w...@gnu.org writes:
The axis names are #X and #Y so I am not in favor.
What about changing axis names as well?
I'm all for it.
Not really easy. We have in C++ macros X Y LEFT RIGHT etc, and making
them lowercase would heavily
Werner LEMBERG w...@gnu.org writes:
Maybe we can add some code to prevent the redefinition of `Scheme
constants' (in the broadest sense) like x, y, left, right, #t, #f?
I don't think we can really do this for Scheme, so we'd lose the
Scheme/LilyPond equivalence of variables.
Hmm, so what
I really don't think we are doing people favors with trying to be as
tricky as possible about the situation. The current situation is
less that pretty, but at least it is not a trap.
Well, I don't want to actively push such a change, but consistency
(cf. the e-mail from Joram) is quite
On 24 mars 2013, at 14:59, d...@gnu.org wrote:
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
File input/regression/instrument-name-x-align.ly (right):
On 2013/03/24 19:06:49, mike7 wrote:
On 24 mars 2013, at 14:59, mailto:d...@gnu.org wrote:
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
File input/regression/instrument-name-x-align.ly (right):
Joram Berger wrote Sunday, March 24, 2013 6:03 PM
In my opinion, it is more important to make things easy for users (more
than for developers). And here: x-offset or y-extent would feel more
consistent. Such things would not be called RIGHT-align, would they?
There is the constant UP, but in
Trevor Daniels t.dani...@treda.co.uk writes:
Joram Berger wrote Sunday, March 24, 2013 6:03 PM
In my opinion, it is more important to make things easy for users (more
than for developers). And here: x-offset or y-extent would feel more
consistent. Such things would not be called RIGHT-align,
I can still learn something new about LilyPond!
Thanks David - LGTM
(with a further suggestion)
https://codereview.appspot.com/7494049/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
LGTM.
https://codereview.appspot.com/7949044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
judging mostly from description, LGTM.
https://codereview.appspot.com/7799048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Another patch i understood in first reading :)
LGTM
Janek
https://codereview.appspot.com/7988043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7836046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7686046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
File
Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
(right):
janek.lilypond wrote
However, I think when discussing case-sensitiveness, we agreed to a
following convention: LilyPond should differentiate between upper- and
lowercase, but no commands/properties/etc. should differ only by case.
so the validity of a command/property/etc. can be checked by
Code looks good, but we could get the same result with
\override Accidental #'horizontal-skylines = #'()
Incorporating the detailed outline of the accidental into the skyline of
the chord costs time, then the iterative alignment of fingering costs
more time, and if that alignment does anything
Thanks for taking the time to do this. No-one else knows enough of the
various stages of processing to bring all the pieces together.
It looks like you try to use a common UP/DOWN direction for the portions
of a broken slur, and the image you posted to the bug-tracker showed a
common direction
42 matches
Mail list logo
