Re: Feedback wanted: syntax highlighting in the LilyPond documentation

[David Kastrup]

Flaming Hakama by Elaine  writes:

> In this sense, it seems like the place that has the most potential use
> for helping people distinguish different data types is where the
> syntax is the most complicated and dense, which is in music entry.
>
> The ability to quickly distinguish articulations, dynamics, notes, and
> durations seems like it would probably be most useful to people
> reading examples in docs, since that is the most unusual aspect of
> lilypond syntax.

I find splitting a8 into different colors about as helpful for reading
music as coloring note stems differently would be for reading score
sheets: there is a standard place they are attached to anyway and there
is no particular reason to look elsewhere.

It would be much more useful to highlight note lengths separated by
space but still common to a preceding note or rest, like

\drummode { bd4 r r 4. 8 }

where the 4. is sucked into the second r likely unintentionally.
Highlighting this is helpful.  When there is a general "angry fruit
salad" flavor pervading the highlighting with lots of colors everywhere,
there just is not a lot of attention one can draw to actually important
things.

-- 
David Kastrup

Re: Feedback wanted: syntax highlighting in the LilyPond documentation

[Flaming Hakama by Elaine]

>
> Am Sonntag, 2. Jänner 2022, 01:06:35 CET schrieb David Kastrup:
> > Jean Abou Samra  writes:
> > > Hi all,
> > >
> > > There is an ongoing proposal to add syntax highlighting
> > > in LilyPond's documentation. Since it is a notable change
> > > to the documentation reading experience, user feedback would
> > > be appreciated. You can browse a syntax-highlighted version
> > > of the notation manual here:
> > >
> > > http://abou-samra.fr/highlighting-demo/notation/index.html
> > >
> > > For comparison, this is the current notation manual:
> > >
> > > https://lilypond.org/doc/v2.23/Documentation/notation/index.html
> > >
> > > The main questions are: what do you think of the principle?
> > > And is the color scheme good enough?
> >
> > I just followed the discussion without much attention because I did not
> > think that it would affect me whether or not there was syntax
> > highlighting.  That probably was a mistake.  Taking a random
> example:___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user



In general, I think syntax highlighting is a good idea.

However, I would say that the backslash prefix already provides a level of
baked-in syntactic self-highlighting.  Using color to reinforce anything
with a backslash seems unnecessary, and potentially dilutes the
opportunities to have a meaningful palette, since a smaller palette is
easier to comprehend.

I'm not sure the distinction between categories of things like \layout,
\override, and \relative is what adds value.

However, I will say that if it is possible to tag it as such, we should.
It is better to have the ability to style against it in case someone wants
to customize it.  It is easy enough to have the default styling show them
all the same if that ends up being what is desired.

What I do find useful is the coloring of reserved words, such as objects
like Staff, properties like baseMoment, string literals, bare words that
are expected arguments, like volta, and clef names.

In this sense, it seems like the place that has the most potential use for
helping people distinguish different data types is where the syntax is the
most complicated and dense, which is in music entry.

The ability to quickly distinguish articulations, dynamics, notes, and
durations seems like it would probably be most useful to people reading
examples in docs, since that is the most unusual aspect of lilypond syntax.


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Problem controlling page numbers in bookparts

[Valentin Petzel]

Hello Vincent,

The first problem seems to be something internal to Lilypond. Basically the 
header markup seems to get called for the 0th page even though we don’t need 
it. But as only positive integers can be formatted as roman this causes a 
problem if the first bookpart is set to roman.

But we can easily fix this as shown in lines 37 and 39 in the fixed first 
example.

For your second problem: The code you are using is messing up the order of 
things. Basically it first performs the first-page check and then does the 
resetting stuff. This means that that if print-first-page-number is ##f the 
reset call is not evaluated on the first page. Apparently this fucks up this 
system. So the solution is to move the first page check after the reset part, 
as shown in lines 63-65 and 79-81 in the fixed second example.

Your third problem is basically a result from the same thing. Due to the order 
the first page check is done before resetting. This means that at the time the 
first page is checked it does not have page number 1. Changing the order again 
fixes this.

Cheers,
Valentin\version "2.22.1"

#(define part-first-pages '(0))

#(define (part-first-page? layout props)
  (= (chain-assoc-get 'page:page-number props -1)
 (ly:output-def-lookup layout 'first-page-number)))

#(define (reset-part-first-page layout props arg)
"Returns page-number-string, starting every bookpart with page-number 0.
Relying on the extern defined `part-first-pages'.
"
  (set! props (prepend-alist-chain 'part-first-page '(0) props))

  (let* ((real-page-number (chain-assoc-get 'page:page-number props -1))
 (parts-page-number (- real-page-number (car part-first-pages

(if (part-first-page? layout props)
(set! part-first-pages (cons (1- real-page-number) part-first-pages)))

(set! props
  (cons
(list
  (cons 'page:page-number-string (number->string parts-page-number))
  (cons 'page:page-number parts-page-number))
props))
(interpret-markup layout props arg)))

#(define ((print-part-first-page-as-one number-type) layout props arg)

  (set! props
(cons
  (list
(cons 'page:page-number-string
  (let ((page-number
 (chain-assoc-get 'page:page-number props -1)))
;(if (<= page-number 0) ""
(cond ((eq? number-type 'roman-lower)
   (fancy-format #f "~(~@r~)" page-number))
  ((eq? number-type 'roman-upper)
   (fancy-format #f "~@r" page-number))
  ((eq? number-type 'arabic)
   (number->string page-number))
  (else (number->string page-number);)
(cons 'page:page-number
  (chain-assoc-get 'page:page-number props -1)))
  props))
  (interpret-markup layout props arg))

\paper {
  %first-page-number = #-3
  print-first-page-number = ##t
  oddMarkup =
  #(define-scheme-function (number-type)(symbol?)
#{
  \markup
\column {
  \fill-line {
" "
\on-the-fly #not-part-first-page \fromproperty #'header:instrument
  %% use in this order:
  \on-the-fly #reset-part-first-page
  \on-the-fly #(print-part-first-page-as-one number-type)
  \on-the-fly #print-page-number-check-first
  \fromproperty #'page:page-number-string
  }
  \vspace #5
}
#})

  evenMarkup =
  #(define-scheme-function (number-type)(symbol?)
#{
  \markup
\column {
  \fill-line {
  %% use in this order:
  \on-the-fly #reset-part-first-page
  \on-the-fly #(print-part-first-page-as-one number-type)
  \on-the-fly #print-page-number-check-first
  \fromproperty #'page:page-number-string
\on-the-fly #not-part-first-page \fromproperty #'header:instrument
" "
  }
  \vspace #5
}
#})

  oddFooterMarkup = \markup {
\column {
  \fill-line {
\concat {
  "real book number: "
\on-the-fly #print-page-number-check-first
  \fromproperty #'page:page-number-string
  }
  }
  \fill-line {
%% Copyright header field only on first page in each boob.
\on-the-fly #part-first-page \fromproperty #'header:copyright
  }
  \fill-line {
%% Tagline header field only on last page in the book.
\on-the-fly #last-page \fromproperty #'header:tagline
  }
}
  }
}


musique = \relative c'' { \repeat unfold 2 { d1 \pageBreak } }

\paper {
   print-first-page-number = ##f
}

\book {
   \bookpart {
 \paper {
   oddHeaderMarkup = \oddMarkup #'arabic
   evenHeaderMarkup = \evenMarkup #'arabic
 }
 \score {
   \musique
 }
   }
   \bookpart {
 \paper {
   oddHeaderMarkup = \oddMarkup #'arabic
   

Re: Feedback wanted: syntax highlighting in the LilyPond documentation

[David Zelinsky]

Jean Abou Samra  writes:

> Hi all,
>
> There is an ongoing proposal to add syntax highlighting
> in LilyPond's documentation. Since it is a notable change
> to the documentation reading experience, user feedback would
> be appreciated. You can browse a syntax-highlighted version
> of the notation manual here:
>
> http://abou-samra.fr/highlighting-demo/notation/index.html
>
> For comparison, this is the current notation manual:
>
> https://lilypond.org/doc/v2.23/Documentation/notation/index.html
>
> The main questions are: what do you think of the principle?
> And is the color scheme good enough?
>
> Thanks in advance,
> Jean


For the short snippets in the manual, I find the synatx highlighting
more distracting than helpful.  I personally would prefer it without.  I
do use syntax highlighting when editing files and find it very useful,
but that's when there are large blocks of code, and the highlighting is
helpful for visually parsing it.

-David

Problem controlling page numbers in bookparts

[Vincent Gay]

Hello,

I'm a french Lilypond user and I use to discuss on the LilyPond 
French-speaking list.


I recently found a post of Thomas Morley about page numbering within a 
\bookpart (this page 
). It 
is very useful for me, is there a more recent version?


Here are a few things I'm having trouble with :

1- the example in the post compiles perfectly, mine (first example 
below) ends with this error.


FORMAT: error with call: (format #f "~(~@r<===~)" ===>0 )

only positive integers can be romanized

: In procedure scm-error in expression (scm-error (quote 
misc-error) #f ...):


: error in format


I don't understand where the difference is.

2- If I compile two books in the same document and 
print-first-page-number has the value ##f the second page of the second 
book is numbered with the value 0. If print-first-page-number has the 
value ##t the result is correct. See the second example below.


3- Even with print-first-page-number = ##f the first pages of the 
\bookparts (starting from the second one) are printed. Is there a way to 
hide them?


Many thanks in advance.




First example :
\version "2.22.1"
\include "BookPartPagesNumber.ly"
musique = \relative c'' { \repeat unfold 2 { d1 \pageBreak } }

\book {
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'roman-lower
  evenHeaderMarkup = \evenMarkup #'roman-lower
    }
    \score {
  \musique
    }
  }
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'arabic
  evenHeaderMarkup = \evenMarkup #'arabic
    }
    \score {
  \musique
    }
  }
}


Second example :
\version "2.22.1"
\include "BookPartPagesNumber.ly"
musique = \relative c'' { \repeat unfold 2 { d1 \pageBreak } }

\paper {
  print-first-page-number = ##f
}

\book {
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'arabic
  evenHeaderMarkup = \evenMarkup #'arabic
    }
    \score {
  \musique
    }
  }
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'arabic
  evenHeaderMarkup = \evenMarkup #'arabic
    }
    \score {
  \musique
    }
  }
}

\book {
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'arabic
  evenHeaderMarkup = \evenMarkup #'arabic
    }
    \score {
  \musique
    }
  }
  \bookpart {
    \paper {
  oddHeaderMarkup = \oddMarkup #'arabic
  evenHeaderMarkup = \evenMarkup #'arabic
    }
    \score {
  \musique
    }
  }
}

--
Vincent Gay
Envoyé depuis mon saxo-phone :)
https://myrealbook.vintherine.org/  -http://photos.vintherine.org/



OpenPGP_signature
Description: OpenPGP digital signature

Re: Feedback wanted: syntax highlighting in the LilyPond documentation

[Peter Toye]

Jean,
 
There are various types of colour-blindness - red-green is the most common. I 
did a quick Google on "design for colour-blind" and got several useful hits, 
mostly for web designers. The basic message is "don't rely on colour to get a 
message across", which isn't much help to you.
 
One way round this might be to allow the user to select colours for the 
different distinguishable syntax elements (I think this has already been 
suggested somewhere in this thread). And not to make it too complicated. I 
personally get a bit fed up with Frescobaldi's colours but being 
normally-sighted I can live with it.


Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Sunday, January 2, 2022, 5:01:11 PM, lilypond-user-requ...@gnu.org wrote:

> Send lilypond-user mailing list submissions to
>         lilypond-user@gnu.org

> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/lilypond-user
> or, via email, send a message with subject or body 'help' to
>         lilypond-user-requ...@gnu.org

> You can reach the person managing the list at
>         lilypond-user-ow...@gnu.org

> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lilypond-user digest..."


> Today's Topics:

>    1. Re: Feedback wanted: syntax highlighting in the LilyPond
>       documentation (Wols Lists)
>    2. Re: Feedback wanted: syntax highlighting in the LilyPond
>       documentation (Jean Abou Samra)


> --

> Message: 1
> Date: Sun, 2 Jan 2022 16:24:39 +
> From: Wols Lists 
> To: lilypond-user@gnu.org
> Subject: Re: Feedback wanted: syntax highlighting in the LilyPond
>         documentation
> Message-ID: <0578c098-ae48-ac16-f8ae-79ef71076...@youngman.org.uk>
> Content-Type: text/plain; charset=UTF-8; format=flowed

> On 02/01/2022 09:34, Marc Lanoisel?e via LilyPond user discussion wrote:
>> It will be necessary to keep an uncolored version for men (in principle 
>> women do not have this problem) who do not see well certain colors.

> In principle (and practice) women DO suffer this problem. It's caused by 
> a defective X chromosome so, like haemophilia, the majority of sufferers 
> are men. If however a colour-blind man marries a carrier woman, any 
> daughter runs a 50-50 risk of being colour-blind.

> Cheers,
> Wol



> --

> Message: 2
> Date: Sun, 2 Jan 2022 17:32:32 +0100
> From: Jean Abou Samra 
> To: Knute Snortum 
> Cc: Lilypond-User Mailing List 
> Subject: Re: Feedback wanted: syntax highlighting in the LilyPond
>         documentation
> Message-ID: <5ceaea96-eda8-45bb-82bf-896733085...@abou-samra.fr>
> Content-Type: text/plain; charset=UTF-8; format=flowed

> Le 02/01/2022 ? 17:01, Knute Snortum a ?crit?:
>> On Sun, Jan 2, 2022 at 7:10 AM Jean Abou Samra  wrote:
>> ...
>>> [Marc]
 It will be necessary to keep an uncolored version for men (in
 principle women do not have this problem) who do not see well certain
 colors.
>>> This is taken care of -- the colors have been
>>> chosen to have enough contrast to the white
>>> background to be readable even for those
>>> with impaired vision. Since I am not such a
>>> person, I have been checking the scheme against
>>> WCAG recommendations. The color with least
>>> contrast has 6.15, which is quite a bit
>>> above the WCAG AA level of 4.5. This means that
>>> even someone not discerning colors at all
>>> can read such highlighted code.
>> I am colorblind (which BTW means that it's hard to distinguish certain
>> colors, not that everything is gray).


> Sorry if I gave a wrong impression. I didn't
> mean that everything actually looked gray, just
> that it was the extreme imaginary case encompassing
> all types of colorblindness (I think there are
> different ones, right?).


>> I can't see a difference
>> between the blue and the purple, but this doesn't cause a problem for
>> me -- I just miss some of the highlighting, which is unavoidable.  The
>> bold terms jump out at me, but the coloration seems reasonable.  All
>> in all, the scheme seems reasonable to me.


> Thanks for the input! That's reassuring.

> Best regards,
> Jean




> --

> Subject: Digest Footer

> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


> --

> End of lilypond-user Digest, Vol 230, Issue 10
> **