Re: scorio contact?
At least, two of the (former?) scorio people (Johannes Feulner and Dominik Hörnel) were attending in Salzburg, if that helps to get in contact with them, and Johannes is in the list of my FB friends IIRC. On Thu, May 21, 2020 at 10:42 PM Han-Wen Nienhuys wrote: Are the scorio folks on this list? Is scorio still being worked on? Does anyone know how it makes stencils appear on their web interface? I am looking into cleaning up how we generate PS and SVG files, and I don't want to make their lives harder than necessary. -- Han-Wen Nienhuys - [1]hanw...@gmail.com - [2]http://www.xs4all.nl/~hanwen References 1. mailto:hanw...@gmail.com 2. http://www.xs4all.nl/~hanwen
scorio contact?
Are the scorio folks on this list? Is scorio still being worked on? Does anyone know how it makes stencils appear on their web interface? I am looking into cleaning up how we generate PS and SVG files, and I don't want to make their lives harder than necessary. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: LilyPond GSoC logistics
Am 21. Mai 2020 19:21:27 MESZ schrieb Owen Lamb : >> >> To preserve your code within LilyPond it probably makes sense if you >put >> your code into a private (but public) branch of the upstream lilypond >> repository (i.e., not a gitlab clone of it), for example >> 'dev/lamb/GSoC-2020'. >> > >I'm a bit confused here, so let me just make sure I understand what >you're >saying > >I'll be making a new branch titled "dev/lamb/GSoC-2020" in the GitLab >repository, based off the current master. It will be "private" in the >sense >that it's my personal workspace (hence the "lamb" namespace), but it >will >be "public" in the sense that it will be visible to the public. It will >not >be merely "a gitlab clone" of the master branch, since it is a new >branch >entirely. Did I interpret that correctly? Yes, that should be how it is. I think the message should read "not a fork". A fork is a personal copy that you need when you don't have push access to a repository. A "clone" in Git-speak is the local copy you are actually working in. Of course you will have such a clone. HTH Urs > >I'm pretty new to git, so please excuse my lack of expertise! -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: LilyPond GSoC logistics
> > To preserve your code within LilyPond it probably makes sense if you put > your code into a private (but public) branch of the upstream lilypond > repository (i.e., not a gitlab clone of it), for example > 'dev/lamb/GSoC-2020'. > I'm a bit confused here, so let me just make sure I understand what you're saying. I'll be making a new branch titled "dev/lamb/GSoC-2020" in the GitLab repository, based off the current master. It will be "private" in the sense that it's my personal workspace (hence the "lamb" namespace), but it will be "public" in the sense that it will be visible to the public. It will not be merely "a gitlab clone" of the master branch, since it is a new branch entirely. Did I interpret that correctly? I'm pretty new to git, so please excuse my lack of expertise!
Re: [RFC] Enabling GitLab CI
Am Donnerstag, den 21.05.2020, 18:25 +0200 schrieb David Kastrup: > > If we think contention will be a problem, we cannot do the proposal. > > There's no sane "mixed bag": As outlined initially, we would 1) > > require CI for merge requests, and 2) disable direct pushes to > > master. This includes patchy which has no special permissions as far > > as GitLab is concerned. > > Sure, it would be the merge request of staging to master that would > trigger the CI then. Interesting approach, I still had patchy in the equation. We'd still need to target master initially so that James gets the CI results for the countdown process. But this could be the easiest workaround in case a developer with many patches hits contention and would be unable to merge otherwise. I'm for keeping this in mind, but not making it a rule. signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys: >> On Thu, May 21, 2020 at 1:17 PM James wrote: >> > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: >> > > so a next step might be making the countdown process more >> > > continuous. >> > >> > What does that mean - even conceptually? >> >> My idea is that patches could enter 'countdown' stage throughout the >> day, and when they do a 48 hour period waiting period kicks in. This >> means the moment they are mergable will be more spread out throughout >> the day. >> >> My main worry is that the CI process (make doc) will be forced to run >> on machines with less CPU power, and the whole test/doc cycle would >> take 1 or even 2 hours. If CI takes 2 hours, we'd realistically only >> be able to merge 8 changes on a day. > > The full pipeline (build & test & doc) takes less than 1 hour on > GitLab's shared runners with a single core. I think it's a safe bet > that it can't get worse than that. If LilyPond itself gets slower by a > factor of 2, I'd call that a regression in general. If it is by the translation team doubling the number of supported languages... Actually, if translations were all kept up to date, we'd probably need less time for "make doc" since then most of the translations would work with the same code examples. -- David Kastrup
Re: [RFC] Enabling GitLab CI
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: >> > > Jonas Hahnfeld writes: >> > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> > > > > The "traffic jam" problem could be avoided by retaining the option of >> > > > > pushing to staging. That would occur without CI, but one could >> > > > > occasionally trigger the merge with CI on staging to have everything >> > > > > in >> > > > > it migrate to master. Since staging would be used by the more >> > > > > experienced people desiring to bunch their work before testing, the >> > > > > triggering could also happen manually by whoever thinks he has pushed >> > > > > enough stuff to staging to give it a whirl. >> > > > >> > > > That's not really how CI works. With our policy of FF merges, what >> > > > happens if some MR get merged directly to master and some sit in >> > > > staging? You'd probably rebase staging which triggers another CI >> > > > pipeline and doesn't buy you much. >> > > >> > > It buys you that several commits are bunched in staging and are treated >> > > in bulk. At least I think it does. >> > >> > No, it doesn't: The MRs must pass CI individually before it can be >> > merged. >> >> I did not propose to have CI on staging. > > In the current proposal, CI tests those merge requests that target > master. If we allowed others targeting staging without CI, we would be > unable to rely on automated testing. The automated testing would be done upon asking Gitlab to merge staging into master. > If we think contention will be a problem, we cannot do the proposal. > There's no sane "mixed bag": As outlined initially, we would 1) > require CI for merge requests, and 2) disable direct pushes to > master. This includes patchy which has no special permissions as far > as GitLab is concerned. Sure, it would be the merge request of staging to master that would trigger the CI then. > FWIW I don't see much contention at the current rate of development. Well yes. And if there were much contention, we'd not likely stay in the free plan for CI anyway. > See also my other reply to Han-Wen. -- David Kastrup
Re: [RFC] Enabling GitLab CI
Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld writes: > > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > > > > > The "traffic jam" problem could be avoided by retaining the option of > > > > > pushing to staging. That would occur without CI, but one could > > > > > occasionally trigger the merge with CI on staging to have everything > > > > > in > > > > > it migrate to master. Since staging would be used by the more > > > > > experienced people desiring to bunch their work before testing, the > > > > > triggering could also happen manually by whoever thinks he has pushed > > > > > enough stuff to staging to give it a whirl. > > > > > > > > That's not really how CI works. With our policy of FF merges, what > > > > happens if some MR get merged directly to master and some sit in > > > > staging? You'd probably rebase staging which triggers another CI > > > > pipeline and doesn't buy you much. > > > > > > It buys you that several commits are bunched in staging and are treated > > > in bulk. At least I think it does. > > > > No, it doesn't: The MRs must pass CI individually before it can be > > merged. > > I did not propose to have CI on staging. In the current proposal, CI tests those merge requests that target master. If we allowed others targeting staging without CI, we would be unable to rely on automated testing. This essentially reduces the net win of the whole thing to zero. If we think contention will be a problem, we cannot do the proposal. There's no sane "mixed bag": As outlined initially, we would 1) require CI for merge requests, and 2) disable direct pushes to master. This includes patchy which has no special permissions as far as GitLab is concerned. FWIW I don't see much contention at the current rate of development. See also my other reply to Han-Wen. signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys: > On Thu, May 21, 2020 at 1:17 PM James wrote: > > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: > > > so a next step might be making the countdown process more > > > continuous. > > > > What does that mean - even conceptually? > > My idea is that patches could enter 'countdown' stage throughout the > day, and when they do a 48 hour period waiting period kicks in. This > means the moment they are mergable will be more spread out throughout > the day. > > My main worry is that the CI process (make doc) will be forced to run > on machines with less CPU power, and the whole test/doc cycle would > take 1 or even 2 hours. If CI takes 2 hours, we'd realistically only > be able to merge 8 changes on a day. The full pipeline (build & test & doc) takes less than 1 hour on GitLab's shared runners with a single core. I think it's a safe bet that it can't get worse than that. If LilyPond itself gets slower by a factor of 2, I'd call that a regression in general. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
On Thu, May 21, 2020 at 1:17 PM James wrote: > > > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: > > so a next step might be making the countdown process more > > continuous. > > What does that mean - even conceptually? My idea is that patches could enter 'countdown' stage throughout the day, and when they do a 48 hour period waiting period kicks in. This means the moment they are mergable will be more spread out throughout the day. My main worry is that the CI process (make doc) will be forced to run on machines with less CPU power, and the whole test/doc cycle would take 1 or even 2 hours. If CI takes 2 hours, we'd realistically only be able to merge 8 changes on a day. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: [RFC] Enabling GitLab CI
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> > > The "traffic jam" problem could be avoided by retaining the option of >> > > pushing to staging. That would occur without CI, but one could >> > > occasionally trigger the merge with CI on staging to have everything in >> > > it migrate to master. Since staging would be used by the more >> > > experienced people desiring to bunch their work before testing, the >> > > triggering could also happen manually by whoever thinks he has pushed >> > > enough stuff to staging to give it a whirl. >> > >> > That's not really how CI works. With our policy of FF merges, what >> > happens if some MR get merged directly to master and some sit in >> > staging? You'd probably rebase staging which triggers another CI >> > pipeline and doesn't buy you much. >> >> It buys you that several commits are bunched in staging and are treated >> in bulk. At least I think it does. > > No, it doesn't: The MRs must pass CI individually before it can be > merged. I did not propose to have CI on staging. > So it only buys you another test when staging progresses to master. That was the first, not another test in my plan. -- David Kastrup
Re: [RFC] Enabling GitLab CI
Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > > > The "traffic jam" problem could be avoided by retaining the option of > > > pushing to staging. That would occur without CI, but one could > > > occasionally trigger the merge with CI on staging to have everything in > > > it migrate to master. Since staging would be used by the more > > > experienced people desiring to bunch their work before testing, the > > > triggering could also happen manually by whoever thinks he has pushed > > > enough stuff to staging to give it a whirl. > > > > That's not really how CI works. With our policy of FF merges, what > > happens if some MR get merged directly to master and some sit in > > staging? You'd probably rebase staging which triggers another CI > > pipeline and doesn't buy you much. > > It buys you that several commits are bunched in staging and are treated > in bulk. At least I think it does. No, it doesn't: The MRs must pass CI individually before it can be merged. So it only buys you another test when staging progresses to master. signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: >> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: >> > > > before merging. As we only allow fast-forward merges, this means each >> > > > MR has received testing in the form it hits master. This would >> > > > effectively replace the current setup of pushing to staging. >> > > >> > > I'm for this. >> > >> > Thanks. What do others (David, Han-Wen, Valentin) think about this? >> > There's certainly room for improvement, but with an initial setup I can >> > start writing documentation. >> >> The "traffic jam" problem could be avoided by retaining the option of >> pushing to staging. That would occur without CI, but one could >> occasionally trigger the merge with CI on staging to have everything in >> it migrate to master. Since staging would be used by the more >> experienced people desiring to bunch their work before testing, the >> triggering could also happen manually by whoever thinks he has pushed >> enough stuff to staging to give it a whirl. > > That's not really how CI works. With our policy of FF merges, what > happens if some MR get merged directly to master and some sit in > staging? You'd probably rebase staging which triggers another CI > pipeline and doesn't buy you much. It buys you that several commits are bunched in staging and are treated in bulk. At least I think it does. > I don't mind deciding that we don't want to enable CI right now. The > purpose of bringing this up now is that I didn't want to spend time > documenting something that's going to change the next day. In my > opinion, having CI and merging to master feels more "natural" than the > staging setup. And finally if contention proves to be a problem, we > can still revert to the old setup. I was more going for the mixed bag right now :) -- David Kastrup
Re: [RFC] Enabling GitLab CI
Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > > > before merging. As we only allow fast-forward merges, this means each > > > > MR has received testing in the form it hits master. This would > > > > effectively replace the current setup of pushing to staging. > > > > > > I'm for this. > > > > Thanks. What do others (David, Han-Wen, Valentin) think about this? > > There's certainly room for improvement, but with an initial setup I can > > start writing documentation. > > The "traffic jam" problem could be avoided by retaining the option of > pushing to staging. That would occur without CI, but one could > occasionally trigger the merge with CI on staging to have everything in > it migrate to master. Since staging would be used by the more > experienced people desiring to bunch their work before testing, the > triggering could also happen manually by whoever thinks he has pushed > enough stuff to staging to give it a whirl. That's not really how CI works. With our policy of FF merges, what happens if some MR get merged directly to master and some sit in staging? You'd probably rebase staging which triggers another CI pipeline and doesn't buy you much. I generally agree that there's a potential for contention. However we're aiming for ~1h of CI which means we can merge many more patches than we currently have per countdown. Merging patches doesn't need to happen the minute James' message hits lilypond-devel, I think doing this some time until the next countdown should be fine. I don't mind deciding that we don't want to enable CI right now. The purpose of bringing this up now is that I didn't want to spend time documenting something that's going to change the next day. In my opinion, having CI and merging to master feels more "natural" than the staging setup. And finally if contention proves to be a problem, we can still revert to the old setup. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
Jonas Hahnfeld writes: > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: >> On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: >> > before merging. As we only allow fast-forward merges, this means each >> > MR has received testing in the form it hits master. This would >> > effectively replace the current setup of pushing to staging. >> >> I'm for this. > > Thanks. What do others (David, Han-Wen, Valentin) think about this? > There's certainly room for improvement, but with an initial setup I can > start writing documentation. The "traffic jam" problem could be avoided by retaining the option of pushing to staging. That would occur without CI, but one could occasionally trigger the merge with CI on staging to have everything in it migrate to master. Since staging would be used by the more experienced people desiring to bunch their work before testing, the triggering could also happen manually by whoever thinks he has pushed enough stuff to staging to give it a whirl. -- David Kastrup
convert-ly doesn't find lilylib
Hi, with master as of 15de2c8874262c2c0a9f2cc3beee5070c766dde4 $ cat buggy.ly \version "2.18.2" c1 $ ~/GIT/Mentor/out/bin/convert-ly -e TEST.ly Traceback (most recent call last): File "/home/jcharles/GIT/Mentor/out/bin/convert-ly", line 65, in import lilylib as ly ModuleNotFoundError: No module named 'lilylib' $ Cheers, -- Jean-Charles
Re: [RFC] Enabling GitLab CI
On 21/05/2020 12:02, Han-Wen Nienhuys wrote: so a next step might be making the countdown process more continuous. What does that mean - even conceptually? The countdown is specifically to allow everyone some time to breathe and digest patches submitted without the fear of having to be always-on and missing anything. I understand the 'jam' on countdown days, but honestly how is having a countdown every day (or continuously) going to change that? I think this was touched on before, when you came back into the development group didn't seem to get the point of what my role was for in regard to countdowns. I know that other developers have been frustrated with the countdown as well (at least at first) and while I appreciate that not all patches need that much of a review, it has been evident even in these these last few weeks that some things you have felt trivial or self-evident has lead to much discussion and debate. Also note that I currently do a 2 day countdown now (mainly because I have the scope working from home), the original idea of the countdown was for 4 days as that was felt to give enough time for everyone to see a submitted patch AND give it consideration AND continue to develop at the same time. We have more devlopers and many more patches than then and we're alreadyt working on a shorter countdown. So please remember the point of countdown, it's a deliberate braking system to stop rushing things through that some might want to care about. That doesn't mean I need to do it, but neither does it mean we need 'continuous' countdown (whatever that means). Thanks. James
Re: mirror GitLab -> Savannah
Am Samstag, den 16.05.2020, 11:49 +0200 schrieb Jonas Hahnfeld: > Am Donnerstag, den 14.05.2020, 20:31 +0200 schrieb Jonas Hahnfeld: > > To keep this short: I'd like to enable push mirroring from GitLab to > > Savannah for the following branches [1]: > > - master > > - release/unstable > > - stable/* > > - translation* > > This is a feature of GitLab and runs automatically in the background: > > https://gitlab.com/help/user/project/repository/repository_mirroring.md > > > > I've already created a new lilypod_bot user and requested access to the > > Savannah project. Unless somebody objects, I'll configure GitLab > > accordingly and paste the generated SSH key for the Savannah user. > > Update on this one: I've tried to configure the necessary options, but > apparently it's broken on gitlab.com since this week: > https://gitlab.com/gitlab-org/gitlab/-/issues/216619 The GitLab devs have identified and remedied the problem, the mirroring is now working correctly since a few days. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Enabling GitLab CI
On Thu, May 21, 2020 at 12:34 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > > before merging. As we only allow fast-forward merges, this means each > > > MR has received testing in the form it hits master. This would > > > effectively replace the current setup of pushing to staging. > > > > I'm for this. > > Thanks. What do others (David, Han-Wen, Valentin) think about this? > There's certainly room for improvement, but with an initial setup I can > start writing documentation. Let's try it. I think the FF requirement might lead to traffic jams on countdown days, so a next step might be making the countdown process more continuous. But we don't have to address that problem right now. > Jonas -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: [RFC] Enabling GitLab CI
Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > before merging. As we only allow fast-forward merges, this means each > > MR has received testing in the form it hits master. This would > > effectively replace the current setup of pushing to staging. > > I'm for this. Thanks. What do others (David, Han-Wen, Valentin) think about this? There's certainly room for improvement, but with an initial setup I can start writing documentation. Jonas signature.asc Description: This is a digitally signed message part
Re: Markup vertical alignment
On 5/21/20, James wrote: > A bit like this (still open) issue? > https://sourceforge.net/p/testlilyissues/issues/1322/ > ;) Uh, that’s precisely one I’m trying to close… :-) https://gitlab.com/lilypond/lilypond/-/merge_requests/59 > Mind you I was sure there was some discussion in dev-lilypond a few > years ago about /null - whether to keep it or change it or something Interesting. You’ve obviously been paying more attention than I have, the only thing I could find is https://codereview.appspot.com/4124056/ (but it’s a doc patch, not really related). > there was a similar discussion about renaming it with regard > to related 'null-ish' tricks s1*0 and <> Oh, that would make sense. Cheers, -- V.
PATCHES - Countdown for May 21st
Hello,
Here is the current patch countdown list. The next countdown will be on
May 23rd
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!58 Doc typos: remove double backslash in `@code{}` - Valentin Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/58
!54 Some documentation cleanups - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/54
!52 Optimize text replacement - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/52
!50 Remove some ancient long-unused cruft - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/50
!49 Remove operator= from Scheme_hash_table - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/49
!43 Issue #5234: Avoid writing a MIDI file when there is no music - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/43
!42 Resolve "(*location*) returning no valid value while parsing
embedded scheme" - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/42
!38 GNUmakefile.in: remove remove-test-changed support - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/38
Countdown:
!64 fixcc.py: update for python3 - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/64
!59 Doc: use \new and \context more consistently (fix #1322) - Valentin
Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/59
!44 Change ly_chain_assoc_get to use eq? - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/44
Review:
!65 musicxml2ly: support multiple elements - Valentin
Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/65
!57 Enable GitLab CI - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/57
!53 Allow CSS-style colors anywhere - Valentin Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/53
!48 skyline: minor performance tweaks - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/48
!47 Stop smobifying Transform - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/47
New:
!67 Doc: update NR 1.8.2.3 Text alignment - Valentin Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/67
!63 Fix #967: add a --svg command line option. - Valentin Villenave
https://gitlab.com/lilypond/lilypond/-/merge_requests/63
!60 WIP: Resolve "Use templates for lots of conversions to SCM and back"
- David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/60
Waiting:
No patches in Waiting at this time.
***
Regards,
James
Re: Markup vertical alignment
Hello, On 20/05/2020 19:36, Valentin Villenave wrote: By the way, isn’t it time to retire \null? Or at least change its oh-so-deceptive name. (\point might be confusing in another way, though; I’m open to suggestions.) Cheers, -- V. A bit like this (still open) issue? https://sourceforge.net/p/testlilyissues/issues/1322/ ;) Mind you I was sure there was some discussion in dev-lilypond a few years ago about /null - whether to keep it or change it or something (!?) - but I am having a hard time finding it in the archives (I may be mis-remembering but there was some big(ish) patch around /null and spacing and there was a similar discussion about renaming it with regard to related 'null-ish' tricks s1*0 and <> I'll keep hunting to see if I can find it (in case it saves some time re-hashing old ground). James
