*understood, of course
On Mon, 25 Apr 2022, 14:14 Luca Fascione, wrote:
> Yes I underground that, I was meaning for person's mental parsers, it
> helps that tokens (in an informal sense) always look the same
>
> L
>
> On Mon, 25 Apr 2022, 14:01 David Kastrup, wrote:
>
>> Luca Fascione writes:
Yes I underground that, I was meaning for person's mental parsers, it helps
that tokens (in an informal sense) always look the same
L
On Mon, 25 Apr 2022, 14:01 David Kastrup, wrote:
> Luca Fascione writes:
>
> > I think this is because it being an unquoted string (PERLfolk call these
> >
Luca Fascione writes:
> I think this is because it being an unquoted string (PERLfolk call these
> barewords) makes it feel more like an identifier, even if technically it's
> a string (for the time being).
> It also has some advantages for example it's easier to work with names
> being always
On Mon, Apr 25, 2022 at 10:47 AM David Kastrup wrote:
> it seems somehow wrong to see stuff without quotes
> that has not previously been defined.
>
Actually, while I think I follow why you're saying this, it's been my
experience
(both as a user and as a provider of software) that most people
Jean Abou Samra writes:
> Well, one reason is that this enables the documentation highlighter
> to highlight engraver names in a special color/style picked based on their
> nature of engravers (purple in HTML, italic bold in PDF), whereas
> between quotes they are just strings.
>
> I observed
Jean Abou Samra writes:
> Le 24/04/2022 à 16:09, David Kastrup a écrit :
>> I think we had this discussion at one time, possibly resulting in making
>> this have a unique style at least in documentation.
>
>
>
> The previous discussion I could find is
>
> https://codereview.appspot.com/6461098/
Le 24/04/2022 à 16:09, David Kastrup a écrit :
I think we had this discussion at one time, possibly resulting in making
this have a unique style at least in documentation.
The previous discussion I could find is
https://codereview.appspot.com/6461098/
Which does not exactly suggest that a
Le 24/04/2022 à 17:41, David Kastrup a écrit :
Werner LEMBERG writes:
\new Staff not \new "Staff"
\override NoteHead.color not \override "NoteHead"."color"
\repeat volta not \repeat "volta"
\change Staff not \change "Staff"
OK to drop that
Werner LEMBERG writes:
>> \new Staff not \new "Staff"
>> \override NoteHead.color not \override "NoteHead"."color"
>> \repeat volta not \repeat "volta"
>> \change Staff not \change "Staff"
>>
>> OK to drop that policy? I can easily make a patch to sed
> \new Staff not \new "Staff"
> \override NoteHead.color not \override "NoteHead"."color"
> \repeat volta not \repeat "volta"
> \change Staff not \change "Staff"
>
> OK to drop that policy? I can easily make a patch to sed out all
> existing
Jean Abou Samra writes:
> Folks,
>
> See
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1323#note_921986589
>
> The CG mandates quotes around the argument of \consists.
> (https://lilypond.org/doc/v2.23/Documentation/contributor/lilypond-formatting)
>
> I find that odd, since the quotes
Folks,
See
https://gitlab.com/lilypond/lilypond/-/merge_requests/1323#note_921986589
The CG mandates quotes around the argument of \consists.
(https://lilypond.org/doc/v2.23/Documentation/contributor/lilypond-formatting)
I find that odd, since the quotes are unnecessary, and there are lots
12 matches
Mail list logo
