Werner wrote Monday, July 27, 2009 12:09 PM
1.220 ossia
add:
There can also be cue notes in the same staff.
See also:
cue-notes
1.72
add:
Also used to give alternatives (e.g. for smaller hands or
instruments not able
to play as low/high, as desired).
See also:
ossia
Thanks for the
Federico, you wrote Tuesday, July 28, 2009 11:24 PM
Last month I started translating the doc into italian, so the
Music Glossary was the first doc I checked.
I have a list of the missing italian words, as well as some
corrections of existing ones. All these modifications have been
already
Mark Polesky wrote Wednesday, July 08, 2009 7:01 PM
Should we add a Known issues and warnings somewhere in
NR 1.4 (Repeats) for this issue?
% bad (don't put \relative inside \repeat)
{ \repeat unfold 2 \relative { c d e f } }
% good
\relative { \repeat unfold 2 { c d e f } }
I added this
Mark Polesky wrote Thursday, July 30, 2009 3:42 PM
This should be mentioned in the docs.
It already is. LM 4.4.3.
- Mark
Trevor
Alexander Kobel wrote:
If I use markup at the last note of a bar and the next bar has
a bar
number appearing, then the bar number appears above the text
Federico Bruni wrote Thursday, July 30, 2009 6:12 PM
I would have a very tiny edit for the documentation.
It's a very small detail and normal users of lilypond will laugh
at me, but I think it's useful for newbies (like me).
Notation Reference, 1.3.3, section Arpeggio:
This is the second
Mark Polesky wrote Thursday, July 30, 2009 7:06 PM
It would be nice to have some central place that explains some
internals concepts. Here are examples of things that a new
developer
might have to ask about, or perhaps spend a long time
disentangling:
grob
prob
smob
output-def
callback
Graham Percival wrote Friday, July 31, 2009 3:05 AM
Could you redistribute the material in LM 5.2 Scores and parts
elsewhere in the LM? Maybe beef up LM 2.4.1, maybe insert a new
LM 2.4.2 that continues the scores and parts theme, maybe
something in LM 3... whatever.
Done. I made a new
Graham Percival wrote Friday, July 31, 2009 10:50 AM
On Fri, Jul 31, 2009 at 09:18:45AM +0100, Trevor Daniels wrote:
It also uses \include, which isn't introduced anywhere, but
Woah, seriously? LM 3.1 is perfect for that. Anyway, I'll leave
this for you.
OK
Perhaps we should move
Graham Percival wrote Friday, July 31, 2009 12:47 PM
On Fri, Jul 31, 2009 at 12:00:53PM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, July 31, 2009 10:50 AM
Besides, suggestions for writing files totally _sounds_ like
usage information to me. :)
Not sure about totally
Trevor Daniels wrote Friday, July 31, 2009 3:32 PM
Graham Percival wrote Friday, July 31, 2009 12:47 PM
Ah, I'd forgotten about those. Yes, 5.1.4 and 5.1.5 would be
better off in LM 3. Or maybe LM 4, since they both discuss
tweaks.
OK. I'll move 5.1.4 and 5.1.5 out sometime in
the next
Mark Polesky wrote Friday, July 31, 2009 7:10 PM
Han-Wen Nienhuys wrote:
No. In the specific case, I'd recommend making another music
function that takes an argument, so you can pass the 15/16
explicitly, without mucking with variables.
So it sounds like you believe that one way or
Mark Polesky wrote Friday, July 31, 2009 8:51 PM
I'm okay with it. But I'd like to see what the others think. Am
I correct in thinking that if an object returns #t for this test
from within a .ly file, it qualifies as a parser variable?
#(defined? 'object-name)
Sorry, I don't know. Anyone
Graham Percival wrote Monday, July 27, 2009 11:22 AM
Lilypond Syntax Development (tentative name)
However, I think we now have a critical mass of interested users,
experience with the syntax, and developers. I therefore propose
to have a Grand Project devoted to stabilizing the lilypond
Thanks Werner.
I've added a mention of the CueNotes context
with an example of its use for rendering a
sequence of alternative notes in NR 1.6.3.
Trevor
- Original Message -
From: Werner mey@web.de
To: lilypond-devel@gnu.org
Sent: Monday, July 27, 2009 12:05 PM
Subject: doc
Mark Polesky wrote Saturday, August 01, 2009 9:09 PM
Patrick McCarty wrote:
$ git pull ssh://sv/srv/git/lilypond.git master
fatal: The remote end hung up unexpectedly
Well, that URI is kind of bogus. :-)
It worked fine yesterday.
It works fine here today too. That's not the problem.
Mark Polesky wrote Sunday, August 02, 2009 1:43 AM
Trevor Daniels wrote:
Error reading commits:
child killed: unknown signal
I've never seen this error message, but it
suggests a problem with the git repo. Try
verifying the database. git gui/Repository/Verify Database
With that, I get
Mark Polesky wrote Sunday, August 02, 2009 10:03 PM
So I did git fetch and got this:
$ git fetch
The authenticity of 'git.sv.gnu.org (199.232.41.69)' can't be
established.
RSA key fingerprint is
Are you sure you want to continue connecting (yes/no)?
This means the known-hosts file
Mark Polesky wrote Monday, August 03, 2009 2:30 AM
Mark Polesky wrote:
199.232.41.69 ssh-rsa B3NzaC1yc2E ...
It's the public key of the Savannah server. In
case you've lost it, I've attached one.
My copy of the public key looks fine.
Any other ideas?
Not shots in the dark.
Graham Percival wrote ages ago on Monday, October 06, 2008 8:00 PM
On Mon, 6 Oct 2008 19:53:10 +0100
Neil Puttock n.putt...@gmail.com wrote:
2008/10/6 Graham Percival gper...@gmail.com:
Why isn't
\set HarmonicDots = ##t
set by default? IMO we should normally print the dot in
Mark Polesky wrote Monday, August 03, 2009 4:25 PM
Graham Percival wrote:
What does:
git reset --hard origin
or
git reset --hard origin master
do? I'd expect one of those to set you to a working state. (NB:
by I'd expect, I mean as a user, I think the program should do
this.
Mark Polesky wrote Monday, August 03, 2009 11:38 PM
Trevor Daniels wrote:
These commands will fail. The correct command is
$ git reset --hard origin/master
It gets up to 50%, then crashes:
Checking out files: 50% (963/1926)
(here the Windows error box pops up)
Once I close the pop-up
Mark Polesky wrote Tuesday, August 04, 2009 9:23 AM
Does anyone know -- is there any harm in just generating a new
SSH key pair?
No harm at all.
I think my modem gives me a different IP address
from time to time.
It (well, your ISP) will - that's normal.
I could be making that up, and
Trevor Daniels wrote Thursday, July 30, 2009 9:16 PM
Mark Polesky wrote Thursday, July 30, 2009 7:06 PM
It would be nice to have some central place that explains some
internals concepts. Here are examples of things that a new
developer
might have to ask about, or perhaps spend a long time
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought the outcome of the discussion
was to use xHead or crossHead for the base
name with deadNote being defined to invoke
the base function
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM
On 8/5/09 2:44 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM
On 8/5/09 2:44 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought
Trevor Daniels wrote Wednesday, August 05, 2009 9:09 AM
Trevor Daniels wrote Thursday, July 30, 2009 9:16 PM
Mark Polesky wrote Thursday, July 30, 2009 7:06 PM
It would be nice to have some central place that explains some
internals concepts.
...
It would be nice to have a LilyPond
Carl Sorensen wrote Wednesday, August 05, 2009 3:07 PM
On 8/5/09 7:22 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
I think it was a pity that the groundwork
for a more generic approach was not laid
down right away, so we could have easily
added the aliases for all the other uses
Mark Polesky wrote Wednesday, August 05, 2009 8:21 PM
I've not been able to connect to git via SSH since Saturday,
and nothing I've tried
has worked. I'd like to take care of
that first, but I'm out of ideas.
Can you remind us what you have tried
so far?
Re-boot (obviously yes?)
Obtain
Graham Percival wrote Thursday, August 06, 2009 7:51 AM
On Thu, Aug 06, 2009 at 12:12:59AM +0100, Ian Hulin wrote:
This is AU section 3.2.1
--
If ‘filename.ly’ contains more than one \score block, then the
rest of the
scores will be output in numbered files, starting with
Graham
I've just pushed another fix for broken refs resulting from your doc
reorganisation. As there seems to be no replacement nodes all I can
do is comment them out with a FIXME. Any chance you could add
replacement nodes as you go so we can fix the links properly rather
than scattering
John Mandereau wrote Wednesday, August 05, 2009 8:47 PM
At least one of the terms listed by Mark is introduced in the
Learning
Manual: grob in 4.1.2 Objects and interfaces. I see this
glossary
could be a quick reference that briefly defines each term and
gives
cross-references to
Graham Percival wrote Thursday, August 06, 2009 10:06 AM
On Thu, Aug 06, 2009 at 09:50:56AM +0100, Trevor Daniels wrote:
I've just pushed another fix for broken refs resulting from your
doc
reorganisation.
Oops, I forgot that I need to touch foo.tely before testing.
That said, it would
John Mandereau wrote Thursday, August 06, 2009 12:06 PM
Le jeudi 06 ao=C3=BBt 2009 =C3=A0 11:35 +0100, Trevor Daniels a
=C3=A9crit =
:
Have you tried building docs inside the source tree?
No; I'm on Windows Vista, so building isn't an option, is it?
I generated my own scripts so I can
John, you wrote Thursday, August 06, 2009 3:01 PM
No; I'm on Windows Vista, so building isn't an option, is it?
No, but you can still run check-xrefs and fix-xrefs, but it will
complain about missing files markup*.tely, internals.tely and so
on.
Good. In that case I'll leave them for
Mark Polesky wrote Thursday, August 06, 2009 3:26 PM
Anything holding up 2.13.4? By now there are so
many new things that I'd like to try, but I'm a
non-compiler, so...
I'm stuck too. Neil updated the LSR today,
so now lots of snippets require 2.13.4 and
I can no longer compile the docs
Neil Puttock wrote Thursday, August 06, 2009 9:58 PM
2009/8/6 Trevor Daniels t.dani...@treda.co.uk:
I'm stuck too. Neil updated the LSR today,
so now lots of snippets require 2.13.4 and
I can no longer compile the docs easily, so
can't check any edits I make.
I'm sorry as always when
Kieren
I'm not sure I understand the need for this.
Maybe I'm missing something (it wouldn't be
unusual :)
I would not normally use a lyric extender
unless the syllable had an extended duration
over several notes or was sung to a long note.
This occurs far less frequently than a 2-note
melisma.
Graham wrote Thursday, August 06, 2009 11:53 PM
Sorry, not this time. The purpose of the unstable releases is to
aid the development effort; it doesn't make sense to hold Trevor
and Mark back just because the doc build is in flux.
The MinGW build that Neil made is fine, Graham, so
there's
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM
On 8/5/09 7:19 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM
If we decide to use this same function for the general case of
switching to
a cross-shaped notehead, then we
Hi Kieren,
I'm not sure I understand the need for this.
I would not normally use a lyric extender
unless the syllable had an extended duration
over several notes or was sung to a long note.
This occurs far less frequently than a 2-note melisma.
Do you attach lyric extenders unconditionally
to
Valentin Villenave wrote Friday, August 07, 2009 9:45 PM
So, I'm thinking that we'd better junk these pseudo-options, and
ask
Seba to make HTML formatting allowed in all snippet descriptions.
Thoughts?
Sounds reasonable. Do we make it clear anywhere what html
markup is permitted in
Patrick McCarty wrote Saturday, August 08, 2009 5:00 AM
On Fri, Aug 07, 2009 at 08:39:16PM -0700, Mark Polesky wrote:
Patrick McCarty wrote:
I've just tested git's shallow cloning feature. It's pretty
neat.
:-)
From what I can see, shallow clones would be okay for *casual*
Kieren MacMillan Sunday, August 09, 2009 4:47 AM
From my point of view the main use for smallStaff (or whatever it
gets called) is for ossia staves.
Except IIRC ossia staves and solo/cue staves are usually of
different sizes, yes?
In scores for a capella vocal music a piano
Mark Polesky wrote Sunday, August 09, 2009 7:31 PM
Well, that's not a functional barline, it's just printed. It's
similar to putting :| which prints a repeat sign, but doesn't
cause LilyPond to recognize the previous section as repeated. I
guess NR 1.2.5 could make this clearer.
original
Patrick McCarty wrote Sunday, August 09, 2009 3:36 AM
On Sat, Aug 08, 2009 at 07:21:42PM -0700, Patrick McCarty wrote:
Hmm, I just realized that the inconsistency still exists, even
with my
patch. Here's an example:
\relative c'' {
a8 a a a
a8 a a a
a16 a a8 a a
a8 a16 a
Patrick McCarty wrote Saturday, August 08, 2009 5:33 PM
On Sat, Aug 08, 2009 at 01:59:50AM -0700, Graham Percival wrote:
A few people talked about browsing the history, which surprised
me. Whenever I want to look at history, I use the web git
interface. But evidently other people don't
Carl Sorensen wrote Sunday, August 09, 2009 10:59 PM
Could the two of you please take some of these examples and beam
them
manually so that I can see what they *should* do? I'll then try
to figure
out why the autobeam engraver doesn't do it.
Some explanation as to *why* it should work the
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty pnor...@gmail.com:
I wonder why we are seeing different beaming patterns? I think all
of
your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing
Graham Percival wrote Monday, August 10, 2009 9:18 AM
On Mon, Aug 10, 2009 at 08:45:22AM +0100, Trevor Daniels wrote:
Graham Percival wrote Monday, August 10, 2009 12:48 AM
I maoing hate git.
Git is fine; the complexity comes from the
baroque structures in LilyPond. Let's be
thankful
Trevor Daniels wrote Monday, August 10, 2009 8:49 AM
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty pnor...@gmail.com:
I wonder why we are seeing different beaming patterns? I think
all of
your manually-beamed patterns are correct though.
Trevor's using
Carl, you wrote Monday, August 10, 2009 10:58 PM
On 8/10/09 9:14 AM, Trevor Daniels t.dani...@treda.co.uk
wrote:
With all Carl's mods applied just the expected two
inconsistencies
remain:
\relative c'' {
a8 a a16 a a8 a a a a16 a | % wrong, should be ...
a8 a a16[ a a8] a a a[ a16
that this is a more fundamental problem.
Trevor
- Original Message -
From: Carl Sorensen c_soren...@byu.edu
To: Trevor Daniels t.dani...@treda.co.uk; Neil Puttock
n.putt...@gmail.com; Patrick McCarty pnor...@gmail.com
Cc: lilypond-devel lilypond-devel@gnu.org
Sent: Monday, August 10, 2009 11:25 PM
Mark Polesky wrote Tuesday, August 11, 2009 12:25 AM
I'm git-weary but still alive. Johannes spent *hours* debugging
my problem, and eventually traced it to an undiscovered bug
in gitk that only affects Microsoft Windows...
Nice to have you operational again. Thanks Johannes!
Can you say
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
deadNotes and palmMute
Johannes Schindelin wrote Tuesday, August 11, 2009 12:51 PM
On Tue, 11 Aug 2009, Trevor Daniels wrote:
Mark Polesky wrote Tuesday, August 11, 2009 12:25 AM
I'm git-weary but still alive. Johannes spent *hours* debugging
my problem, and eventually traced it to an undiscovered bug
in gitk
Mark Polesky wrote Tuesday, August 11, 2009 7:18 PM
My concept glossary idea is now called a technical glossary.
I thought the name was fine when it was suggested, but now I'm
realizing something -- I'd also like it to list terms that are not
specifically dealing with LilyPond *internals*.
Hi Mark
Good to see you pushing again!
But could you preface commits which affect only docs with Docs:
please. It helps code developers with better things to do to skip
uninteresting commits.
Trevor
___
lilypond-devel mailing list
Carl Sorensen Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
Carl, I am part-way through
Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM
And if we're ever going to move it to a postfix operator (which is
one of
the goals of the GLISS project), now is the time, before we get a
strong
codebase of music function applications.
I'm beginning to wonder whether this is a
Andrew Hawryluk wrote Thursday, August 13, 2009 4:18 AM
Long ago I noticed that the text in our PDF manuals is fully
black,
which results in rough-looking text when printed:
http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
Attached is a patch which corrects this, and
Mark Polesky wrote Saturday, August 15, 2009 3:26 AM
3) Make the command index strictly a *command* index.
Add a separate property index strictly for properties. It
could even be on the same page -- just the existence of a menu
with the two different node names should be enough to help
Mark
I'm top-posting as I'm not answering any of your specific questions.
If you really want to understand how data types are defined you will
need to understand how lexers and parsers work first. To help, I've
just added a few more clues to the Technical glossary. Then you
will find all
Werner LEMBERG wrote Monday, August 17, 2009 6:42 PM
I've just seen this change in a recent commit:
+...@seealso
+
+Installed Files:
+...@file{lily/parser.yy}
IMHO, this is not correct: lily/parser.yy does *not* get installed
at
all! Either we introduce a special macro which points to
Graham Percival wrote Monday, August 17, 2009 10:35 PM
On Mon, Aug 17, 2009 at 05:17:08PM +0200, Reinhold Kainhofer
wrote:
Am Montag, 17. August 2009 16:08:36 schrieb Michael Käppler:
(nobody checks the regression tests for each release, for
example
-- and that's trivially done with
Mark Polesky wrote Tuesday, August 18, 2009 6:04 AM
Mark Polesky wrote:
What does this mean?
ly/music-functions-init.ly
476 %% Todo:
477 %% doing
478 %% define-music-function in a .scm causes crash.
Nevermind. I'm an idiot. I get it.
Actually, strike that. What does this comment
Graham Percival wrote Wednesday, August 19, 2009 1:00 PM
I get the same thing even with make. I've reverted Trevor's
commit, although I have no clue what's wrong. These errors
generally mean that the @menu wasn't updated, but he did that
perfectly (as far as I can see). I'm baffled, but
Mark Polesky wrote Thursday, August 20, 2009 8:59 AM
I made an attempt at cleaning up property-init.ly. I
included my revised file (not a patch) Mostly I'm
curious to know if there's anything I'm doing here
that goes against coding conventions or anything like
that. Or if I'm making things
I'm trying to complete the 'prob' entry in the Technical glossary.
From a position of ignorance I've come up with this:
PRoperty OBjects, or @strong{probs} for short, are instances of
the @code{Prob} class, a simple base class for objects which have
mutable and immutable property alists. The
Marc Hohl wrote Saturday, August 22, 2009 7:30 PM
Jay Anderson schrieb:
[...]
So what do you think? Should the SmallStaff just
be left as a snippet?
If it is a snippet ideally I'd want to do something like:
\include small_staff.lyi
\score {
\new SmallStaff {...}
}
How would one make
Werner LEMBERG wrote Saturday, August 22, 2009 7:23 AM
There is a horizontal offset bug if a markup is attached to a
skip.
Look at this small example:
\paper {
ragged-right = ##f
}
foo = {
s1
\time 7/8 s8*7^foobar
\time 10/8
}
bar = {
R1
R8*7
}
\context Staff
Mark Polesky wrote Sunday, August 23, 2009 11:16 PM
Carl Sorensen wrote:
Here's what I recommend (I didn't used to do this, but it
seems to be a better way to work).
git branch newfeature
git checkout newfeature
git rebase -i master
git rebase -I SHA1-ID-of-the-parent-of-branch-newfeature
Carl Sorensen wrote Monday, August 24, 2009 1:25 AM
From: Trevor Daniels [t.dani...@treda.co.uk]
Not sure these rebases are necessary if
you are going to use cherrypick rather
than merge.
Yes, your method works OK.
I use the rebase to get all of my work into
a single commit, instead
Werner LEMBERG wrote Monday, August 24, 2009 3:08 PM
This effect seems to be a consequence of ragged-right = ##f
together
with a second bar containing a single note (or space). When the
second bar is stretched to fill the line the note gets displaced
almost to the centre of the bar. This
It seems there has been a change in the splitting of manuals on
kainhofer. They no longer split at numbered sections but only at
the second level. So the whole of Pitches, for example, comes as a
single html page. Is this deliberate or an error?
Trevor
Werner LEMBERG wrote Monday, August 24, 2009 9:52 PM
I would argue against introducing this complication. Positioning
spacer rests differently to notes of the same duration does not
seem
a good idea.
Well, my example shows that it actually uses a *different*
position
compared to the
Werner LEMBERG wrote Tuesday, August 25, 2009 6:52 AM
Both the note and the spacer in the second bar are positioned in
roughly the centre of the bar, although interestingly not quite
in
identical positions. I don't know why they differ slightly, but
you
see my point.
Here's another
Werner LEMBERG wrote Tuesday, September 01, 2009 6:44 AM
Hmm. I currently can't imagine a situation where a value 0 is
needed, so I vote to remove the setting of
#'outside-staff-priority for MultiMeasureRestText -- however,
I'm
not sure whether this has any influence to issue #495 (this
Werner LEMBERG wrote Tuesday, September 01, 2009 4:30 PM
It seems sensible to have a distinct, lower, value, but something
like 40 would place it below everything else while retaining some
future flexibility.
OK. Shall I commit this or will you do that?
Werner, I'll do it, but I've had
Joe, you wrote Tuesday, September 01, 2009 8:49 PM
Attached is a patch to extend the NR documentation on Turkish
classical
music as defined in the file makam.ly.
Thanks for this, but I'm afraid the patch has whitespace errors
and also fails to apply.
The console output says:
Applying
Carl Sorensen wrote Wednesday, September 02, 2009 1:06 PM
On 9/2/09 2:41 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
So instead I propose to change the definition
of \fermataMarkup to:
fermataMarkup =
#(make-music 'MultiMeasureTextEvent
'tweaks (list
; Set the 'text
Joe, you wrote Wednesday, September 02, 2009 4:53 PM
Trevor Daniels wrote:
Thanks for this, but I'm afraid the patch has whitespace errors
and also fails to apply.
I don't understand what 'whitespace errors' are -- sorry, this is
my
first time using texinfo and git on a project. If you
Francisco Vila wrote Wednesday, September 02, 2009 4:59 PM
Hello, here are some updates to the Spanish definitions of the
Music Glossary.
Thanks. Applied to origin/master.
I've found that church modes are not translated: there is no
reference
to Ionian, Dorian etc in other languages
Joseph Wakeling wrote Wednesday, September 02, 2009 7:48 PM
I think the attached patches should work. They should lack
trailing
whitespace and I've used git format-patch origin which I hope will
generate the patch against the head of the master branch. (Still
getting the hang of git; I'm a
Joe, you wrote Thursday, September 03, 2009 7:20 AM
Trevor Daniels wrote:
Thanks Joe. Initially these patches didn't apply either, but I
traced the reason to their having DOS (CRLF) line endings
rather than Unix (LF) line endings. When I changed that they
applied fine. (This actually might
Hi Joe, you wroteThursday, September 03, 2009 10:35 AM
Trevor Daniels wrote:
I then looked at the actual mail message. You're using
Thunderbird with inline attachments and quoted-printable
encoding. This is the problem. I seem to remember
Jonathan Kulp discovering that Thunderbird messed
Joseph Wakeling wrote Thursday, September 03, 2009 7:22 PM
... if the previous patch doesn't work, I hope the one attached to
this
mail will. Let me know how it goes. :-)
Still has DOS line endings :( But it's really not a problem - I can
easily change them before applying.
I didn't
Hi Joe, you wrote Friday, September 04, 2009 12:42 AM
As discussed on the -user list, this is a patch to start a section
in
the Specialist Notation chapter on contemporary music.
I really hope that this patch (or rather, this email containing
the
patch:-) has avoided the DOS line endings.
Reinhold
The last doc update on your server was on
1 Sep - has something broken? I see there
are several broken links following Graham's
recent reorganisation. Let me know if this
is the problem and I'll fix them.
Trevor
___
lilypond-devel
Graham Percival wrote Friday, September 04, 2009 10:03 PM
On Fri, Sep 04, 2009 at 09:54:38PM +0100, Trevor Daniels wrote:
The last doc update on your server was on
1 Sep - has something broken? I see there
are several broken links following Graham's
recent reorganisation. Let me know
Hi Joe, you wrote Friday, September 04, 2009 3:49 PM
Hope the previous message works. It's a small, incremental
change, just
to see if git-send-email will work where Thunderbird clearly
doesn't ... :-)
If this is an acceptable way to send patches, shall I add a
section to
the CG
Reinhold Kainhofer wrote Friday, September 04, 2009 10:51 PM
Am Freitag, 4. September 2009 23:12:00 schrieb Trevor Daniels:
Graham Percival wrote Friday, September 04, 2009 10:03 PM
Oh, I see it now. Remember that we currently need to touch any
docs we want updated. I've just done
Graham Percival wrote Saturday, September 05, 2009 12:43 AM
On Sat, Sep 05, 2009 at 12:35:06AM +0200, Reinhold Kainhofer
wrote:
Am Samstag, 5. September 2009 00:12:44 schrieb Trevor Daniels:
Reinhold Kainhofer wrote Friday, September 04, 2009 10:51 PM
It seems that the NR was really last
Carl Sorensen wrote Sunday, September 06, 2009 3:46 AM
On 9/5/09 7:12 PM, Graham Percival gra...@percival-music.ca
wrote:
Hmm. This could be a meaningless semantic quibble, or it could
be
something that's fundamental to the docs, GLISS, and development
in general. Is a change to the
Carl Sorensen wrote Saturday, September 05, 2009 2:13 PM
On 9/5/09 1:13 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
No. It's much easier to write documentation
than it is to add commands. I would not want to
delay useful additions to the documentation or to
put off a keen documentation
Thanks Joe - applied and pushed to origin/master.
The attached patch still had DOS endings, no problem with that,
but it lacked a commit message and your email address, so I
had to add those. Your previous method of creating patches
included these in the patch. Could you use that method in
I've finally got around to thinking about the introduction to
parallel voices in the Learning Manual - currently sections 3.2.1
and 3.2.2. You'll remember the many discussions about the two
constructs - explicit voices and the \\ construct, and the
final agreement to introduce explicit voices
Joseph Wakeling wrote Sunday, September 06, 2009 10:36 PM
OK, I think I've cracked the problem of patches with Thunderbird.
The
problem is that Thunderbird takes .patch files to be of mime-type
text/x-diff. Renaming the file to end in .txt changes its opinion
of
the file type and allows
Graham Percival wrote Monday, September 07, 2009 12:53 AM
On Sun, Sep 06, 2009 at 11:22:42PM +0100, Trevor Daniels wrote:
Joseph Wakeling wrote Sunday, September 06, 2009 10:36 PM
This probably _is_ something which should be in the docs as it's
not
something you would imagine would
Joseph Wakeling wrote Monday, September 07, 2009 12:41 AM
Joseph Wakeling wrote:
the duplication of two @nodes called 'Further reading' may break
the doc
build -- just checking that now.
Duplicate node names in the same manual do break the build.
... which the attached patch should fix.
201 - 300 of 1527 matches
Mail list logo
