Re: Align metronome mark at time signature or first musical element. Fixes #684. (issue1579041)
Am Sonntag, 20. Juni 2010, 23:57:20 schrieb n.putt...@gmail.com: Here are some more comments for you. What happened to this patch? AFAICS, it has not been pushed to master, right? I'm just afraid that it might be forgotten, which would be very bad, since I need this in LilyPond, too... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Align metronome mark at time signature or first musical element. Fixes #684. (issue1579041)
Op dinsdag 27-07-2010 om 15:45 uur [tijdzone +0200], schreef Reinhold Kainhofer: What happened to this patch? AFAICS, it has not been pushed to master, right? I'm waiting for an ack. Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RemoveEmptyStaves and \with
Hi,
Context modifications inside an identifier are great, but in the case
of \RemoveEmptyStaves, there's a nasty surprise waiting for you: since
it's defined inside a layout block (as part of engraver-init.ly), it's
unusable within a music block.
\new Staff \with { \RemoveEmptyStaves } { c4 }
or
\new Staff \RemoveEmptyStaves { c4 } % even better, gets rid of nasty
\with block :)
- error: unknown escaped string: `\RemoveEmptyStaves'
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., \blankStaves for manuscript paper),
so a separate home for them makes sense.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
vim filetype off
Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. I need those lines to work around behavior that (I think) changed in very recent Vim versions. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. For background, see this thread: http://groups.google.com/group/vim_use/browse_thread/thread/c896684d209503e Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On Tue, Jul 27, 2010 at 11:15:36AM -0700, Patrick McCarty wrote: On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. Hmm. I'd prefer doing set runtimepath+= syntax on since that's IMO more understandable. According to that thread, it will have the same effect. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On 2010-07-27, Graham Percival wrote: On Tue, Jul 27, 2010 at 11:15:36AM -0700, Patrick McCarty wrote: On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. Hmm. I'd prefer doing set runtimepath+= syntax on since that's IMO more understandable. According to that thread, it will have the same effect. That doesn't work for me, unfortunately. Sourcing $VIMRUNTIME/vimrc_example.vim executes syntax on filetype plugin indent on which means that the runtimepath has already been searched before any commands in ~/.vimrc are executed. Looking into this a bit more, I found another incantation that works: set runtimepath+=/path/to/lilypond/current/vim runtime! ftdetect/lilypond.vim Would you prefer this over the filetype off/on version? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vim filetype off
On Tue, Jul 27, 2010 at 12:32:30PM -0700, Patrick McCarty wrote: On 2010-07-27, Graham Percival wrote: On Tue, Jul 27, 2010 at 11:15:36AM -0700, Patrick McCarty wrote: On Tue, Jul 27, 2010 at 10:49 AM, Graham Percival gra...@percival-music.ca wrote: Why on earth do we have a filetype off set runtimepath filetype on in the suggested .vimrc ? Those lines should be unnecessary. Basically, if I remove the filetype lines, the set runtimepath occurs too late in the filetype detection sequence to have any effect. By turning off filetype detection, modifying the runtimepath, and re-enabling filetype detection, the new runtimepath will be recognized. Hmm. I'd prefer doing set runtimepath+= syntax on since that's IMO more understandable. According to that thread, it will have the same effect. That doesn't work for me, unfortunately. Sourcing $VIMRUNTIME/vimrc_example.vim executes syntax on filetype plugin indent on which means that the runtimepath has already been searched before any commands in ~/.vimrc are executed. Looking into this a bit more, I found another incantation that works: set runtimepath+=/path/to/lilypond/current/vim runtime! ftdetect/lilypond.vim Would you prefer this over the filetype off/on version? Mao. When I read that syntax on called filetype on internally, I assumed that it would reload the directories, but apparently not. Huh. It also depends on whether you have a system-wide vimrc that contains syntax on... debian doesn't, but I'm guessing that ubuntu/redhat/etc would. Or at least, they /might/, so we can't rely on them not having this. ok, let's keep the filetype off set runtimepath+= filetype on version. People might wonder about it, but it's safe and works. Maybe some later version of vim will fix the runtimepath issue. :( Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Add user-init option to include a custom init snippet (not replacing the whole init file) (issue1901042)
http://codereview.appspot.com/1901042/diff/2001/3001 File ly/init.ly (right): http://codereview.appspot.com/1901042/diff/2001/3001#newcode26 ly/init.ly:26: #(if (ly:get-option 'user-init) user-include ? http://codereview.appspot.com/1901042/diff/2001/3001#newcode27 ly/init.ly:27: (begin remove http://codereview.appspot.com/1901042/diff/2001/3001#newcode28 ly/init.ly:28: (ly:parser-include-string parser indent http://codereview.appspot.com/1901042/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RemoveEmptyStaves and \with
Am Dienstag, 27. Juli 2010, um 18:19:39 schrieb Neil Puttock: Hi, Context modifications inside an identifier are great, but in the case of \RemoveEmptyStaves, there's a nasty surprise waiting for you: since it's defined inside a layout block (as part of engraver-init.ly), it's unusable within a music block. [..] 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., \blankStaves for manuscript paper), so a separate home for them makes sense. Good catch! I never used it for a single staff so far, but you are absolutely right... I also think there are several nice context modifications that we can provide pre-built, so users don't have to worry about which engravers to add/remove and which properties need to be set (the issue about placing marks above staff groups rather than the whole score comes to my mind, for example). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Accordion push and pull symbols
I have just pushed a patch containing accordion push and pull symbols. Because this modifies the font, in order to see its effects, you will need to do make clean make or rm mf/out/* make in order to rebuild the font and see the new symbols. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add user-init option to include a custom init snippet (not replacing the whole init file) (issue1901042)
Reviewers: Neil Puttock, http://codereview.appspot.com/1901042/diff/2001/3001 File ly/init.ly (right): http://codereview.appspot.com/1901042/diff/2001/3001#newcode26 ly/init.ly:26: #(if (ly:get-option 'user-init) On 2010/07/27 20:16:58, Neil Puttock wrote: user-include ? Hmm, actually, I don't like either user-init (indicates it's part of the init sequence and has similar uses as the --init command line option; also it sounds too technical) nor user-include (to me that sounds like setting an include path)... How about custom-definitions or user-definitions (no, sounds too much like it defines users)? http://codereview.appspot.com/1901042/diff/2001/3001#newcode27 ly/init.ly:27: (begin On 2010/07/27 20:16:58, Neil Puttock wrote: remove Oops, right. I had a debug statement there, too, which I removed in the second revision, so the begin is not necessary any more Description: Add user-init option to include a custom init snippet (not replacing the whole init file) This allows the user to apply the same set of options/definitions to different files. In particular, lilypond -duser-include=myinclude.ily file.ly will compile file.ly, but read and execut myinclude.ily before file.ly is processed. That way, e.g. global paper changes can be easily done, and a file can be run several times, each time with a different user-include file containing different settings. This feature is similar to the --init=DATEI feature, except that --init will replace the whole init sequence (thus your init file will copy all of lilypond's init.ly), while -duser-include will only add some definitions to the normal init sequence in init.ly (i.e. the file is included using scheme in init.ly). Please review this at http://codereview.appspot.com/1901042/show Affected files: M ly/init.ly M scm/lily.scm Index: ly/init.ly diff --git a/ly/init.ly b/ly/init.ly index 20416624c2f54c73ab03b9ef4246d42571f3d914..cda58c1ea243d600f24879dd7d706997a9983b39 100644 --- a/ly/init.ly +++ b/ly/init.ly @@ -22,6 +22,13 @@ #(define book-filename #f) #(define book-output-suffix #f) #(use-modules (scm clip-region)) + +#(if (ly:get-option 'user-init) + (begin + (ly:parser-include-string parser + (format \\include \~a\ (ly:get-option 'user-init))) +)) + \maininput %% there is a problem at the end of the input file Index: scm/lily.scm diff --git a/scm/lily.scm b/scm/lily.scm index 332f816b9030665775312557be792a822708eb11..247f7daab4b2a47fd95e6dc6afe071e708ff8b31 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -169,6 +169,8 @@ second. Dump results to `FILE.stacks' and `FILE.graph'.) (trace-scheme-coverage #f Record coverage of Scheme files in `FILE.cov'.) +(user-init #f +Global settings file, included before the score is processed.) (verbose ,(ly:command-line-verbose?) Value of the --verbose flag (read-only).) (warning-as-error #f ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add user-init option to include a custom init snippet (not replacing the whole init file) (issue1901042)
On Wed, Jul 28, 2010 at 12:43:08AM +, reinhold.kainho...@gmail.com wrote: On 2010/07/27 20:16:58, Neil Puttock wrote: user-include ? Hmm, actually, I don't like either user-init (indicates it's part of the init sequence and has similar uses as the --init command line option; also it sounds too technical) nor user-include (to me that sounds like setting an include path)... How about custom-definitions or user-definitions (no, sounds too much like it defines users)? Don't forget that this is aimed at lilypond users, not C programmers -- they're used to seeingwriting \include . I can't imagine many people getting confused with an include path. I suppose you could use file-include or include-file if you prefer, but I definitely encourage using include somewhere in the option name. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
