Le dim. 24 févr. 2019 à 23:09, John Mandereau a
écrit :
> > What about "TEXINFO_MANUALS_WITHOUT_WEB"?
>
> To make the contest a little bit more interesting, what about the
> following ones?
>
> NON_WEBSITE_TEXINFO_MANUALS
> TEXINFO_MANUALS_WITHOUT_WEBSITE
>
I uploaded a new patchset using NOT_WE
On Thu, Feb 21, 2019 at 7:44 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi Valentin,
>
> > Or, we just don’t bother and keep using (and recommending) # everywhere.
> > Thoughts?
>
> I use # everywhere I can, even where it’s not strictly necessary, in part
> because it visibly se
On 2019/02/28 14:22:35, Malte Meyn wrote:
Make it (nearly) as efficient as it was before.
“nearly” because (!line_breakable || !page_breakable) might need only
the line_breakable lookup. But I thought we have enough “if”s here
already …
https://codereview.appspot.com/351880043/
___
https://codereview.appspot.com/351880043/diff/20001/lily/page-turn-page-breaking.cc
File lily/page-turn-page-breaking.cc (right):
https://codereview.appspot.com/351880043/diff/20001/lily/page-turn-page-breaking.cc#newcode37
lily/page-turn-page-breaking.cc:37: bool page_breakable = scm_is_symbol
Greetings Malte,
nice catch! I’d been struggling with it for a while.
I believe that’s the last GCC warning we had (other than -Wconversion
warnings, of which there still are many).
V.
https://codereview.appspot.com/351880043/
___
lilypond-devel maili
On 2/25/2019 6:09 AM, Karlin High wrote:
I'm planing to ask on the Apple Developer Forum about possibilities for
Linux cross-compile - explaining our current situation, future options,
and software license concerns.
Starting discussion on Apple Developer Forum. Post is currently awaiting
mode
Hello,
Here is the current patch countdown list. The next countdown will be on
March 3rd.
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
Push:
No patches to push at this time.
Countdown:
5484 ma
On 2019/02/28 09:41:26, lemzwerg wrote:
[Oops, pressed the wrong button]
The idea of
\fermata 'foo
is its open endedness; you don't have to define a new command for a
new fermata
type. I'm a fan of a smaller set of multiplex commands instead of a
larger set
of specific macros (wh
On 2019/02/28 09:41:26, lemzwerg wrote:
[Oops, pressed the wrong button]
The idea of
\fermata 'foo
is its open endedness; you don't have to define a new command for a
new fermata
type. I'm a fan of a smaller set of multiplex commands instead of a
larger set
of specific macros (wh
[Oops, pressed the wrong button]
The idea of
\fermata 'foo
is its open endedness; you don't have to define a new command for a new
fermata type. I'm a fan of a smaller set of multiplex commands instead
of a larger set of specific macros (which a user could always define by
herself). However
On 2019/02/28 09:21:34, Malte Meyn wrote:
On 2019/02/28 09:15:44, lemzwerg wrote:
> LGTM. However, I'm not completely happy with it. What about making
\fermata
> (and \fermataMarkup) accept an optional argument that indicates the
type:
>
> \fermata 'short
> \fermata 'veryLong
I’m not
Reviewers: lemzwerg,
Message:
On 2019/02/28 09:15:44, lemzwerg wrote:
LGTM. However, I'm not completely happy with it. What about making
\fermata
(and \fermataMarkup) accept an optional argument that indicates the
type:
\fermata 'short
\fermata 'veryLong
I’m not sure whether that
LGTM. However, I'm not completely happy with it. What about making
\fermata (and \fermataMarkup) accept an optional argument that indicates
the type:
\fermata 'short
\fermata 'veryLong
\fermata "arbitrary markup stuff"
https://codereview.appspot.com/344160043/
_
13 matches
Mail list logo
