>> compiling the documentation of current git I get huge PDFs. For
>> example, the NR is now 44.7MByte – previously (in my case two months
>> ago), it was 7MByte.
>
> I can see the 44M number here, but I have extractpdfmark
> disabled. Can you confiirm it is being run?
It is, definitely.
The
On 6/23/20, Jonas Hahnfeld wrote:
> I knew that description and, honestly, that would be a show stopper for
> me reporting any issue to a project in 2020.
Why? Because mailing lists are a thing of the past in your view? :-)
Sending an e-mail to an open mailing list is much more universal and
Am 22.06.2020 um 20:26 schrieb Werner LEMBERG:
This looks strange. The red version is the newer one, right? What I
see is that the URLs are broken in the middle of lines, leaving huge
gaps to the right margin. This looks extremely ugly.
The index changes look fishy, too: Everything typeset
There are just three files, so I'll go ahead and put them in flower/.
One more minor thing--the files are .cpp and .h, which is a bit confusing
given they're not our standard extensions. Is it all right if I change the
extensions to .cc and .hh to match the rest of the files?
Thanks,
Owen
On
On Tue, Jun 23, 2020 at 10:26 PM Carl Sorensen
wrote:
> On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete wrote:
>
>
> >
> > (Also in response to Carl)
> > In Italy, we call this approach "fare la morale".
> > C's answer made P's words look like:
> >
> > "Hey, please develop this for me." And the
On Tue, Jun 23, 2020 at 10:32 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi Paolo,
>
> > I don't understand what you mean exactly, in the choral pieces.
>
> A cappella choral pieces don’t include piano music, and therefore don’t
> include any piano pedal markings, and therefore
On Tue, Jun 23, 2020 at 2:25 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen:
> > Accepted: the Bug Squad added it, or reviewed the item.
> > Started: a contributor is working on a fix. Owner should change to be
> > this contributor.
> >
> > Closed
Hi Paolo,
> I don't understand what you mean exactly, in the choral pieces.
A cappella choral pieces don’t include piano music, and therefore don’t include
any piano pedal markings, and therefore don’t use or need the feature you’re
describing — therefore, they are one of the [uncountable!]
On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete wrote:
>
>
>
> (Also in response to Carl)
> In Italy, we call this approach "fare la morale".
> C's answer made P's words look like:
>
> "Hey, please develop this for me." And the answer was, more or less (---> do
> the moral):
> "If you want it to
Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen:
> On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote:
> > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra:
> > > Hi,
>
>
> > > Actually, I think the while Status family of scoped labels will no longer
> > > need
On Tue, Jun 23, 2020 at 10:13 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi Paolo,
>
> > This issue is not *important for me*. It is an *essential* feature for
> any score.
>
> At best, one could argue that it‘s "an essential feature" for any score
> with multiple pedal
On Tue, Jun 23, 2020 at 9:53 PM Jean Abou Samra wrote:
> Paolo,
>
>
> I really think Carl did not intend to be harsh. He even explicitely tried
> to
> avoid making you taking it as an offence:
>
> > I'm trying not to be mean in this answer, but to explain the way
> > LilyPond development works.
Hi Paolo,
> This issue is not *important for me*. It is an *essential* feature for any
> score.
At best, one could argue that it‘s "an essential feature" for any score with
multiple pedal spanners [of different types] that cross line breaks. It’s
demonstrably false that it’s "an essential
On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra:
> > Hi,
> > Actually, I think the while Status family of scoped labels will no longer
> > need to exist. Status::Fixed and Status::Verified are replaced as above.
> > In
Paolo,
Le 23/06/2020 à 21:32, Paolo Prete a écrit :
On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen
wrote:
Paolo,
On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote:
2) Considering that a Pedal cautionary is *essential* in *every* serious
score, I really encourage the developers to fix
Am 23.06.2020 um 21:30 schrieb Han-Wen Nienhuys:
On Tue, Jun 23, 2020 at 8:44 PM Werner LEMBERG wrote:
Folks,
compiling the documentation of current git I get huge PDFs. For
example, the NR is now 44.7MByte – previously (in my case two months
ago), it was 7MByte.
Then I used gs 9.21, now
Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra:
> Hi,
>
> Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit :
> > Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
> > > On 6/22/20, Jonas Hahnfeld wrote:
> > > > In short, I'd like to propose that we replace the
On Tue, Jun 23, 2020 at 1:32 PM Paolo Prete wrote:
>
>
>
> On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen
> wrote:
>>
>> Paolo,
>>
>> On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote:
>> >
>>
>> >
>> > 2) Considering that a Pedal cautionary is *essential* in *every* serious
>> > score, I
On Tue, Jun 23, 2020 at 9:55 AM Jonas Hahnfeld via Discussions on
LilyPond development wrote:
>
> Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb:
> > Thanks, everyone! It looks like jsoncpp should work well for LilyPond.
> >
> > I don't have experience with adding files from one project
On Tue, Jun 23, 2020 at 9:32 PM Jean Abou Samra wrote:
> Hi Paolo,
>
> Le 23/06/2020 à 21:09, Carl Sorensen a écrit :
> > Paolo,
> >
> > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete
> wrote:
> >> 2) Considering that a Pedal cautionary is *essential* in *every* serious
> >> score, I really
Hi Paolo,
Le 23/06/2020 à 21:09, Carl Sorensen a écrit :
Paolo,
On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote:
2) Considering that a Pedal cautionary is *essential* in *every* serious
score, I really encourage the developers to fix this in the development
branch. I forward this post to
On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen
wrote:
> Paolo,
>
> On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote:
> >
>
> >
> > 2) Considering that a Pedal cautionary is *essential* in *every* serious
> > score, I really encourage the developers to fix this in the development
> > branch. I
On Tue, Jun 23, 2020 at 8:44 PM Werner LEMBERG wrote:
>
>
> Folks,
>
>
> compiling the documentation of current git I get huge PDFs. For
> example, the NR is now 44.7MByte – previously (in my case two months
> ago), it was 7MByte.
>
> Then I used gs 9.21, now I use version 9.52; I guess this is
Paolo,
On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote:
>
>
> 2) Considering that a Pedal cautionary is *essential* in *every* serious
> score, I really encourage the developers to fix this in the development
> branch. I forward this post to the devel ml.
There is no way to "encourage the
Hi,
Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit :
Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
On 6/22/20, Jonas Hahnfeld wrote:
In short, I'd like to propose that we replace the labels Fixed_x_y_z
with milestones x.y.z and use these to track which issues were fixed
Folks,
compiling the documentation of current git I get huge PDFs. For
example, the NR is now 44.7MByte – previously (in my case two months
ago), it was 7MByte.
Then I used gs 9.21, now I use version 9.52; I guess this is the
culprit since I don't think that any other program in my
On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:
> Hi Paolo,
> See: http://lsr.di.unimi.it/LSR/Item?id=1023
> Cheers,
> PIerre
>
>
Hi Pierre,
I already saw your workaround but, as said in the previous email, it has
unwanted side effects.
The
On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote:
>>
> Pretty much that: You can only have one label from the same scope, and
> assigning a second automatically removes the old (cf. Patch::*). I
> actually agree that multiple Type's might be useful. If others are in
> favor as well, we can just
Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
> On 6/22/20, Jonas Hahnfeld wrote:
> > In short, I'd like to propose that we replace the labels Fixed_x_y_z
> > with milestones x.y.z and use these to track which issues were fixed
> > for a particular release. This has the
On 6/22/20, Jonas Hahnfeld wrote:
> In short, I'd like to propose that we replace the labels Fixed_x_y_z
> with milestones x.y.z and use these to track which issues were fixed
> for a particular release. This has the advantage of a) less labels
> which makes the drop-downs more usable and b) the
Am 22.06.2020 um 22:55 schrieb Michael Käppler:
Am 22.06.2020 um 20:26 schrieb Werner LEMBERG:
I'm not sure what the best solution would be...
I just put texi2dvi from texinfo git into scripts/build and
adjusted stepmake/stepmake/texinfo-rules.make
to use it. It works(tm) and is IMHO a cleaner
Hi James,
Am Dienstag, den 23.06.2020, 08:00 +0100 schrieb James:
> Hello
>
> On 22/06/2020 18:33, Jonas Hahnfeld wrote:
> > In short, I'd like to propose that we replace the labels Fixed_x_y_z
> > with milestones x.y.z and use these to track which issues were fixed
> > for a particular release.
Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb:
> Thanks, everyone! It looks like jsoncpp should work well for LilyPond.
>
> I don't have experience with adding files from one project to another.
> Jonas, is this "Amalgamated" procedure what you were describing?
>
Hello
On 22/06/2020 18:33, Jonas Hahnfeld wrote:
In short, I'd like to propose that we replace the labels Fixed_x_y_z
with milestones x.y.z and use these to track which issues were fixed
for a particular release.
Just so you know I have just gone through all the 'Fixed_' labels this
morning
34 matches
Mail list logo
