Le 16 févr. 2013 à 15:15, m...@mikesolomon.org a écrit :
I've heard from friends that Google has codified standards for how code
should be written. What are these standards like?
http://code.google.com/p/google-styleguide/ Style guides for
Google-originated open-source projects
Le 4 nov. 2012 à 07:53, Joram Berger a écrit :
Am 04.11.2012 00:17, schrieb David Kastrup:
Joram Berger joram.no...@gmx.de writes:
Would it be an idea to add … français as aliases to italiano?
According to my knowledge in French, the note names are the same and
bémol/dièse also fits with
Le 6 oct. 2012 à 09:10, d...@gnu.org a écrit :
Reviewers: janek,
Message:
On 2012/10/05 14:46:09, janek wrote:
please provide usage example(s). I suppose i like this idea, but
without
examples i don't know what exactly will be possible, and what won't be
possible.
Is it enough to say
Le 1 sept. 2012 à 18:25, Graham Percival a écrit :
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for
Le 24 juil. 2012 à 11:09, Graham Percival a écrit :
** Stability or not?
Stabilizing a language is a tricky process. If you do it too
early, then you’re stuck with whatever mistakes or poor design
decisions. If you do it too late, then there’s a large body of
documents in the
Le 6 mai 2012 à 23:54, Trevor Daniels a écrit :
I'm ok with using as a quick hack for things like convert-ly
rules, so I'm not arguing against David's patch. But I wouldn't
want to see becoming part of our basic vocabulary. I still
think that a n or z or \null would be more clear if
Le 7 mai 2012 à 13:58, David Kastrup a écrit :
\relative c' {
e2\p\ d\ s1*0\!
} \addlyrics { Oh no }
\relative c' {
e2\p\ d\ \!
} \addlyrics { Oh yes }
I think that closes the s1*0 vs. debate.
Because of its unexpected side effects, the s1*0 idiom must be banished.
Now that this is
Le 20 mars 2012 à 09:39, Marc Hohl a écrit :
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar lines either :-(
Is this a feasible
Le 26 janv. 2012 à 11:00, David Kastrup a écrit :
The bad news is that absolute pitch friends would have to call the \q
function (any better name for it?) explicitly. Since q is an input
convenience, and relative pitch is also an input convenience, I don't
think that there would be much of
Le 26 déc. 2011 à 10:18, m...@apollinemike.com a écrit :
http://lilypond.org/doc/v2.15/Documentation/contributor/understanding-pure-properties
Thanks for the pointer, Mike!
It's in contributing, but what I was doing is extending.
Something is missing e.g. in
Hi,
I have in my tool box some overriden stencil functions, in particular
for bar lines (to define custom baroque repeat bars).
Now, some things seem to have changed since 2.15.20, with respect to
pure things, which show strange behavior when overriding the BarLine
stencil callback, with a
Le 17 sept. 2011 à 17:41, m...@apollinemike.com a écrit :
I've been toying with the idea for some time now of making markups at all
levels behave more like grobs. It would require a massive code rewrite, but
it'd allow a much more uniform approach to exactly this sort of thing
(markups
Hi David,
This is so cool! and smart.
http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm
File scm/parser-ly-from-scheme.scm (right):
http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm#newcode36
scm/parser-ly-from-scheme.scm:36:
Le 9 juil. 2011 à 11:26, Reinhold Kainhofer a écrit :
Please review:
http://codereview.appspot.com/4641097
I have no remark, but thank you for doing this!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
A replacement function for text is a very good idea, and would be very
useful.
General comments:
A regtest for lyrics might be missing.
The current implementation of replacement function, in the C++ part,
need some rework.
An alternate design might be:
Define in the guile part the replacement
Le 4 mai 2011 à 13:18, Francisco Vila a écrit :
Is this the intended output? Looks as if a C (incomplete) chord is
created where there is no previous chord.
{ c'8 q }
What output can be intended when the input is wrong?
`q' a chord repetition chord, so you should use it after chords.
Le 3 mars 2011 à 10:52, Graham Percival a écrit :
On Wed, Mar 02, 2011 at 11:28:16PM +0100, Nicolas Sceaux wrote:
Le 2 mars 2011 à 08:08, Graham Percival a écrit :
Friday, 9am UK time.
Fret diagram fixes
http://codereview.appspot.com/4176056/
I'm still taking care of this one
Le 2 mars 2011 à 08:08, Graham Percival a écrit :
Friday, 9am UK time.
Fret diagram fixes
http://codereview.appspot.com/4176056/
I'm still taking care of this one... but my pace regarding LilyPond
dev is just really slow.
___
lilypond-devel
On 2011/02/17 18:39:21, Carl wrote:
On 2011/02/17 16:17:29, nicolas.sceaux wrote:
There is also a modification of the first fret label position, but
maybe this
is
a mistake. Is the label supposed to be vertically centered with the
fret line?
or the bottom of the label should be aligned
Le 27 févr. 2011 à 15:17, carl.d.soren...@gmail.com a écrit :
P.S. Can you propose your patch to git-cl to the git-cl maintainers? I
think that your approach is the right one. But I don't want to have us
in the position of needing a custom git-cl.
I thought git-cl was shipped in whatever
Reviewers: carl.d.sorensen_gmail.com,
Message:
Hi,
Here is a patch for fret diagrams, but as I have very little knowledge
of them I may well be wrong on some points.
First, it fixes sizing issues, when the size property is overridden: the
xo signs became too big, and too far from the first
http://codereview.appspot.com/2145047/diff/6001/scm/define-music-display-methods.scm
File scm/define-music-display-methods.scm (right):
http://codereview.appspot.com/2145047/diff/6001/scm/define-music-display-methods.scm#newcode927
scm/define-music-display-methods.scm:927: (format #f \\tempo
Le 5 janv. 2011 à 11:37, Mats Bengtsson a écrit :
Since I haven't been very active on the LilyPond lists the last year, I think
it would be appropriate to remove my name from the Current development team
list.
Mine too, please. I don't think I've done anything in this release.
Nicolas
Le 25 déc. 2010 à 01:42, Carl Sorensen a écrit :
I'd be happy if I could make something like
this work, as well:
default-string-tunings =
#`((guitar-tuning . ,(lily-scheme e, a, d g b e'))
(bass-tuning . ,(lily-scheme e,, a,, d, g,))
(mandolin-tuning . ,(lily-scheme g d' a' e'')))
Le 23 déc. 2010 à 06:13, Carl Sorensen a écrit :
Hi,
I'm trying to get an easier method of creating custom string tunings (see
http://article.gmane.org/gmane.comp.gnu.lilypond.general/60871)
I'd like to do one of the following:
\makeStringTuning #'violin-tuning g d' a' e''
If you
A short note about bookpart titles.
http://codereview.appspot.com/3667041/diff/13001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/3667041/diff/13001/Documentation/notation/input.itely#newcode538
2010/11/10 Jan Nieuwenhuizen jann...@gnu.org:
I've created a GUB installer for linux-x86
http://lilypond.org/schikkers-list/download/
Maybe LILYPOND_DATADIR environment variable should be set to
${INSTALLER_PREFIX}/share/lilypond/current by the main script, because
otherwise, the lilypond
Le 16 août 2010 à 01:33, carl.d.soren...@gmail.com a écrit :
LGTM.
Further info: This code has been in the file since
114c05e7b0e992de7dbdd0958d23eb8d2ab1eaae
(the file name at that time was scm/new-markup.scm).
I think that the alternate syntax has never been used in the main source
Le 28 juil. 2010 à 01:50, Reinhold Kainhofer a écrit :
Am Dienstag, 27. Juli 2010, um 18:19:39 schrieb Neil Puttock:
[..]
Why don't we move its definition to a separate file (e.g.,
`context-modifications-init.ly')? I'm sure there are other mods which
could usefully be defined (e.g.,
Le 17 juin 2010 à 17:31, David Kastrup a écrit :
Carl Sorensen c_soren...@byu.edu writes:
On 6/17/10 8:59 AM, David Kastrup d...@gnu.org wrote:
Hi,
I have a question about developing Emacs input and major modes for
Lilypond. What would be the right way to go forward for me?
I
Le 19 juin 2010 à 14:23, David Kastrup a écrit :
It would appear pretty nonsensical for me to ignore your work on lyqi
(which, in turn, appears to be slated to replace most of the existing
lilypond-mode functionality).
Indeed, I do not use LilyPond-mode anymore.
If it is compatible with
Le 19 juin 2010 à 16:15, David Kastrup a écrit :
Nicolas Sceaux nicolas.sce...@gmail.com writes:
Le 19 juin 2010 à 14:23, David Kastrup a écrit :
It would appear that you work on MacOSX or so. Can you check whether
some variation of the Midi test code using make-serial-process I posted
Le 13 juin 2010 à 15:22, David Kastrup a écrit :
If the worst Boris can come up with with regard to developer attitudes
are misconstrued postings of mine (heck, I'd think I can be enough of a
problem without reverting to such tactics) or replies to them, the
situation cannot be all that bad.
Le 7 juin 2010 à 21:35, reinhold.kainho...@gmail.com a écrit :
On 2010/06/07 19:17:27, Neil Puttock wrote:
On 2010/06/07 13:59:45, Reinhold wrote:
However, I fail to see where this is actually used...
It's called whenever Guile encounters the character sequence #{ for
parsing
LilyPond
Looks good!
http://codereview.appspot.com/969046/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Le 8 mai 2010 à 17:37, James E. Bailey a écrit :
On Sat, 8 May 2010, josé henrique padovani wrote:
Hi,
I have made some changes on my emacs lilypond-mode files to process lytex
files as suggested here
Le 29 avr. 2010 à 20:27, David Kastrup a écrit :
What type signatures would be actually permissable under the assumption
that they are supported by lexer and parser?
It is somewhat clear to me that we can't have markup-list followed by
markup in the arguments. Anything else?
I'd say, a
Le 26 avr. 2010 à 19:46, Carl Sorensen a écrit :
The problem is that the #{ throws off the emacs Scheme editor (at least I
assume that's what happens).
So there are two reasonably compliant choices for indentation.
#(define-music-function (parser location args)
Le 25 avr. 2010 à 08:13, Mark Polesky a écrit :
In both:
Notation 5.6.1 Substitution function syntax, and
Extending 2.1.2 Simple substitution functions,
it says that variables inside the music block part of a
music-function definition should be referenced using the
hash-cash notation
Le 4 avr. 2010 à 20:20, Joe Neeman a écrit :
On Sun, 2010-04-04 at 11:46 +0200, Nicolas Sceaux wrote:
+LY_DEFINE (ly_note_column__accidentals,
ly:note-column::accidentals,
+ 1, 0, 0, (SCM note_column),
+ Return the first accidentals found in @var{note_column},
or #f
Hi,
While working on a scheme engraver for adding harpsichord ornementations
to note heads, I'd like to be able to shift accidentals or dots attached
to notes.
Is it OK to add this `lily/note-column-scheme.cc' file?
note-column-scheme.patch
Description: Binary data
It makes it possible to
Le 4 avr. 2010 à 13:06, Neil Puttock a écrit :
On 4 April 2010 10:46, Nicolas Sceaux nicolas.sce...@gmail.com wrote:
Hi,
While working on a scheme engraver for adding harpsichord ornementations
to note heads, I'd like to be able to shift accidentals or dots attached
to notes.
Is it OK
Le 3 mars 2010 à 14:52, d...@gnu.org a écrit :
The use of modules oop and goops appears to me as part of a programming
practice at a different knowledge level than to be expected from the
audience of this example.
If I rewrite the example to get along without those modules, are there
Le 1 mars 2010 à 20:24, Marc Hohl a écrit :
Nicolas Sceaux schrieb:
Shouldn't there be a few words of explantion about using q and
\tabChordRepetition somewhere in 2.4.1 Common notation for fretted
strings?
Done. I hope it is ok.
Marc
http://codereview.appspot.com/224082/show
Le 1 mars 2010 à 10:00, Marc Hohl a écrit :
nicolas.sce...@gmail.com schrieb:
http://codereview.appspot.com/224082/diff/1/3
File ly/chord-repetition-init.ly (right):
http://codereview.appspot.com/224082/diff/1/3#newcode51
ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
Le 28 févr. 2010 à 10:18, Marc Hohl a écrit :
This solution might be very useful for tablature users, so I propose to store
the
definition for tab-repeat-chord in scm/tablature.scm and provide a
user-friendly shortcut for switching to tab-repeat-chord, perhaps
\tabChordRepetition or
Le 28 févr. 2010 à 12:35, Graham Percival a écrit :
On Sat, Feb 27, 2010 at 02:27:35PM -0800, Mark Polesky wrote:
...and hopefully the final draft.
http://www.markpolesky.com/norobots/compiling_new.itexi
http://www.markpolesky.com/norobots/compiling_new.itexi.html
Please review and let
Le 21 févr. 2010 à 15:11, Han-Wen Nienhuys a écrit :
On Sun, Feb 21, 2010 at 7:10 AM, nicolas.sce...@gmail.com wrote:
This is a proof-of-concept for instanciable scheme engravers, with
private instance slots.
Looks OK to me; maybe you'd want to pass in the context into the
function, so
http://codereview.appspot.com/224082/diff/1/3
File ly/chord-repetition-init.ly (right):
http://codereview.appspot.com/224082/diff/1/3#newcode51
ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
previous-chord location duration articulations)
It would be better to define a
Le 28 févr. 2010 à 17:11, Han-Wen Nienhuys a écrit :
On Sun, Feb 28, 2010 at 12:48 PM, Nicolas Sceaux
nicolas.sce...@gmail.com wrote:
On Sun, Feb 21, 2010 at 7:10 AM, nicolas.sce...@gmail.com wrote:
This is a proof-of-concept for instanciable scheme engravers, with
private instance slots
Le 27 févr. 2010 à 11:07, Marc Hohl a écrit :
the 'q' functionality has changed after 2.13.11 was released. Nicolas Sceaux
pushed a patch
to remove multiple fingerings etc., but the string information should be
copied, IMHO.
Precisely for the reason fingerings shall not be repeated
Reviewers: ,
Message:
Hi,
This is a proof-of-concept for instanciable scheme engravers, with
private instance slots.
There is at least one issue that I have to solve before this is
commitable, as this shows the following warning:
Warning : Attempting to remove nonexisting listener.
Warning :
Le 17 févr. 2010 à 07:27, Boris Shingarov a écrit :
Another change I was thinking about, is to redesign the API contracts
around interpret-markup-list. [...]
Boris,
The patch you submitted seems to me as a hack making the \score markup
command behaving differently from other markup commands,
Le 9 févr. 2010 à 14:42, David Kastrup a écrit :
I find that syntax tiresome to read. It requires evaluation and thus
does not have a close correspondence to print syntax.
That's partly because of the way the Scheme engraver example has been
written.
I'd much prefer it to use backquote
Le 9 févr. 2010 à 21:32, David Kastrup a écrit :
If you really must, you should probably use make-procedure-with-setter
in order to be able to use
(define (engraver-method engraver 'initialize) ...
According to:
Le 31 janv. 2010 à 12:50, Reinhold Kainhofer a écrit :
Before ~1800, the G clef was mainly used for violins, while all choral voices
and
most other instruments used either a C-clef of the bass clef, thus in
German, it is now usually called the Violin-Schlüssel. The English name
treble
Le 6 janv. 2010 à 13:35, Reinhold Kainhofer a écrit :
If so it is a pity because it would be quite nice to be able
to write things like:
\tocItem \markup { \fromproperty #'header:title }
I had the same problem a while ago, and there is a workaround to make header
fields available to a
Le 2 janv. 2010 à 11:57, Joe Neeman a écrit :
Any objections/comments? If not, I'll push in the next few days.
Please do, it looks good and is indeed more convenient.
Cheers,
Joe
On Tue, 2009-12-22 at 21:52 -0800, Joe Neeman wrote:
http://codereview.appspot.com/182042/show
This
Le 15 déc. 2009 à 07:20, Patrick McCarty a écrit :
On 2009-12-14, Harmath Dénes wrote:
On 2009.12.13., at 20:31, Patrick McCarty wrote:
2009/12/12 Harmath Dénes harmathde...@gmail.com:
And yes, this solved the problem! You're right, flex is among the
dependencies.
Concluding it, I think
On 2009/12/17 11:23:04, dak wrote:
Well, patch set 7 does that, but after rethinking this, I suppose I'd
call it a
mistake. Even if the option gets implemented for other constructs
than markup,
the time and memory savings are likely negligible. Checking for the
option is
likely causing
Le 13 déc. 2009 à 11:05, David Kastrup a écrit :
If in an existing score I later replace a q with an explicit chord all
the following q, qq and qqq will need changing too.
Yes. But q, qq, and qqq are not intended for use all across the score,
but rather in confined places. I am not sure
Hi,
I'm taking into account remarks from previous discussions regarding
chord repetition. In particular, I've get rid off the user-settable
memorization function: only chords (with angle brackets) are memorized.
This should be the more useful to users, and at the same time easy
enough for
Le 12 déc. 2009 à 14:01, David Kastrup a écrit :
{ G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // | }
Memorizing more than one chord/note (e.g. 3 chords/notes), and accessing
them using q, qq, qqq, would do it?
___
lilypond-devel
Le 6 déc. 2009 à 06:28, Werner LEMBERG a écrit :
Please see #924.
This one is fixed.
Concerning chord repetition, the issues that have been raised are:
- \relative mode
A patch is available for review at http://codereview.appspot.com/164096
If nobody objects I'll commit it within a few
Le 6 déc. 2009 à 13:09, Alexander Kobel a écrit :
I'm not sure, though, if such a policy-based version is possible via Scheme
(read: at runtime), since it seems to affect the parser.
This is what I was beginning to think about.
I will introduce a new customizable function for the
Hi,
I've uploaded a second patch set, which introduces a chord memorization
function.
When dealing with a simple_chord_element (simple notes, rests, etc) or a
note_chord_element (chord with several notes), the parser updates the
memorized chord by calling a user-settable memorization function
Le 5 déc. 2009 à 09:48, d...@gnu.org a écrit :
Currently I don't see a better way forward than using a special command
line option, something like -dindex-markup on documentation runs. As
far as I can see, everything else would come too late in the load order.
Nicolas' proposal to only
Reviewers: ,
Message:
Hi,
Here is a patch to make chord repetition work in \relative mode.
As I'm not sure how exactly music translation works, might someone
comment the RepeatedChord music type definition, and the relative
callback?
In particular, I don't know what the RepeatedChord types
Le 3 déc. 2009 à 13:26, Valentin Villenave a écrit :
On Thu, Dec 3, 2009 at 11:56 AM, nicolas.sce...@gmail.com wrote:
Here is a patch to make chord repetition work in \relative mode.
You forgot the link: http://code.google.com/p/lilypond/issues/detail?id=164096
The link really is
Hi,
When defining a user markup command, it would be better not to modify at
all the variables from the (lily) module, even if you took care of the
memory leak. Also, there is one file to be deleted, and the associated
\include to be removed from an init .ly file.
Nicolas
Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit :
I propose using a different separator for \parallelMusic than |, and allow
to include bar checks in there.
\parallelMusic as is is very fine and handy, but sometimes you want to enter
a whole phrase of two or three measures in a single
Hi,
Maybe this patch, as a first step, should focus on the unification of
the syntax of the two macros?
(define-markup-command (command-name layout props . arguments)
arguments-signature
#:properties property-bindings
#:allow-other-keys
#:rest body)
on the user side and:
Le 24 nov. 2009 à 17:51, d...@gnu.org a écrit :
It would make sense to apply URL:http://codereview.appspot.com/160048
first and make this patch work on top of that.
There may be cases where a separate property-bind like this is useful in
called routines, and the markup commands from the
2009/11/24 David Kastrup d...@gnu.org
file3.ly:
myInclude =
#(define-music-function (parser location file) (string?)
#{ \include $file #}
(make-music 'void #t))
\myInclude file2.ly
\markup \foo
Please ignore this case, it's broken. What I had in mind a bit
Le 23 nov. 2009 à 03:23, Carl Sorensen a écrit :
I think that what Graham meant was you should use @var{props} instead of
`props'.
Yes, I've finally understood what Graham meant, but after I've sent that
stupid message :)
___
lilypond-devel
Le 23 nov. 2009 à 01:03, David Kastrup a écrit :
The specification of category and properties makes the *-builtin-*
variants diverge syntactically from the user specified markup. Moving
those specifications into keyword arguments makes the builtin defining
macros upwards compatible with the
Le 23 nov. 2009 à 22:05, David Kastrup a écrit :
There is no clue just _how_ one should answer the questions or what they
mean.
Oh please... If you had read the git-cl README, which gives the complete
sequence, instead of writing (one more time) a lengthy useless mail,
then the patch would
Le 23 nov. 2009 à 19:03, David Kastrup a écrit :
Han-Wen Nienhuys hanw...@gmail.com writes:
On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup d...@gnu.org wrote:
lilypond a.ly b.ly
we want to reuse the built-in definitions, without changes effected
in a.ly leaking into the processing of
Le 22 nov. 2009 à 00:00, David Kastrup a écrit :
I'd be insterested to see an implementation of a single
`define-markup-command' for builtin and user defined markups, where
user defined commands do not pollute the (lily) module, and still are
available across file includes.
There is no
Reviewers: ,
Message:
Hi,
This patch improves (as I hope) the documentation on markup command
definition, by using more complete examples. It also tries to address
an issue that was raised on -devel, concerning the different syntax
between built-in and user-defined markup command definition.
Thank you Ian for the careful review.
Nicolas
http://codereview.appspot.com/157133/diff/1/2
File Documentation/extending/programming-interface.itely (right):
http://codereview.appspot.com/157133/diff/1/2#newcode1045
Documentation/extending/programming-interface.itely:1045: The
@code{layout}
Le 22 nov. 2009 à 17:10, Graham Percival a écrit :
On Sun, Nov 22, 2009 at 3:37 PM, nicolas.sce...@gmail.com wrote:
As I'm not (obviously) a native English speaker, comments on style are
most welcome.
Whenever I try to publish my comments, I get a 500 server error. :(
I'll summarize them
Le 21 nov. 2009 à 17:32, David Kastrup a écrit :
Carl Sorensen c_soren...@byu.edu writes:
I still don't like the divergence between define-markup-command and
define-internal-markup-command.
Agree. I think define-internal-markup-command makes for more readable
code. If we can consider
Le 17 nov. 2009 à 19:00, Carl Sorensen a écrit :
David,
I appreciate your work on this.
However, I am *not* in favor of moving in this direction to solve the
problems you correctly identified.
In my mind, the *last* thing we need is another opaque interface in
LilyPond, where in the
Le 16 nov. 2009 à 20:32, David Kastrup a écrit :
With very few exceptions (about 2 or 3, one being the harp-pedal code),
all the commands appear to use the let-binding mechanism.
Indeed, when I introduced the property binding thing I changed consistently
all markup command definitions. But it
Le 14 nov. 2009 à 09:29, David Kastrup a écrit :
Now the harp-pedal command defines the property signature
((size 1.0)
(harp-pedal-details)
(thickness 0.5))
So far, so fine. It
then calls make-harp-pedal without passing it those let-bound
variables. As far as I understand Scheme
On 2009/11/12 21:40:37, Carl wrote:
Nicolas,
It looks great! Thanks.
I have just a couple of suggestions for changes to the documentation
I've addressed your remarks concerning documentation in a new patch
http://codereview.appspot.com/154056
http://codereview.appspot.com/154056
On 2009/11/12 21:40:37, Carl wrote:
http://codereview.appspot.com/154056/diff/1/10#newcode1
ly/chord-repetition-init.ly:1: \version 2.13.8
Just a question. Why do this in a .ly file instead of in a .scm file?
This initializes the parser object, and thus shall be placed in a .ly
file, where
Le 12 nov. 2009 à 23:02, Neil Puttock a écrit :
Hi all,
Though strings are valid markup objects according to the type
predicate `markup?', the parser only recognizes full_markup objects as
valid for music functions, which means it's currently impossible to
pass both strings and markups unless
Le 13 nov. 2009 à 13:25, David Kastrup a écrit :
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Since the patch (as I understand it) ensures that q does not
duplicate
anything except the notes, q allows for
c e g8-. q-^ q-. q-^
etc., right? Obviously, this would *not* be
Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit :
The rules are already defined (albeit unsatisfactorily in my opinion):
Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
Le 12 nov. 2009 à 20:45, David Kastrup a écrit :
Why does define-internal-markup-command have more arguments than
define-markup-command?
I think you mean define-builtin-markup-command.
One is the doc, but there also seem to be
default properties. Why doesn't define-markup-command have
Hi,
Here is patch implementing the chord repetition shortcut that has been
discussed a few times, for review:
http://codereview.appspot.com/154056
I've chosed arbitrary defaults, which may be changed:
- the shortcut is `q';
- the function copying the previous chord only copies the chord
Le 28 oct. 09 à 08:37, David Kastrup a écrit :
Carl Sorensen c_soren...@byu.edu writes:
Isn't the problem that beams create melismata in vocal music, and you
don't want to have a line break in the middle of a melisma?
Baroque melisme can go on for lines. Do we have a way to discourage
Hi,
What is the new way of setting the next padding and spacing of an
individual line
(a markup line in that case)?
I am asking because there is a regression regarding markup lines: they
used to be
densely spaced, with no extra space between lines, but now they are
stretched,
which is
Le 18 oct. 09 à 20:34, Joe Neeman a écrit :
Does (or did) this really have the effect described in the comment? It
seems to me that this would have used extent-based spacing, so the
lines
o
y
l
would be unevenly spaced.
This was solved by using an appropriate markup list
Le 9 sept. 09 à 15:58, Kieren MacMillan a écrit :
The problem is, something like
\markup \uppercase \fromproperty #'header:title
fails. In general, I'd rather have the syntax be
\markup \uppercase { test }
instead of
\markup \uppercase #test
There is currently no workaround to this
Le 8 sept. 09 à 14:43, Kieren MacMillan a écrit :
Hello all,
1. Can anyone explain the logic behind the decision to make
\smallCaps and \caps do the same thing?
\caps used to change the font shape to caps, which is available in eg
ccm, but not in CenturySchoolBook. So when the later was
Reinhold Kainhofer reinh...@kainhofer.com a écrit :
is it okay to change note-name-lily-string (and octave-lily-string) to
define-public instead, so e.g. debugging statements can print out the human-
readable pitch name?
I guess nobody will object.
Le 30 août 09 à 03:20, Carl Sorensen a écrit :
On 8/29/09 7:01 PM, Reinhold Kainhofer reinh...@kainhofer.com
wrote:
You mean something like this patch:
http://codereview.appspot.com/112044
LGTM.
Just a question. In your regression test, you first define (add-one-
score
#f),
1 - 100 of 445 matches
Mail list logo
