I haven't worked wirh TexInfo markup before, however it occurs to me
that lisp is regular enough that with some effort one could hope to scrape
out a majority of the function definitions
and then use such a database to touch up the help source?
Like if you imagine a strategy like this:
- scrape out what you can with a script (targeting to find 90% or so of
what's there)
- add an exception list hand-curated (which mops up the rest)
- use this stuff to find and 'parse' the contents of the help so that you
can then transform it into something else
this could give you some 90-95% of the source revised.
- mop up again the result by hand
If this were a one-off affair, it could be a way to go,
it sounds more painful that it often ends up being, the key being to find a
good balance
between how robust your scrapers are wrt how much manual effort is to go
back and mop things up.
I know the docs for lilypond are a huge set, and I'm not sure how
translations are implemented.
I'm not suggesting now it's a good time to do this, however if one were to
consider such a thing, this seems like it could be a way to do it,
purely because Lisp-y things are easy to parse, which makes them relatively
robust to detecting decorations such as @var{}
I've used pygmentize in other projects and it can look quite beautiful,
once you get it going.
I like how it's able to provide a unified look to a number of different
languages, making the final result
look consistent while making it clear what language is what.
(I've done a fair bit of LaTeX over the years)
Luca
On Mon, Feb 21, 2022 at 6:33 PM Jean Abou Samra <j...@abou-samra.fr> wrote:
> Le 21/02/2022 à 17:42, Luca Fascione a écrit :
> > Looks lovely to me.
> >
> > I notice the inline source is not highlighted, is that on purpose?
> > (say 2.1.7, page 23). A lot of other text I've seen seems to use the same
> > highlighting patterns for running code as well as display boxes of code,
> > esp given the fonts you picked are so regular in the weight, wouldn't it
> > look better?
>
>
>
> As with the syntax highlighting in HTML output that was
> already added (https://gitlab.com/lilypond/lilypond/-/merge_requests/1019,
> https://lists.gnu.org/archive/html/lilypond-devel/2021-12/msg00107.html
> and other threads),
> this is not straightforward to achieve. The problem is that
> the Texinfo source uses @code for anything that should
> appear in typewriter font. Not all uses of @code are for
> LilyPond input. 'git grep -o "@code" | wc -l' will give you
> an idea of the amount of effort that would be required to
> introduce a distinction ...
>
> Also, often we use @var inside @code, resulting in italics,
> to denote variadic parts (e.g.: "The syntax of @code{\relative}
> is @code{\relative @var{pitch} @var{music}}, where @var{pitch}
> is ..."). If italics were used for fixed syntactic elements,
> there would be confusion between the two uses.
>
>
> Best,
> Jean
>
>
