Re: [oll-user] 'snippets' Github interface idea

[Janek W. <lem...@gm...>]

2013/9/13 Urs Liska <ul...@op...>

>  Am 13.09.2013 01:20, schrieb Janek Warchoł:
>
 In the basic version the generated file would contain
>> - A heading and a general short introductory text
>> - A generated image (the example output of the compilable file)
>>    -> one more incentive to include good examples
>> - The complete code listing
>>    (unfortunately it isn't possible to provide code highlighting like in
>> the blog posts)
>>
>
>  This could simply be a link to the snippet file, if we wanted to make
> things simple.
>
> I would prefer including the listing. This shouldn't be really
> complicated, and it would make the code readable in the context of the
> description. Opening .ly files in a browser usually isn't really exciting
> ...
>

+1

>  Actually, we may be able to provide syntax highligting: as far as i
> know, you can insert HTML into markdown, so we could use your html-export
> from Frescobaldi to produce html code and paste it into the .md file!
> ...for some reason this doesn't work as expected.  I've added a markdown
> file containing html code generated using your Frescobaldi export, and it
> isn't coloredd.  I think that Github isn't respecting some aspect of html
> formatting, maybe that's a bug.
>  See my attempt here:
>
> https://github.com/openlilylib/snippets/blob/markdown-test/notation-snippets/scaling-stencils.md
>
>
> As you noticed, I had tried the same before ;-)
> Having written to Github is a good idea. Although I don't think it's a bug
> but rather an omission. Maybe even on purpose, e.g. for security reasons.
>

As for now i was told to report this to pygments:
http://bitbucket.org/birkenfeld/pygments-main/issues

>   In a later version one could (quite easily) extract meta information
>> from the snippet and provide them in a formatted and structured display.
>>
>
>  In fact, we might want to switch to markdown in snippet descriptions
> because of this.
>
>  The script would be run locally every now and then by an admin.
>>
>
>  Easy to do with a cron job.
>
>  I would prefer doing it as a Git hook.
> It should be possible to check which files have been affected by a commit
> and act upon this information.
>

I suppose that It would have to be done as a post-fetch hook, and we would
probably need cron jobs anyway to ensure that some of the admins fetch
regularly.

>   Some issues to be considered:
>> - Try to determine snippets to be processed (i. e. only new or modified
>> ones)
>>    recompiling snippets with differing LIlyPond versions would result in
>> the images to be modified
>>    (i.e. detected as changes by Git)
>>
>
>  This should be easy: just store the committish of the revision of the
> snippet that was used for producing .md and .png files, and check if think
> that having a .png file in the snippet directory.  If there were changes in
> the snippet file since that commit, recompile.
>
>
> You're more experienced with Git than I am. But I think if we hook into
> the commit itself it would be easier and more reliable to retrieve
> information on the affected files themselves.
>

I haven't used git hooks yet, but as far as i understand it to use a
post-commit hook everyone needs to configure this hook in their
repositories, and probably it wouldn't work with github's web interface.
So, instead of using the post-commit hook we would run the script as
post-fetch hook.

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...