https://codereview.appspot.com/7094044/diff/11001/lily/tuplet-iterator.cc
File lily/tuplet-iterator.cc (right):
https://codereview.appspot.com/7094044/diff/11001/lily/tuplet-iterator.cc#newcode139
lily/tuplet-iterator.cc:139: }
lgtm
https://codereview.appspot.com/7094044/diff/11001/ly/music-fun
Congratulations on finding the cause of the problem, through the maze of
objects implementing MIDI output.
https://codereview.appspot.com/7108043/diff/1/input/regression/midi-grace-after-tie.ly
File input/regression/midi-grace-after-tie.ly (right):
https://codereview.appspot.com/7108043/diff/1/
https://codereview.appspot.com/7101045/diff/5001/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):
https://codereview.appspot.com/7101045/diff/5001/scm/define-context-properties.scm#newcode310
scm/define-context-properties.scm:310:
(horizontallyStaggerDifferentVoi
On 13 janv. 2013, at 12:35, Phil Holmes wrote:
> I've just whiled away a happy few minutes looking at the regtests. There are
> quite a number of changes, I think mostly based on Mike's latest horizontal
> skylining.
'tis true.
> There are some that concern me in particular:
>
> finger-
Reitveld -> Rietveld
https://codereview.appspot.com/7101048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Il 14/01/2013 20:32, David Kastrup ha scritto:
Redundancy of contributors, or redundancy in CG to make things much
>easier to find?
Redundancy of contributions. We currently have "one person does the
translation once and nobody including himself looks at it ever after".
I've had a look here:
On 14 janv. 2013, at 21:30, k-ohara5...@oco.net wrote:
> LilyPond is too complicated.
>
> The manual explains engravers and contexts, and you you can
> \layout {
> \context { \Staff \remove "Accidental_engraver" }
> \context { \Voice \consists "Accidental_engraver" }}
>
But does the manual say
LilyPond is too complicated.
The manual explains engravers and contexts, and you you can
\layout {
\context { \Staff \remove "Accidental_engraver" }
\context { \Voice \consists "Accidental_engraver" }}
but then there are all these properties that mess with that structure,
like
horizontallyAli
On Mon, 14 Jan 2013 10:25:24 -0800, wrote:
If you can access the value with
staffline_ && to_boolean(staffline_ -> get_property("remove-empty"))
at this point, that would seem to be simpler.
It would also mean that we can just leave keepAliveInterfaces alone when
switching between harakiri
2013/1/14 David Kastrup :
> As you aptly observed, that's the best you yourself can barely manage
> for Spanish. But I can't believe you to be the only LilyPond user
> natively speaking Spanish. The main qualification we should be
> requiring from translators and translation revisors is good comm
I think this thread has moved too fast and we could have a problem of
time zones here. Sorry for answering on a one-by-one basis but it
worths it. The thread is asking many questions and I have some
answers. I don't want you to think I am not concerned with the issue.
2013/1/14 James :
> Once a lo
Francisco Vila writes:
> 2013/1/14 David Kastrup :
>>> Probably the CG should be updated, improved and simplified.
>>> I think that at the moment it would be a bit hard for a new translator
>>> to get in.
>>
>> And I think we could make of several new ones or, probably needing
>> similar measures
2013/1/14 David Kastrup :
> We have a translation branch, but for typos, I think (correct me if I am
> wrong) that of little relevance as we have back-and-forth merging.
Right.
> Factual errors occuring only in one translation should be fixed there.
> Factual errors inherited from the English ver
2013/1/14 David Kastrup :
>> Probably the CG should be updated, improved and simplified.
>> I think that at the moment it would be a bit hard for a new translator
>> to get in.
>
> And I think we could make of several new ones or, probably needing
> similar measures, reactivate some old ones.
>
> I
2013/1/14 David Kastrup :
> [...] I can't help the impression that we
> have, for several languages, people who feel responsible for maintaining
> the translations but are unaware that many translations are severely
> outdated and not really all that useful any more for working with the
> current v
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc
File lily/axis-group-engraver.cc (right):
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc#newcode122
lily/axis-group-engraver.cc:122: {
On 2013/01/14 18:20:44, Keith wrote:
On 2013/01/14 17:50:47
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc
File lily/axis-group-engraver.cc (right):
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc#newcode122
lily/axis-group-engraver.cc:122: {
On 2013/01/14 17:50:47, Keith wrote:
The property haraKiri
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc
File lily/axis-group-engraver.cc (right):
https://codereview.appspot.com/7061062/diff/1/lily/axis-group-engraver.cc#newcode122
lily/axis-group-engraver.cc:122: {
The property haraKiri is misleadingly named (because it sele
Original Message -
From:
To: ;
Cc: ;
Sent: Monday, January 14, 2013 2:11 PM
Subject: Re: CG: explicitly detail the correct values for git cl config
(issue7096052)
At this point, the git-cl used by the project has been sufficiently
geared towards lilypond development that I somewh
At this point, the git-cl used by the project has been sufficiently
geared towards lilypond development that I somewhat doubt anybody is
using it for work outside of lilypond. It might not make sense at all
for "our" git-cl to keep asking these superfluous questions; should they
be remove entirely
Werner LEMBERG writes:
>> So how can we improve the efficiency of our current translation work
>> force, and how can we make it easier for people to help in a way
>> that does not step on anybody's toes and actually leads to better
>> results?
>
> Yeah. Let's assume that I would like to quickly
2013/1/14 Werner LEMBERG :
> I wonder what's the best way to update outdated documentation.
> Reading the whole documentation and checking the translation is
> probably quite hard and needs a lot of time. Would it be better
> instead to use a git repository viewer, walking over the English
> docum
Hello,
On 14 January 2013 12:52, Federico Bruni wrote:
> 2013/1/14 Werner LEMBERG
>
>>
>> > So how can we improve the efficiency of our current translation work
>> > force, and how can we make it easier for people to help in a way
>> > that does not step on anybody's toes and actually leads to
2013/1/14 Werner LEMBERG
>
> > So how can we improve the efficiency of our current translation work
> > force, and how can we make it easier for people to help in a way
> > that does not step on anybody's toes and actually leads to better
> > results?
>
> Yeah. Let's assume that I would like to
> So how can we improve the efficiency of our current translation work
> force, and how can we make it easier for people to help in a way
> that does not step on anybody's toes and actually leads to better
> results?
Yeah. Let's assume that I would like to quickly improve various
places of the G
Federico Bruni writes:
> 2013/1/14 David Kastrup
>
> The only translations that appear to be thoroughly maintained are
> the
> Spanish and French translation, with the German translation
> following
> close behind.
>
>
>
> Well, the italian translation is far to be
2013/1/14 Werner LEMBERG
> I wonder what's the best way to update outdated documentation.
> Reading the whole documentation and checking the translation is
> probably quite hard and needs a lot of time. Would it be better
> instead to use a git repository viewer, walking over the English
> docum
2013/1/14 David Kastrup
> The only translations that appear to be thoroughly maintained are the
> Spanish and French translation, with the German translation following
> close behind.
>
>
Well, the italian translation is far to be completed but it _is_ maintained.
> It would a lamentable state
> [...] I can't help the impression that we have, for several
> languages, people who feel responsible for maintaining the
> translations but are unaware that many translations are severely
> outdated and not really all that useful any more for working with
> the current version of LilyPond: partl
Harmath Dénes writes:
> 2013/1/13 Francisco Vila
>
> the dead links to web.xx.pdf occur only on certain languages:
> fr, de, cs, hu
>
>
> for 'es' the link is alive but points to untranslated web.pdf
>
> As responsible for the Hungarian translation, what are the exact steps
2013/1/14 Harmath Dénes
> As responsible for the Hungarian translation, what are the exact steps I
> should perform in order to solve this?
>
Hi Darmath
I don't think it's your duty, the problem is in the build system.
Honestly, I don't know why the links change depending on the language. The
f
As responsible for the Hungarian translation, what are the exact steps I
should perform in order to solve this?
2013/1/13 Francisco Vila
> 2013/1/13 Federico Bruni :
> > Il 13/01/2013 11:45, Francisco Vila ha scritto:
> >
> >> Oh sorry! you mean PDF of the translation of the web document.
> >>
>
On 14 janv. 2013, at 10:42, Phil Holmes wrote:
> - Original Message - From:
> To: "Phil Holmes"
> Cc: "Devel"
> Sent: Monday, January 14, 2013 7:41 AM
> Subject: Re: 2.17.10 regtests
>
>
>
> On 13 janv. 2013, at 12:35, Phil Holmes wrote:
>
>> There are some that concern me in par
Il 13/01/2013 13:26, Phil Holmes ha scritto:
Aha. It's because you're missing a bugfix that's in master. Have a
look at
f1e9b96641440bf81e701f01dbad61ed2ca6a83e
- you should be able to edit website_post.py manually to apply that fix.
yes, it works fine on master
thanks
--
Federico
___
LGTM; "not used by LilyPond" is really superior to "you don't need to
understand"!
https://codereview.appspot.com/7096052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2013/1/14 Phil Holmes :
> Surely the bracket should not be visible by default if you're setting
> mensural notation? Should not the \remove Ligature_bracket_engraver be
> removed automatically for mensural notation?
it is removed in MensuralVoice, but hey, this is just a regtest:
ambitus is not
- Original Message -
From:
To: "Phil Holmes"
Cc: "Devel"
Sent: Monday, January 14, 2013 7:41 AM
Subject: Re: 2.17.10 regtests
On 13 janv. 2013, at 12:35, Phil Holmes wrote:
There are some that concern me in particular:
finger-chords.ly: I think the vertical positioning is now wr
- Original Message -
From: "Benko Pál"
To: "Phil Holmes"
Cc: "Devel"
Sent: Sunday, January 13, 2013 9:28 PM
Subject: Re: 2.17.10 regtests
all,
2013/1/13 Phil Holmes :
I've just whiled away a happy few minutes looking at the regtests. There
are quite a number of changes, I think m
LGTM
https://codereview.appspot.com/7101048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
dear developers
please separate the word commit and the following commitish string when you
change an issue to "fixed" - it makes it easier (for me) to double-click and
select when verifying
thanks
Eluze
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/put-a-blank-before
Suggested addition.
https://codereview.appspot.com/7101048/diff/1/Documentation/contributor/issues.itexi
File Documentation/contributor/issues.itexi (right):
https://codereview.appspot.com/7101048/diff/1/Documentation/contributor/issues.itexi#newcode850
Documentation/contributor/issues.itexi:85
On 14 janv. 2013, at 09:46, d...@gnu.org wrote:
> What happened to "I'll have a look later" in
> https://codereview.appspot.com/7069044#msg5>? Have you even
> _tried_ using the remove-empty property of the created axis spanner
> instead of adding a new haraKiri property duplicating its functiona
What happened to "I'll have a look later" in
https://codereview.appspot.com/7069044#msg5>? Have you even
_tried_ using the remove-empty property of the created axis spanner
instead of adding a new haraKiri property duplicating its functionality?
https://codereview.appspot.com/7061062/
_
43 matches
Mail list logo
