Re: Careful with Texinfo markup on GitLab
Am Donnerstag, dem 06.01.2022 um 00:47 +0100 schrieb Jean Abou Samra: > Le 06/01/2022 à 00:44, Dan Eble a écrit : > > On Jan 5, 2022, at 17:42, Jean Abou Samra wrote: > > > request. The typical case is @lilypond, which mentions all 25+ > > > members of the LilyPond group … > > "You can prevent users from being added to a conversation and getting > > notified when anyone mentions a group in which those users are members." > > > > https://docs.gitlab.com/ee/user/group/#disable-group-mentions > > Interesting, thanks for the link. I'd be in favor of enabling this in > LilyPond. Done. signature.asc Description: This is a digitally signed message part
Re: Careful with Texinfo markup on GitLab
Le 06/01/2022 à 00:44, Dan Eble a écrit : On Jan 5, 2022, at 17:42, Jean Abou Samra wrote: request. The typical case is @lilypond, which mentions all 25+ members of the LilyPond group … "You can prevent users from being added to a conversation and getting notified when anyone mentions a group in which those users are members." https://docs.gitlab.com/ee/user/group/#disable-group-mentions Interesting, thanks for the link. I'd be in favor of enabling this in LilyPond.
Re: Careful with Texinfo markup on GitLab
On Jan 5, 2022, at 17:42, Jean Abou Samra wrote: > > request. The typical case is @lilypond, which mentions all 25+ > members of the LilyPond group … "You can prevent users from being added to a conversation and getting notified when anyone mentions a group in which those users are members." https://docs.gitlab.com/ee/user/group/#disable-group-mentions — Dan
Careful with Texinfo markup on GitLab
Prompted by https://gitlab.com/lilypond/lilypond/-/merge_requests/1102, a friendly reminder to everyone because it's an easy mistake to do: please be cautious when writing about Texinfo commands on GitLab. If you leave @something without special markup, it is taken as a mention and random people having accounts on GitLab with names @qq, etc. get mentioned and start receiving unsolicited notifications for comments on the merge request. The typical case is @lilypond, which mentions all 25+ members of the LilyPond group ... This collision is a bit unfortunate, but the fix is simple: always enclose Texinfo commands in backticks. For code suggestions, you can also use the dedicated feature of GitLab, which also makes it easier for the patch author to apply s/ / /-style changes. Read https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html about those. I've also opened https://gitlab.com/lilypond/lilypond/-/merge_requests/ to make new contributors aware of this. Thanks, Jean
PATCHES - Countdown for January 5th
Hello, Here is the current patch countdown list. The next countdown is scheduled for January 8th there is a large number of patches at the moment hence the reason I am adding an extra day again for the countdown. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: No patches in Push at this time. Countdown: !1105 spaceable-grob: pass Spring as const& - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1105 !1098 Hint at invisible bar lines in bar-line tests - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1098 !1095 Various doc issues - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1095 !1092 Doc-CG: update for automatic 'make check' in CI - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1092 !1090 musicxml2ly: set fallback for missing divisions - Tim Burgess https://gitlab.com/lilypond/lilypond/-/merge_requests/1090 !1086 Remove System members pointing to all-elements - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1086 !1079 Fix handling of *unspecified* returned from grob callbacks - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1079 Review: !1110 LM: Revise 'Tutorial' section - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1110 !1109 texi2html: Never use 'section ' prefix in links. - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1109 !1108 Bump libpng to 1.6.0 - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1108 !1106 simple-spacer: make solve() a const method - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1106 !1104 font-name-add-files: embed fonts unconditionally in test output - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1104 !1101 Doc-NR: add some more info about horizontal spacing - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1101 !1100 Doc-NR: improve formatting of MIDI instrument list - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1100 !1099 Draft:Make GridPoint and GridLine take a grid-id - Valentin Petzel https://gitlab.com/lilypond/lilypond/-/merge_requests/1099 !1093 Doc-NR: overhaul "Changing defaults" (part 1) - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1093 !1091 Doc-CG: update "Administrative policies" and "Issues" - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1091 New: !1102 Improve skyline debugging experience - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1102 Waiting: !1107 simple-spacer: compute rod_force exactly - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1107 !1103 output-distance: use ImageMagick's compare for visual comparisons - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/1103 !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 -- Regards James
Re: LilyPond | Various doc issues (!1095)
> Le 05/01/2022 14:04, Thomas Morley a écrit : > > > Am Mi., 5. Jan. 2022 um 13:28 Uhr schrieb Jean Abou Samra > : > > > > [Replying via the mailing list because it's unrelated to Werner's MR] > > Le 05/01/2022 12:59, Thomas Morley (@Thomas_Morley) > > a écrit : > > [1]Thomas Morley commented on a discussion on > > [2]Documentation/en/notation/notation-appendices.itely: > > Unrelated to this patch > > Though, [3]@jeanas > > They do. You might be confused by the change of presentation > > Indeed, I was wrong. Alas, in IR the former behaviour added to every > > interface: > > This grob interface is used in the following graphical object(s): > > list-of-grobs > > Now > > This grob interface is added dynamically to grobs of class > > Spanner/Item. > > is printed. > > I miss this list-of-grobs in the docs now. > > Any chance to get this back in the IR for item/spanner-interface or > > have this list somewhere in IR linked from thoe interfaces? > > That is feasible if we define what it means to be "used": basically > > should Footnote be included in this list or not since it will sometimes > > have it and sometimes not? Should grobs having the interface > > conditionally be in a separate list? The info on _allowable_ classes > > (and thus interfaces) is all in define-grobs.scm, it's just a matter of > > defining how it should be presented. > > Cheers, > > Jean > > References > > 1. https://gitlab.com/Thomas_Morley > > 2. https://gitlab.com/lilypond/lilypond/-/merge_requests/1095#note_801886836 > > 3. https://gitlab.com/jeanas > IIuc, only 5 grobs may be item _or_ spanner: > BalloonText > ControlPoint > ControlPolygon > Footnote > Parentheses > All others are definitely Items or Spanners. > > If so, then I'd suggest to have three lists to link to in IR: Items, > Spanners, Items-or-Spanners In what section of the IR would be the list of items-or-spanners though? Currently they all have the sticky-grob-interface, but it's an open bet whether they will continue to be characterized by an interface in the future because other use cases can be found (e.g. perhaps we would want to unify PercentRepeat and DoublePercentRepeat?). Maybe rather list them in spanner-interface and item-interface? """ This interface is used in in the following graphical objects: Foo, Bar, Baz In addition, this interface is conditionally supported by the following objects: Footnote, BalloonText, etc. """
Re: LilyPond | Various doc issues (!1095)
Am Mi., 5. Jan. 2022 um 13:28 Uhr schrieb Jean Abou Samra : > >[Replying via the mailing list because it's unrelated to Werner's MR] > >Le 05/01/2022 12:59, Thomas Morley (@Thomas_Morley) > a écrit : > >[1]Thomas Morley commented on a discussion on >[2]Documentation/en/notation/notation-appendices.itely: > >Unrelated to this patch >Though, [3]@jeanas > > They do. You might be confused by the change of presentation > >Indeed, I was wrong. Alas, in IR the former behaviour added to every >interface: > > This grob interface is used in the following graphical object(s): > list-of-grobs > >Now > > This grob interface is added dynamically to grobs of class > Spanner/Item. > >is printed. >I miss this list-of-grobs in the docs now. >Any chance to get this back in the IR for item/spanner-interface or >have this list somewhere in IR linked from thoe interfaces? > >That is feasible if we define what it means to be "used": basically >should Footnote be included in this list or not since it will sometimes >have it and sometimes not? Should grobs having the interface >conditionally be in a separate list? The info on _allowable_ classes >(and thus interfaces) is all in define-grobs.scm, it's just a matter of >defining how it should be presented. > >Cheers, > >Jean > > References > >1. https://gitlab.com/Thomas_Morley >2. > https://gitlab.com/lilypond/lilypond/-/merge_requests/1095#note_801886836 >3. https://gitlab.com/jeanas IIuc, only 5 grobs may be item _or_ spanner: BalloonText ControlPoint ControlPolygon Footnote Parentheses All others are definitely Items or Spanners. If so, then I'd suggest to have three lists to link to in IR: Items, Spanners, Items-or-Spanners Cheers, Harm
Re: LilyPond | Various doc issues (!1095)
Le 05/01/2022 11:30, Han-Wen Nienhuys <[1]hanw...@gmail.com> a écrit :
On Tue, Jan 4, 2022 at 7:55 PM Jean Abou Samra (@jeanas)
<[2]git...@mg.gitlab.com> wrote:
>
Jean Abou Samra commented on a discussion on
Documentation/en/notation/notation-appendices.itely:
>[about InstrumentName spanners]
>
3289
+@strong{Spanners} are a class of grobs that span up something in
3290
+the horizontal direction; in most cases they contain the word
On a personal note, I find the use of spanners misleading for these and
would very much like to see them converted to breakable items like bar
numbers, etc. That would be the main part
Converting them to breakable items adds 3 grobs per break-point, so it
has a certain cost. Since these items don't participate much in the
formatting process, there is little benefit to compensate for the
cost.
Yes, I know this is what prompted to convert these to spanners in the
first place. Of course, changing them back would require benchmarking.
If the overhead is noticeable, I suspect it could be at least
alleviated by adding is_live () checks in a bunch of places doing
expensive processing; that might be some work but it might also benefit
performance independently from instrument names and system start
delimiters. But I say this without being good at profiling or improving
performance in general.
References
1. mailto:hanw...@gmail.com
2. mailto:git...@mg.gitlab.com
Re: LilyPond | Various doc issues (!1095)
[Replying via the mailing list because it's unrelated to Werner's MR] Le 05/01/2022 12:59, Thomas Morley (@Thomas_Morley) a écrit : [1]Thomas Morley commented on a discussion on [2]Documentation/en/notation/notation-appendices.itely: Unrelated to this patch Though, [3]@jeanas They do. You might be confused by the change of presentation Indeed, I was wrong. Alas, in IR the former behaviour added to every interface: This grob interface is used in the following graphical object(s): list-of-grobs Now This grob interface is added dynamically to grobs of class Spanner/Item. is printed. I miss this list-of-grobs in the docs now. Any chance to get this back in the IR for item/spanner-interface or have this list somewhere in IR linked from thoe interfaces? That is feasible if we define what it means to be "used": basically should Footnote be included in this list or not since it will sometimes have it and sometimes not? Should grobs having the interface conditionally be in a separate list? The info on _allowable_ classes (and thus interfaces) is all in define-grobs.scm, it's just a matter of defining how it should be presented. Cheers, Jean References 1. https://gitlab.com/Thomas_Morley 2. https://gitlab.com/lilypond/lilypond/-/merge_requests/1095#note_801886836 3. https://gitlab.com/jeanas
Re: LilyPond | Various doc issues (!1095)
On Tue, Jan 4, 2022 at 7:55 PM Jean Abou Samra (@jeanas)
wrote:
>
> Jean Abou Samra commented on a discussion on
> Documentation/en/notation/notation-appendices.itely:
>[about InstrumentName spanners]
>
> 3289
>
> +@strong{Spanners} are a class of grobs that span up something in
>
> 3290
>
> +the horizontal direction; in most cases they contain the word
>
> On a personal note, I find the use of spanners misleading for these and would
> very much like to see them converted to breakable items like bar numbers,
> etc. That would be the main part
Converting them to breakable items adds 3 grobs per break-point, so it
has a certain cost. Since these items don't participate much in the
formatting process, there is little benefit to compensate for the
cost.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
