> Which brings me to my second point, that I share Jean's concern and
> the reasoning about supporting three TeX engines and appreciated him
> asking if we could drop support for some as pretty much the first
> comment on the merge request, less than a day after it was posted:
> https://gitlab.com
On 2022-11-21 9:26 pm, Werner LEMBERG wrote:
!1734 Resurrect banana commas - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1734
Heh, "banana". But seriously, many thanks for the quick fix,
Werner!
:-) Someone on the list (or in a MR/bug issue) used this word for the
sh
>> The problem is the startup time of luatex. For processing our more
>> than 1000 small snippets that are embedded in the final
>> documentation (as PDF files), this sums up.
>
> Why would the snippets cause multiple startups of luatex?
Oops, brain fart, I mixed it up ghostscript. Sorry for
>> !1734 Resurrect banana commas - Werner Lemberg
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1734
>
> Heh, "banana". But seriously, many thanks for the quick fix,
> Werner!
:-) Someone on the list (or in a MR/bug issue) used this word for the
shape, IIRC, and I found it catchy.
On 2022-11-21 4:46 pm, Colin Campbell wrote:
!1734 Resurrect banana commas - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/1734
Heh, "banana". But seriously, many thanks for the quick fix, Werner!
-- Aaron Hill
Here is the current countdown report.
The next cpountdown will begin on November 23rd.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!1734 Resurrect banana commas - Werner Lemberg
https://gitlab.com/lilypon
On 21/11/2022 16:41, Jean Abou Samra wrote:
I think we are losing sight of the question at hand. The origin of this
“users vs developers” debate is that Wols criticized me for seemingly
minimizing the importance of typography for my own reading experience of
the manual compared to maintenance t
Hi all,
there has been a huge number of messages in this thread today.
Unfortunately, in my opinion, many of them contained points that are
factually wrong, fundamentally contradict any best practices for
sustainable and maintainable open source projects, or are not relevant
to this discussion. I
Werner LEMBERG writes:
>> I'd say that for a 80-100page document it's maybe somewhere between
>> 50% and twice as slow. Still it's a several seconds build that
>> becomes more several seconds. I'm not sure it crosses important
>> workflow thresholds [1], it certainly didn't in my own use.
>
> T
Luca Fascione writes:
> On Mon, Nov 21, 2022 at 2:06 PM Werner LEMBERG wrote:
>
>> The thing is: Something might happen if I'm not available, for
>> whatever reasons. It definitely *is* a high maintenance cost if a
>> single developer is responsible...
>>
>
> But that's true of any one feature:
Le 21 nov. 2022 à 16:53, Luca Fascione a
écrit :
On Mon, Nov 21, 2022 at 2:06 PM Werner LEMBERG <[1]w...@gnu.org> wrote:
The thing is: Something might happen if I'm not available, for
whatever reasons. It definitely *is* a high maintenance cost if a
single
> I'd say that for a 80-100page document it's maybe somewhere between
> 50% and twice as slow. Still it's a several seconds build that
> becomes more several seconds. I'm not sure it crosses important
> workflow thresholds [1], it certainly didn't in my own use.
The problem is the startup time
>> The thing is: Something might happen if I'm not available, for
>> whatever reasons. It definitely *is* a high maintenance cost if a
>> single developer is responsible...
>
> But that's true of any one feature: I build you a nice template
> library to do in and you find a bug
> while I'm .
On Mon, Nov 21, 2022 at 2:06 PM Werner LEMBERG wrote:
> The thing is: Something might happen if I'm not available, for
> whatever reasons. It definitely *is* a high maintenance cost if a
> single developer is responsible...
>
But that's true of any one feature: I build you a nice template libra
On Mon, Nov 21, 2022 at 2:23 PM Werner LEMBERG wrote:
>
> > Sorry, luatex is like 10yrs old, what's the need for xetex again?
>
> Some issues that potentially speak against using luatex:
>
> * LuaTeX's OpenType support is still in flux and sometimes buggy. The
> future is probably luatex-hb, u
On Mon, Nov 21, 2022 at 2:05 PM Jean Abou Samra wrote:
> > Le 21 nov. 2022 à 13:46, Luca Fascione a écrit :
> > Sorry, luatex is like 10yrs old, what's the need for xetex again?
> Are you asking this to me (judging from To:/Cc:)? I don’t see one.
>
No, I was asking the group in general.
Editing
> Sorry, luatex is like 10yrs old, what's the need for xetex again?
Some issues that potentially speak against using luatex:
* LuaTeX's OpenType support is still in flux and sometimes buggy. The
future is probably luatex-hb, using the 'HarfBuzz' library for
OpenType font handling.
* The ma
>> build problems are fixed by developers, not users, sometimes very
>> painfully, and using time that they could spend on other tasks.
>
> If Werner's change breaks the build, surely he'll be the first one
> to argue it's on him to fix it (possibly with help to learn how
> tonfix whatever he d
> Le 21 nov. 2022 à 13:46, Luca Fascione a écrit :
>
> Sorry, luatex is like 10yrs old, what's the need for xetex again?
Are you asking this to me (judging from To:/Cc:)? I don’t see one.
> Maybe I could justify pdftex (I really don't quite see it, but maybe)
As said on the MR, it is fast
Sorry, luatex is like 10yrs old, what's the need for xetex again? Maybe I
could justify pdftex (I really don't quite see it, but maybe) but xetex
seems just arbitrary... Or do you mean for a transition period?
What's the oldest system that this Lilypond would be used on? What's the
youngest texliv
On Mon, 21 Nov 2022, 13:34 Jean Abou Samra, wrote:
>
> build problems are fixed by developers, not users, sometimes very
> painfully, and using time that they could spend on other tasks.
>
If Werner's change breaks the build, surely he'll be the first one to argue
it's on him to fix it (possibl
> Le 21 nov. 2022 à 13:36, Werner LEMBERG a écrit :
>
> To clarify what Jean wants if he mentions 'maintenance burden': We are
> talking about a potential change checking for all three TeX variants
> in the `configure` script, or rather, what TeX versions should be
> tested against.
>
> The pa
> Note that I personally haven’t objected to declaring LuaTeX
> supported. I do object to keeping XeTeX in that case.
To clarify what Jean wants if he mentions 'maintenance burden': We are
talking about a potential change checking for all three TeX variants
in the `configure` script, or rather,
> Le 21 nov. 2022 à 13:22, Wols Lists a écrit :
> On 20/11/2022 15:05, Jean Abou Samra wrote:
>> Le 20/11/2022 à 15:40, Werner LEMBERG a écrit :
>>> I'm too tired to defend superior typographical output
>>> again and again since it is obviously only me who sees a benefit in
>>> it.
>> It's not
On 20/11/2022 15:05, Jean Abou Samra wrote:
Le 20/11/2022 à 15:40, Werner LEMBERG a écrit :
I'm too tired to defend superior typographical output
again and again since it is obviously only me who sees a benefit in
it.
It's not that I don't see any benefit at all in superior
typographical outpu
> Le 21 nov. 2022 à 12:34, Kevin Barry a écrit :
> I agree with most of what Luca said.
>
> I'm sure whatever the maintenance burden is, Werner is likely to bear it
> himself. Supporting newer versions of tools may even help (cf. texi2html
> and texi2any). Either way, since he principally takes
On Mon, Nov 21, 2022 at 12:03:34PM +0100, Luca Fascione wrote:
> I must say I don't understand this discussion.
I agree with most of what Luca said.
I'm sure whatever the maintenance burden is, Werner is likely to bear it
himself. Supporting newer versions of tools may even help (cf. texi2html
an
I must say I don't understand this discussion.
If we as the developers of Lilypond recommend users move onto
lilypond-next, shouldn't we also keep current with versions of software
around us?
After all, we upgrade platforms, compilers, python interpreters, guile
interpreters and all that, what exa
28 matches
Mail list logo
