Re: GSoC update; Q's about final/draft modes, and triggering footnotes

On Mon, 2016-06-27 at 19:50 -0400, Jeffery Shivers wrote: > Hi fellow LP users, > > Firstly, thanks to Urs for all his guidance in the project so far. The > LaTeX package for scholarLY is inching forward still, and hopefully I > will share an initial version after a few more kinks have been worked

Re: GSoC update; Q's about final/draft modes, and triggering footnotes

Hi Jeffrey, It's good to hear about your progress! Just a thought about modes... On 06/27/2016 07:50 PM, Jeffery Shivers wrote: ***Final/"draft" Modes*** OpenLilyLib will ideally be used in final/draft/etc. modes in order to toggle between fancy/plain settings, or really whatever the user deci

Re: GSoC update; Q's about final/draft modes, and triggering footnotes

Am 29.06.2016 um 15:12 schrieb Paul: > Hi Jeffrey, > > It's good to hear about your progress! Just a thought about modes... > > On 06/27/2016 07:50 PM, Jeffery Shivers wrote: >> ***Final/"draft" Modes*** >> OpenLilyLib will ideally be used in final/draft/etc. modes in order to >> toggle between

Re: scheme-function to provide value for \include

On Tue, 28 Jun 2016 11:05:59 +0200 David Kastrup wrote: > Basically you are expecting something akin to the #include of the C > preprocessor to accept calls of functions defined in C for specifying > the file to include. Except that in C #include is significantly different from the rest of the C

Re: scheme-function to provide value for \include

Johan Vromans writes: > On Tue, 28 Jun 2016 11:05:59 +0200 > David Kastrup wrote: > >> Basically you are expecting something akin to the #include of the C >> preprocessor to accept calls of functions defined in C for specifying >> the file to include. > > Except that in C #include is significant

Re: scheme-function to provide value for \include

Am 29.06.2016 um 17:12 schrieb David Kastrup: > Johan Vromans writes: > >> On Tue, 28 Jun 2016 11:05:59 +0200 >> David Kastrup wrote: >> >>> Basically you are expecting something akin to the #include of the C >>> preprocessor to accept calls of functions defined in C for specifying >>> the file

Re: scheme-function to provide value for \include

On Wed, 29 Jun 2016 17:12:57 +0200 David Kastrup wrote: > The same with LilyPond. You can put \include in the midst of any > LilyPond construct without bothering about nesting. Try I meant "visually distinct". Lines starting with # are preprocessor only lines. \include is not visually distinct

Re: scheme-function to provide value for \include

Urs Liska writes: > Am 29.06.2016 um 17:12 schrieb David Kastrup: >> Johan Vromans writes: >>> >>> Except that in C #include is significantly different from the rest >>> of the C syntax. #-lines are all different and independent of >>> C-lines and syntax. >> >> The same with LilyPond. You can

Re: scheme-function to provide value for \include

Am 29.06.2016 um 17:54 schrieb David Kastrup: >> That's not what Johan is talking about. What he refers to is that the >> > C #include syntax *looks* completely different from regular C/C++ >> > code, so nobody will mistake it for a regular function call or >> > whatever. >> > >> > But \include *lo

ragged-first-top effect

Hi all, is there an automatic way to produce the opposite effect of ragged-last-bottom? I'm entering music from parts and have configured LilyPond to copy the original line and page breaking so I can easily navigate visually between original and LilyPond score. The parts I'm copying from start s

Re: ragged-first-top effect

Hi Urs, :-) Best, Simon On 29.06.2016 18:31, Urs Liska wrote: Hi all, is there an automatic way to produce the opposite effect of ragged-last-bottom? I'm entering music from parts and have configured LilyPond to copy the original line a

Re: GSoC update; Q's about final/draft modes, and triggering footnotes

> > Both lilypond and LaTeX have steep learning curves ​ One of the conditions of the package ​, in my mind,​ is to make ​its ​ usage possible at ​the ​highest​ ​ level, but configurable at the lowest. ​LaTeX is such a powerful utility, and in this case should really extend our workflows (and no

Re: GSoC update; Q's about final/draft modes, and triggering footnotes

On 06/29/2016 10:03 AM, Urs Liska wrote: Implementation-wise it is basically nothing to add another mode by simply allowing additional values for the "mode" option. Packages can also quite easily implement that by extending the conditionals in their functions to respond to more than two modes.

Re: ragged-first-top effect

Am 29.06.2016 um 18:31 schrieb Urs Liska: Hi all, is there an automatic way to produce the opposite effect of ragged-last-bottom? I don't think so. I'm entering music from parts and have configured LilyPond to copy the original line and page breaking so I can easily navigate visually between

Re: ragged-first-top effect

Am 30.06.2016 um 08:26 schrieb Knut Petersen: > Am 29.06.2016 um 18:31 schrieb Urs Liska: >> Hi all, >> >> is there an automatic way to produce the opposite effect of >> ragged-last-bottom? > > I don't think so. >> I'm entering music from parts and have configured LilyPond to copy the >> original