[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: David Kastrup
Subject: Re: [Scheme coding] turning a list into a markup/string
Date: Tue, 21 Jan 2020 23:44:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 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.

Yes.  The CG might have a bit of info there, but if it is there, it is
likely very sketchy and does not really help a lot.

> Cheers,
>   Harm

Well, to some degree my "why don't you use $x" kind of advice results
from having had to fight through the code base in order to be able to
refactor parts I had to fix into something I could understand.  So I
have bit of a semantic network in my head that may give me a hunch what
to grep for in order to tackle some class of problem.

That's pretty lousy as a way of getting information suited to the task.
I don't like the bus factor impact that makes me have.  Gives me a bad

David Kastrup

reply via email to

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