Then that means we have to use that oo code in the NR? I am not sure I
follow. I'd rather not please.
Andrew
On 28/08/2020 1:48 pm, Werner LEMBERG wrote:
I side step the whole thing by having dynamic expanable macros in
the text editor.
But this gives overlong lines, which I want to avoid
>> Because right now LSR is still using this version.
>
> Then that means we have to use that oo code in the NR? I am not sure
> I follow. I'd rather not please.
Right now I'm checking the NR for bad typography in the PDF version,
which usually means overlong lines. A lot of snippets are
>> However, saying
>>
>> \oo VeryLong.Grob.PropertyToBeChanged = foo
>>
>> for this (and only this) snippet is just fine.
>
> I don't think that it makes sense for snippets to introduce
> convenience shorthands unless the snippet in itself tries is about
> showcasing the shorthand. It detracts
Hi Harm,
Thank you very much, it solves all my problems at once, much appreciated!
It tells me how to engrave my last bar, and why I had to do what I did for
my first bar :)
I was indeed confusing merged notes for collisionning ones; I wasn't aware
of the concept / term / mechanics behind.
Have
Werner LEMBERG writes:
>>> Because right now LSR is still using this version.
>>
>> Then that means we have to use that oo code in the NR? I am not sure
>> I follow. I'd rather not please.
>
> Right now I'm checking the NR for bad typography in the PDF version,
> which usually means overlong
Werner LEMBERG writes:
>> oo = #(define-music-function (parser location prop value)
>>(symbol-list? scheme?)
>> #{ \once \override #prop = #value #})
>>
>> should likely work fine in 2.18.
>
> Thanks! Aaron provided this version
>
> oo = #(define-music-function (parser
Hi all,
I would need to start working on my project again, using luatex, lilypond,
lyluatex and lilyglyphs. But lilyglyphs appears to be missing from the
ubuntu packages. This summer I upgraded to 20.04 though, and I found out to
my surprise, lilyglyphs is missing. It is present in 'eoan' though.
On Fri, Aug 28, 2020 at 8:52 AM Werner LEMBERG wrote:
> >> However, saying
> >>
> >> \oo VeryLong.Grob.PropertyToBeChanged = foo
> >>
> >> for this (and only this) snippet is just fine.
> >
> > I don't think that it makes sense for snippets to introduce
> > convenience shorthands unless the
I am running Ubuntu 18.04, Lilypond 2.21.4, emacs 25.2.2
Ever since I started my current Lilypond project, I have been
getting occasional segmentation faults when compiling. Until today I
thought it was something to do with errors or inconsistencies in my
Lilypond code, and I have been able to
Werner LEMBERG writes:
>>> However, saying
>>>
>>> \oo VeryLong.Grob.PropertyToBeChanged = foo
>>>
>>> for this (and only this) snippet is just fine.
>>
>> I don't think that it makes sense for snippets to introduce
>> convenience shorthands unless the snippet in itself tries is about
>>
On Aug 27, 2020, at 12:06, Kieren MacMillan
wrote:
>
> Hello all!
>
> I'm hoping to [finally!] wrestle my large and currently unwieldy collection
> of stylesheets into public-worthy form. This effort is really the perfect
> time to [finally!] implement a real stylesheet system in
Werner LEMBERG writes:
>>> Well, we have to make a compromise. The PDF document has a small
>>> line width, and you can't scroll horizontally...
>>
>> Then you just have to wrap the line.
>
> I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think
> that wrapping is suboptimal and
Hi David,
That certainly is strange behaviour. A segmentation fault occurs when
a program tries to access a segment of memory that it isn't allowed
to. It's usually the result of memory bugs in the program. If it's a
bug in emacs, which looks possible, then I am not sure what you will
be able to
I was also getting occasional seg. faults with 21.1.4. I would add a little
more to the code and they would go away. Since I was able to finish that
project I didn’t worry about it and it certainly worth the trouble to try too
create a MWE. I also use Emacs but I just alt-tab to another
>> Well, we have to make a compromise. The PDF document has a small
>> line width, and you can't scroll horizontally...
>
> Then you just have to wrap the line.
I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think
that wrapping is suboptimal and reduces legibility I hope you
On 28/08/2020 20:42, Werner LEMBERG wrote:
Well, we have to make a compromise. The PDF document has a small line
width, and you can't scroll horizontally...
Theoretically, the snippet could be printed with a smaller font size,
but this doesn't look very pretty IMHO. I consider the `\oo`
No. I'm against it. Introducing abbreviations into examples is a
slippery slope and sets a bad precedent. In my scores I use \t for
\tuplet, but I would never inflict that on any public example, even to
save space. Wrapped lines are not a visual or semantic issue to me at
least. Please don't
>> Well, we have to make a compromise. The PDF document has a small line
>> width, and you can't scroll horizontally...
>>
>> Theoretically, the snippet could be printed with a smaller font size,
>> but this doesn't look very pretty IMHO. I consider the `\oo`
>> shorthand both innocuous and
Hi Bart,
thanks for reminding.
Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
> Hi all,
> I would need to start working on my project again, using luatex,
> lilypond, lyluatex and lilyglyphs. But lilyglyphs appears to be
> missing from the ubuntu packages. This summer I upgraded to
> Maybe
>
> \void \displayLilyMusic
> \once
> \propertyTweak color #red
> \propertyTweak font-size #3
> \propertyTweak direction #UP Voice.Slur
>
> helps?
It does, thanks a lot! I didn't have this function on my radar, and
it isn't documented in the NR at all.
Attached a version using
> No. I'm against it. Introducing abbreviations into examples is a
> slippery slope and sets a bad precedent. In my scores I use \t for
> \tuplet, but I would never inflict that on any public example, even
> to save space. Wrapped lines are not a visual or semantic issue to
> me at least.
21 matches
Mail list logo
