re: [PATCH 1/2] Fix spelling definiton - definition
Message du 20/01/12 03:42 De : Stefan Weil A : lilypond-devel@gnu.org Copie à : Stefan Weil Objet : [PATCH 1/2] Fix spelling definiton - definition Signed-off-by: Stefan Weil --- po/cs.po po/de.po po/el.po po/es.po po/fr.po po/it.po po/ja.po po/lilypond.pot po/nl.po po/vi.po Please *never* patch the po directory: all translations transit on the Free Translation Project. The master file, lilypond.pot, is generated by a dedicated script I will run when 2.16-RC1 comes out. The po files are to the responsability of a due translator who willl send his updated native po file to the FTP. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] Fix spelling definiton - definition
Jean-Charles, On 20 January 2012 08:02, Lilyfan lily...@orange.fr wrote: Message du 20/01/12 03:42 De : Stefan Weil A : lilypond-devel@gnu.org Copie à : Stefan Weil Objet : [PATCH 1/2] Fix spelling definiton - definition Signed-off-by: Stefan Weil --- po/cs.po ... Please *never* patch the po directory: all translations transit on the Free Translation Project. The master file, lilypond.pot, is generated by a dedicated script I will run when 2.16-RC1 comes out. The po files are to the responsability of a due translator who willl send his updated native po file to the FTP. Should we mention this in the Contributor Guide somewhere - Documentation Translation didn't seem the appropriate place? Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] Fix spelling definiton - definition
Message du 20/01/12 09:15 De : James A : Lilyfan Copie à : StefanWeil , lilypond-devel@gnu.org Objet : Re: [PATCH 1/2] Fix spelling definiton - definition Jean-Charles, On 20 January 2012 08:02, Lilyfan wrote: Message du 20/01/12 03:42 De : Stefan Weil A : lilypond-devel@gnu.org Copie à : Stefan Weil Objet : [PATCH 1/2] Fix spelling definiton - definition Signed-off-by: Stefan Weil --- po/cs.po ... Please *never* patch the po directory: all translations transit on the Free Translation Project. The master file, lilypond.pot, is generated by a dedicated script I will run when 2.16-RC1 comes out. The po files are to the responsability of a due translator who willl send his updated native po file to the FTP. Should we mention this in the Contributor Guide somewhere - Documentation Translation didn't seem the appropriate place? I think it should be worth it. In fact, it doesn't belong to translations but rather directly to the source code (everything that will be gettextified). Ooops, my chief... further read after office-time ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
Ok, this latest iteration is quite close to what I want to end up committing. All the work of picking apart articulations and events have gone into the rhythmic event iterator. What it does is to broadcast all articulations that have a listener, and keep the rest as articulations. One side effect will be that things like c\3 will exhibit a string number (previously, only c\3 did). Another side effect is that tweaks can work on single notes outside of chords even when those have non-articulation postevents. You get an EventChord iff you write ... . A note getting postevents always receives them in 'articulations, whether it is part of an EventChord or not. Postevents on a chord get appended to the EventChord members as previously. This is total straightforward. I have _removed_ the compatibility option since it a) considerably complicated code, grammar and semantics b) was not able to a reasonably reliable job Instead, it will make sense to write a music function that tacks EventChord around naked rhythmic events (unwrapping the articulations in the process) and use that manually for converting music expressions to the old style when one does not want to adjust one's internals. In spite of the remaining problems with spanners and trills (slated to be removed in the next days), this should be good for testing how hand-written analysis code fares. There should be no difference to the way synthesized code (in the old style) gets typeset. So give this a testing now or after I shook out the last bugs. I am really planning to get this into 2.16. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
LGTM. Good job, Carl! http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Fix links in texinfo output (issue 2224). (issue 5557056)
LGTM http://codereview.appspot.com/5557056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
LGTM http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
LGTM http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy File lily/parser.yy (right): http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy#newcode432 lily/parser.yy:432: %type scm list_music I must *strongly* recommend that the name of either music_list or list_music be changed. Even if the names make distinct sense, it is far to easy to transpose identifiers like this when reading or writing code. (I have made this mistake in my own code many times in the past.) Given the existence of other _list types, I suggest that the name of list_music be changed. Maybe wrapped_music or music_chord... http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc File lily/rhythmic-music-iterator.cc (right): http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc#newcode62 lily/rhythmic-music-iterator.cc:62: if (scm_is_true ly_lily_module_constant should only be called for things that don't exist in C++. Otherwise, it's better to use the C++ function. In this case: ly_is_listened_event_class (in translator.cc) http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy File lily/parser.yy (right): http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy#newcode432 lily/parser.yy:432: %type scm list_music On 2012/01/20 13:55:56, md5i wrote: I must *strongly* recommend that the name of either music_list or list_music be changed. Even if the names make distinct sense, it is far to easy to transpose identifiers like this when reading or writing code. (I have made this mistake in my own code many times in the past.) Given the existence of other _list types, I suggest that the name of list_music be changed. Maybe wrapped_music or music_chord... Or nothing at all. This nonterminal is not in the current patch. It was part of -devent-chord-wrapper which was not reliable enough to be worth the trouble. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 2012/01/20 14:08:18, MikeSol wrote: http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc File lily/rhythmic-music-iterator.cc (right): http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc#newcode62 lily/rhythmic-music-iterator.cc:62: if (scm_is_true ly_lily_module_constant should only be called for things that don't exist in C++. I've seen that elsewhere. Maybe to support redefining the function before it is first memoized. Otherwise, it's better to use the C++ function. In this case: ly_is_listened_event_class (in translator.cc) Will do. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 2012/01/20 14:55:38, dak wrote: On 2012/01/20 14:08:18, MikeSol wrote: Otherwise, it's better to use the C++ function. In this case: ly_is_listened_event_class (in translator.cc) Will do. Very funny. After putting the (required) prototype into translator.hh, it takes hours to recompile on my slow machine. Rest is shaping up. For your programmatic uses of LilyPond, consider using extract-named-music and extract-typed-music (yes, you'll get to see _that_ only after I got through with !@#@! recompilation but then I might fork it out into a separate commit) since they get rather transparently at material without bothering about NoteEvent layers in between. Should I be forking the rhythmic-music-iterator stuff into the separate review (it's dormant code elsewhere, so Patchy is not all too informative once it compiles) or is it visible enough in here? It is, after all, pretty well-separated and requires the Issue 2233 patch as basis (currently also contained in this review but going to leave once I commit and it percolates to master). http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 2012/01/20 15:33:07, dak wrote: Should I be forking the rhythmic-music-iterator stuff into the separate review I'd say leave it with this - it's easy to forget that two patches need to be tested in concert. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] Fix spelling definiton - definition
Am 20.01.2012 09:02, schrieb Lilyfan: Message du 20/01/12 03:42 De : Stefan Weil A : lilypond-devel@gnu.org Copie à : Stefan Weil Objet : [PATCH 1/2] Fix spelling definiton - definition Signed-off-by: Stefan Weil --- po/cs.po po/de.po po/el.po po/es.po po/fr.po po/it.po po/ja.po po/lilypond.pot po/nl.po po/vi.po Please *never* patch the po directory: all translations transit on the Free Translation Project. The master file, lilypond.pot, is generated by a dedicated script I will run when 2.16-RC1 comes out. The po files are to the responsability of a due translator who willl send his updated native po file to the FTP. Cheers, Jean-Charles Salut, my patch also fixes the English text in python/convertrules.py. As soon as this file is changed, all po files no longer have a translation for this text because they are still referring to the old wrong text. That's a scenario which is not handled by the Free Translation Project - or is there a simple way how to fix an English text in all language files? I expected that it would be possible for a maintainer to apply the patch to all Free Translation Project po files in one action. Should I send a new patch which only changes python/convertrules.py, or what do you propose to fix this simple spelling bug? Cheers, Stefan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH 1/2] Fix spelling definiton - definition
2012/1/20 Stefan Weil s...@weilnetz.de: Salut, my patch also fixes the English text in python/convertrules.py. As soon as this file is changed, all po files no longer have a translation for this text because they are still referring to the old wrong text. That's a scenario which is not handled by the Free Translation Project - or is there a simple way how to fix an English text in all language files? I expected that it would be possible for a maintainer to apply the patch to all Free Translation Project po files in one action. All occurrences of 'definiton' in po files come from a single source string in python/convertrules.py , so please patch only that and we generate the po files afterwards. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix spelling definiton - definition
Signed-off-by: Stefan Weil s...@weilnetz.de
---
python/convertrules.py |2 +-
1 file changed, 1 insertions(+), 1 deletions(-)
diff --git a/python/convertrules.py b/python/convertrules.py
index 32cb5a5..b7d845f 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -392,7 +392,7 @@ def conv (str):
return str
-@rule ((1, 3, 93), _ ('change property definiton case (eg. onevoice -
oneVoice)'))
+@rule ((1, 3, 93), _ ('change property definition case (eg. onevoice -
oneVoice)'))
def conv (str):
# Ugh, but meaning of \stemup changed too
# maybe we should do \stemup - \stemUp\slurUp\tieUp ?
--
1.7.2.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
- error: syntax error, unexpected EVENT_IDENTIFIER
\foo
If I add a note before the identifier, it gets erroneously added to the
articulations list of the first NoteEvent, and is typeset in the wrong
place (at the start of the system).
Cheers,
Neil
http://codereview.appspot.com/5440084/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix spelling definiton - definition
2012/1/20 Stefan Weil s...@weilnetz.de: Signed-off-by: Stefan Weil s...@weilnetz.de 1.7.2.5 Applied, thanks. It would be better if you send patches as an attachment. Also, to keep your name in the author field you should make the patch with the git format-patch command. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Spelling fixes
Hi,
my last two patches were sent inline (with git send-email),
but I just learned that they should have been appended instead.
So here are both patches again. Both fix some spelling issues.
Kind regards,
Stefan Weil
From 808f92bccd5efff1348d614209d933da98f37ac2 Mon Sep 17 00:00:00 2001
From: Stefan Weil s...@weilnetz.de
Date: Thu, 19 Jan 2012 22:39:31 +0100
Subject: [PATCH] Fix spelling in input/regression/*.ly
accomodate - accommodate
adn - and
eigth - eighth
excercise - exercise
inbetween - between
occurence - occurrence
refered - referred
supressed - suppressed
Signed-off-by: Stefan Weil s...@weilnetz.de
---
input/regression/backend-excercise.ly |2 +-
input/regression/markup-scheme.ly |2 +-
input/regression/mozart-hrn3-rondo.ily |2 +-
input/regression/multi-measure-rest-text.ly |2 +-
input/regression/nested-fill-lines.ly |2 +-
input/regression/page-label.ly |2 +-
input/regression/rest-polyphonic-2.ly |2 +-
input/regression/spacing-short-notes.ly |2 +-
input/regression/tie-single.ly |2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/input/regression/backend-excercise.ly b/input/regression/backend-excercise.ly
index 0612002..ba4af11 100644
--- a/input/regression/backend-excercise.ly
+++ b/input/regression/backend-excercise.ly
@@ -1,5 +1,5 @@
\header {
- texidoc = Excercise all output functions
+ texidoc = Exercise all output functions
}
\version 2.14.0
diff --git a/input/regression/markup-scheme.ly b/input/regression/markup-scheme.ly
index fa71686..5dea41d 100644
--- a/input/regression/markup-scheme.ly
+++ b/input/regression/markup-scheme.ly
@@ -10,7 +10,7 @@
%{
-For maintenance reasons, we don't excercise the entire markup command set.
+For maintenance reasons, we don't exercise the entire markup command set.
%}
diff --git a/input/regression/mozart-hrn3-rondo.ily b/input/regression/mozart-hrn3-rondo.ily
index aeeb211..8e45355 100644
--- a/input/regression/mozart-hrn3-rondo.ily
+++ b/input/regression/mozart-hrn3-rondo.ily
@@ -130,7 +130,7 @@ rondo = \relative c' {
fis[ g gis]
a[ bes b]\!
- %% EB does the slur in the Rondo differently from the 1st adn 2nd time.
+ %% EB does the slur in the Rondo differently from the 1st and 2nd time.
%% why. Should check with MS.
\rondotheme
diff --git a/input/regression/multi-measure-rest-text.ly b/input/regression/multi-measure-rest-text.ly
index 2e2d432..73e1218 100644
--- a/input/regression/multi-measure-rest-text.ly
+++ b/input/regression/multi-measure-rest-text.ly
@@ -6,7 +6,7 @@
Texts may be added to the multi-measure rests.
By setting the appropriate @code{spacing-procedure}, we can make
-measures stretch to accomodate wide texts.
+measures stretch to accommodate wide texts.
diff --git a/input/regression/nested-fill-lines.ly b/input/regression/nested-fill-lines.ly
index f4236ea..011cc90 100644
--- a/input/regression/nested-fill-lines.ly
+++ b/input/regression/nested-fill-lines.ly
@@ -4,7 +4,7 @@
{
texidoc =
-Nested fill-lines should work properly. In this example, both occurences
+Nested fill-lines should work properly. In this example, both occurrences
of FOO should be centered.
diff --git a/input/regression/page-label.ly b/input/regression/page-label.ly
index 143d685..a369640 100644
--- a/input/regression/page-label.ly
+++ b/input/regression/page-label.ly
@@ -2,7 +2,7 @@
\header {
texidoc = Page labels may be placed inside music or at top-level,
-and refered to in markups.
+and referred to in markups.
}
#(set-default-paper-size a6)
diff --git a/input/regression/rest-polyphonic-2.ly b/input/regression/rest-polyphonic-2.ly
index 23af88f..e009dcf 100644
--- a/input/regression/rest-polyphonic-2.ly
+++ b/input/regression/rest-polyphonic-2.ly
@@ -3,7 +3,7 @@
texidoc = Rests avoid notes. Each rest is moved in the direction
of the stems in its voice. Rests may overlap other rests in voices
with the same stem direction, in which case a warning is given, but
-is supressed if the rest has a pitch.
+is suppressed if the rest has a pitch.
}
diff --git a/input/regression/spacing-short-notes.ly b/input/regression/spacing-short-notes.ly
index d05ef1d..47786b0 100644
--- a/input/regression/spacing-short-notes.ly
+++ b/input/regression/spacing-short-notes.ly
@@ -4,7 +4,7 @@
texidoc = Notes that are shorter than the common shortest note get a
space (i.e. without the space needed for the note) proportional to
-their duration. So, the 16th notes get 1/2 of the space of an eigth note.
+their duration. So, the 16th notes get 1/2 of the space of an eighth note.
The total distance for a 16th (which includes note head) is 3/4 of the
eighth note.
diff --git a/input/regression/tie-single.ly b/input/regression/tie-single.ly
index 899c927..f7b96fe 100644
--- a/input/regression/tie-single.ly
+++ b/input/regression/tie-single.ly
@@ -11,7 +11,7 @@
@item short ties
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
You have the newest. The problem is the definition of ly:event? (for
recognizing postevents). It is currently (in lily/music-scheme.cc)
defined as the equivalent of
(define (ly:event? m)
(and (ly:music? m)
(ly:is-music-of-type? m 'event)
(not (ly:is-music-of-type? m 'rhythmic-event
That seemed to be more or less right. Apparently you found a less
right case.
Suggestions?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 2012/01/20 17:33:44, dak wrote:
mailto:n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one
here?
I've tried it out briefly on a real music example, and have a
problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
You have the newest. The problem is the definition of ly:event? (for
recognizing postevents). It is currently (in lily/music-scheme.cc)
defined as the equivalent of
(define (ly:event? m)
(and (ly:music? m)
(ly:is-music-of-type? m 'event)
(not (ly:is-music-of-type? m 'rhythmic-event
That seemed to be more or less right. Apparently you found a less
right case.
Suggestions?
define-music-display-methods has a rather crude post-event? definition
but I am not all too sure whether it is early enough in the load-order.
I think I will go the tiresome way of explicitly putting post-event into
the types of each suitable music event. That puts the information to an
obvious place, and it does not look like the current event types
discriminate correctly.
And either post-event? or ly:event? should eventually be eradicated.
http://codereview.appspot.com/5440084/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 20 January 2012 17:32, David Kastrup d...@gnu.org wrote:
n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
You have the newest. The problem is the definition of ly:event? (for
recognizing postevents). It is currently (in lily/music-scheme.cc)
defined as the equivalent of
(define (ly:event? m)
(and (ly:music? m)
(ly:is-music-of-type? m 'event)
(not (ly:is-music-of-type? m 'rhythmic-event
That seemed to be more or less right. Apparently you found a less
right case.
Suggestions?
I can't think of anything better than adding another type such as
`command-event' to things like TempoChangeEvent and MarkEvent and
filtering that out too.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
The LilyPond Report #23 has been released
Greetings! After a long hiatus, the LilyPond Report #23 URL:http://news.lilynet.net/?The-LilyPond-Report-23 has been released on 2012-01-20. The report contains current news about the development of LilyPond, the GNU Music Typesetter URL:http://www.lilypond.org/ and features an article about recent work to make extending LilyPond with the GNU project's Scheme interpreter and extension language Guile URL:http://www.gnu.org/software/guile/ more accessible and powerful. Here is the intro: Greetings everybody, and welcome to this twenty-third issue of the LilyPond Report! Another year, another Report. This month we’re welcoming new LilyPond Report editor David Kastrup, who (in addition to being a talented developer) has been busy writing about some of the new, awesome features recently added to LilyPond... And speaking of awesomeness, don’t miss his interview with composer/contributor Mike Solomon, whose work never ceases to amaze! The table of contents features: Editorial Release news What’s up with LilyPond? An Interview With Mike Solomon Feature story: Prelude #1 in Scheme Bug Report of the Report Enjoy! -- For the editing team: David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 2012/01/20 17:59:40, Neil Puttock wrote: I can't think of anything better than adding another type such as `command-event' to things like TempoChangeEvent and MarkEvent and filtering that out too. Emacs stands for Editor Macros. ;; Keyboard Macro Editor. Press C-c C-c to finish; press C-x k RET to cancel. ;; Original keys: ESC @ ESC w C-x b RET C-s C-y RET C-s general-music RET SPC post-event C-x b RET C-s ' RET Command: last-kbd-macro Key: none Macro: ESC @ ;; mark-word ESC w ;; kill-ring-save C-x b ;; switch-to-buffer RET ;; newline C-s ;; isearch-forward C-y ;; yank RET ;; newline C-s ;; isearch-forward general-music ;; self-insert-command * 13 RET ;; newline SPC ;; self-insert-command post-event ;; self-insert-command * 10 C-x b ;; switch-to-buffer RET ;; newline C-s ;; isearch-forward ' ;; self-insert-command RET ;; newline And lo and behold, we have transferred the list of post events from define-music-display-methods.scm into define-music-types.scm. And have discovered in that way when regtesting that \LaissezVibrerEvent and \BreakDynamicSpanEvent must have wrongly been formatted as command events (since the post-event? function did not recognize them). Let's see whether we get more surprises. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
Wow -- what a lot of work. And it really seems to be cleaning things up! Thanks! http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm File scm/modal-transforms.scm (right): http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm#newcode129 scm/modal-transforms.scm:129: (define (make-scale music) I'm a bit hesitant to name this make-scale instead of extract-pitches. make-scale is a particular use, extract-pitches is a general use. But I don't feel really strongly about it. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Spelling fixes
On Fri, 20 Jan 2012 17:58:47 +0100 Stefan Weil s...@weilnetz.de wrote: Hi, my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. By the way, somebody please run codespell on the Lilypond sources: http://git.profusion.mobi/cgit.cgi/lucas/codespell/ It find so much stuff that perhaps somebody with commit access and good knowledge of the code could do it more effectively without bothering others. It's funny that codespell even found a mistake in German text (Probelm). There are some false positives, such as upto, portugues and \openin. Also, we probably don't want to fix old changelogs. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Spelling fixes
Hello, On 20 January 2012 16:58, Stefan Weil s...@weilnetz.de wrote: Hi, my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. Kind regards, Stefan Weil I'd offer to manage these but I guess it is better handled by someone who understands the translation branches? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Spelling fixes
2012/1/21 James pkx1...@gmail.com: Hello, On 20 January 2012 16:58, Stefan Weil s...@weilnetz.de wrote: Hi, my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. Kind regards, Stefan Weil I'd offer to manage these but I guess it is better handled by someone who understands the translation branches? These patches can be applied directly onto the staging branch. They only touch comments ant deprecated strings, or English texts whose translations don't need fixings. Translation branches explained: We have a single translation branch. Its name is lilypond/translation. Every often, any changes from master branch are merged on it. Translation changes are merged, in turn, onto the staging branch. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Spelling fixes
Am 21.01.2012 00:10, schrieb Pavel Roskin: On Fri, 20 Jan 2012 17:58:47 +0100 Stefan Weils...@weilnetz.de wrote: Hi, tre my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. By the way, somebody please run codespell on the Lilypond sources: http://git.profusion.mobi/cgit.cgi/lucas/codespell/ Hi Pavel, that's what I did. I started with three patches, but as soon as I know that they are accepted, more will follow. Cheers, Stefan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm File scm/modal-transforms.scm (right): http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm#newcode129 scm/modal-transforms.scm:129: (define (make-scale music) On 2012/01/20 23:02:21, Carl wrote: I'm a bit hesitant to name this make-scale instead of extract-pitches. make-scale is a particular use, extract-pitches is a general use. But I don't feel really strongly about it. extract-pitch-sequence [sic!] was only used inside of make-scale and returned a different, hardly useful value. I decided to keep its only caller make-scale instead. It is not like extract-pitch-sequence was the equivalent of a published API: almost every file has its own version of it. http://codereview.appspot.com/5440084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
