guile-user
[Top][All Lists]
Advanced

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

Re: Starting a GNU Guile awesome list


From: Zelphir Kaltstahl
Subject: Re: Starting a GNU Guile awesome list
Date: Tue, 14 Jul 2020 23:23:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi Dmitry!


On 7/14/20 11:00 AM, Dmitry Alexandrov wrote:
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
>> I ‹…› started creating an awesome list
>> https://notabug.org/ZelphirKaltstahl/awesome-guile
> +1!
>
> However, even if you are not going to apply for inclusion¹ in meta-list 
> <https://awesome.re> and therefore are free from complying with all rules 
> that might come to the mind of a macboy in state of administrative ecstasy²; 
> calling your list ‘an awesome list’ implies a certain format nonetheless.
>
> And that format actually answers two of the there of your questions.

Thanks for informing and mentioning those things! I did not even know.


> -
> ¹ In any case, I am not sure, whether they accept lists with the primary 
> repository outside of github.com at all.

I'm surely not going to create any repositories on GitHub in the near
future, unless somehow MS becomes the new saint of the free software
movement ; )


> ² E. g., recently he had broken local clones and invalidated all the 
> pull-request backlog by renaming ‘master’ branch to ‘main’, and now require 
> all the lists to follow his example.

Ha, the whole thing about renaming master branch sounds so silly to me,
I'd never do that. Perhaps that person got too much time or something.

I wonder, can people even still get a "master degree" or write a "master
thesis"? Can I still write my master degree on my CV or is it now shameful?


>> * Do you think each item should have a short description or not?
> Thatʼs the key feature of ‘awesome lists’, number one in the ‘manifesto’ [1]:
>
> | Comment on why something is awesome
> |
> | Apart from suggesting a particular item on your list, you should also 
> inform your readers why it's on the list and how they will benefit from it.
>
> [1] https://github.com/sindresorhus/awesome/blob/main/awesome.md

OK, it can be useful. I'll see, when and if I can get around to writing
the descriptions.

The thing is: For some modules / packages / libraries I don't even know
how to describe them correctly and would need the authors' help or quote
their texts. It would be nice, if people sharing adding Guile things to
the list gave short descriptions, if able to do so.


>> * Do you think the rendered readme.md should be handwritten instead of 
>> exported from org-mode?
> Again, ‘awesome list’ format implies [2] Markdown as a source format.  Nobody 
> says, though, that a source is something handtyped.
>
> [2] https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md

To me this awesome list thing seemed like an Internet software
development phenomenon, which would be nice to carry into the Guile
world, in order to increase discoverability. That's how I have
experienced it so far. I've never even heard of https://awesome.re. I
should have looked it up / researched it more, beforehand. Didn't think
there was anything more to it, than creating a list inside a repository.

I think their rules are theirs and we can do as we wish. I don't think
anyone can claim the word "awesome" as a prefix for themselves and
impose rules on how anything has to be, when having the prefix. However,
I'd consider using another word instead (Why not do our own thing?), if
it is consensus (What do people think about renaming the list?), that
the name should be changed due to the list at https://awesome.re
existing and the author of that trying to impose stuff. Possibly this
comes at the cost of a little bit of discoverability. There is still
"ingenious guile" :D


>> (Perhaps I should not ask this question …  the amount of markdown typing … 
>> my fingers hurt.)
> ???  The only thing where org-mode saves typing over markdown-mode is ToC 
> generation.  But there are lots ToC helpers for Markdown!  (describe-package 
> 'markdown-toc), for instance.
>
> In the case you will stick with Org, there at least should be a runnable 
> build recipe (i. e. a Makefile).

I'm sorry, you are (understandably) misunderstanding me here. I was not
very clear.

I've been hinting at RSI, which I need to look out for, not at any
advantage in number of characters or key presses to type in Markdown vs
Org-mode : ) I am not even sure which one would require less typing,
considering the comfort Emacs offers for org-mode.

In Emacs one can easily export to Markdown from Org-mode or to many
other formats. The table of contents is already generated by org-mode
export. I am not sure, whether one can use Emacs functionality from
outside of Emacs. I remember there being a library about Emacs stuff,
possibly written in Guile. Forgot the name though. It was I think also
shared on this mailing list at least once. (I should probably find it
again and put it on the list!)

What I will not do is discarding the org-mode file, as it is a much
saner markup language and allows for many more output formats. One can
write whole scientific books in org-mode, which is impossible in
original Markdown (probably only possible in PandocMarkdown) and yet the
syntax remains very intuitive (for example for check lists / todo
lists!) and simple.

The question is, whether it is worth it typing the markdown file by hand
instead of exporting from org, because of how the converted file is
converted and then how rendered at the git host's web interface, with
Roman numbers on second level of the lists. The style of headings also
does not distinguish the levels of the headings very well. The font
sizes are too similar. I wish it would render org files properly, in
their full glory.


>> * Do you think license information should be written next to each item in 
>> the list?
> First at foremost, the list _itself_ has to be licensed as a free 
> documentation.  FWIW, most of ‘awesome lists’ are under CC0.

While the list is not CC0, I meant to put it under "GNU Free
Documentation License v1.3", which I think should be appropriate (Is it
not?) and free as in freedom. Good that you hint at the license, because
I thought it had a license already.

It seems I did not check the checkbox for notabug to insert that license
file or I forgot in excitement of creating the list.

I'll add that license as the next step.


>> * Do you think license information should be written next to each item in 
>> the list?
> Anyway, imho, yes, it should.  This is an information with the highest 
> usefulness/length ratio.  Perhaps, only maintained-or-abandoned bit could 
> contend for it.
>
> Actually, you might eventually find out useful to list something, because it 
> has not a technical, but exactly a licensing advantage to another item.
>
> For instance, the above-mentioned GNU G-Golf have a advantage over Guile GI 
> as it does not follow a bad licensing practice of distributing a glue between 
> a library under license A and a language under license B under terms of the 
> third license C.

OK I will consider those points. Thanks!

Best regards,
Zelphir




reply via email to

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