Do not build PDFs from the website Texinfo sources (issue 363930043 by john.mander...@gmail.com)

2019-02-21 Thread lemzwerg
https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmakefile File Documentation/GNUmakefile (right): https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmakefile#newcode54 Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB = $(filter-out web,$(TEXINFO_MANUALS)) LGTM

Re: C++ cleanup : get rid of some compilation warnings (issue 353880043 by v.villen...@gmail.com)

2019-02-21 Thread John Mandereau
David Kastrup wrote: > Huh.  Maybe the Ubuntu compilation of gcc/g++ disabled some warnings? > > g++ --verbose > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none > OFFLOAD_TARGET_DEFAULT=1 > Target: x86_64-l

Re: Re[2]: Please test gub

2019-02-21 Thread John Mandereau
On February 21 2019 18:07 +, Trevor wrote: > Added with Developer privileges. Welcome! Thanks Trevor; at the end of the issue creation, an auto-generated email bounced with """ Your mail to 'Testlilyissues-auto' with the subject [testlilyissues:issues] #5482 Do not build PDFs from the web

Re: C++ cleanup : get rid of some compilation warnings (issue 353880043 by v.villen...@gmail.com)

2019-02-21 Thread David Kastrup
John Mandereau writes: > v.villen...@gmail.com wrote: > >> page-turn-page-breaking.cc: In instantiation of 'bool is_break(T*) >> [with >> T = Grob]': >> page-turn-page-breaking.cc:50:54: required from here >> page-turn-page-breaking.cc:38:3: warning: operation on '*0' may be >> undefined [-Wseq

Re: C++ cleanup : get rid of some compilation warnings (issue 353880043 by v.villen...@gmail.com)

2019-02-21 Thread John Mandereau
v.villen...@gmail.com wrote: > page-turn-page-breaking.cc: In instantiation of 'bool is_break(T*) > [with > T = Grob]': > page-turn-page-breaking.cc:50:54: required from here > page-turn-page-breaking.cc:38:3: warning: operation on '*0' may be > undefined [-Wsequence-point] > if (turnable >

Re: Syntax: numbers prefixed with # or not

2019-02-21 Thread Valentin Villenave
On 2/21/19, David Kastrup wrote: > baba = -.4 Indeed. That’s probably rare enough that we could get away with a @knownissues in the right place(s), though… Right now, the new ability to have #-less numbers (and strings, although my recent patch changes that) isn’t documented anywhere but the git

Re[2]: Please test gub

2019-02-21 Thread Trevor
John, you wrote 21/02/2019 17:19:23 Could somebody please add me (login john-mandereau) on SourceForge so I can upload a patch using the expected workflow? Added with Developer privileges. Welcome! Trevor ___ lilypond-devel mailing list lilypond-dev

Re: Please test gub

2019-02-21 Thread John Mandereau
Le mer. 20 févr. 2019 à 00:26, John Mandereau a écrit : > It's certainly possible, it must boil down to filtering out web from > TEXI_FILES or TEXINFO_MANUALS, and give this to PDF_FILES definition in > the makefiles. I'm testing a patch for this. > Could somebody please add me (login john-mande

Re: Syntax: numbers prefixed with # or not

2019-02-21 Thread David Kastrup
Valentin Villenave writes: > Greetings, > > Alongside issue #5473, I’ve started investigating whether numbers > still require to be prefixed with #. In music, something like -.4 has entirely different meaning than in layout blocks. To wit: baba = -.4 \void \displayScheme #baba \layout { bub

Re: Syntax: numbers prefixed with # or not

2019-02-21 Thread Kieren MacMillan
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 sets arguments apart for easy parsing [by me]. Not sure if that’s useful input for you? Best, Kieren.

Syntax: numbers prefixed with # or not

2019-02-21 Thread Valentin Villenave
Greetings, Alongside issue #5473, I’ve started investigating whether numbers still require to be prefixed with #. AFAICS, the only ones that still do are in markups and all markups commands, but hardly anywhere else; which _could_ make LilyPond syntax a tiny bit easier to grasp for new users… Or w