[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme coding] turning a list into a markup/string

From: Thomas Morley
Subject: Re: [Scheme coding] turning a list into a markup/string
Date: Tue, 21 Jan 2020 23:37:14 +0100

Am Di., 21. Jan. 2020 um 23:13 Uhr schrieb David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:

> > David, you remember my suggestion to generate that "General Code
> > Reference" with an Index ... ?
> Yes, that may have helped.  But it may also have delivered a haystack.
> I think we probably need a "good programming" corpus, but the snippets
> are supposed to be that.  Navigating them still is too hard.

If you think of the "Snippets Manual" or the LSR, then I doubt they
are best suited to what I think we need.
Their snippets are too much targeted at delivering ready to use tools
for actual typesetting work.

As an example:
music-map has the problem that you can't really stop it recursing
deeper. One reason why you wrote map-some-music and for-some-music.
Alas, I always need to get to their doc-strings again, to understand
the differences and which one to use for which case.
And ofcourse their docstrings are not in any manual, afaict.

Sometimes I look in our regression-tests, which contains nice coding
examples, but you can't expect average user to look there.
And sometimes even the regression-test don't say anything, as an
example for no info at all:
$ git grep "ly:broadcast"
lily/ (ly_broadcast, "ly:broadcast",
scm/define-music-callbacks.scm:              (ly:broadcast
(ly:context-event-source context)

Leading to IR entry:

Function: ly:broadcast disp ev
      Send the stream event ev to the dispatcher disp.

Which is ununderstandable without any context.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]