Hi, It's good to see this thread about Big Dreams and their forks, including documentation.
My use of Leo is know kind of the same, and I'm using Grafoscopio[1] for the possibilities I want to explore on outlining and interactive documentation. But anyway, I would like Leo to be a vehicle for big dreams, because it was a game changer for me and there is a lot of potential hidden for many others. [1] http://mutabit.com/grafoscopio/index.en.html So, my proposal follows Zoom's about a directory with Leo documents that exemplify the way Leo can be used. Vitalije made one of those in the form of a Leo tutorial and I remember understanding things that I don't even know exist or I was interested in looking for in the extensive documentation Leo has. What we do in the Grafoscopio community (which is pretty small) is try to keep the non-interactive documentation minimal (installation, basis usage, community support and places of contact) and then show how to use the interactive documentation to showcase the rest of the Grafoscopio possibilities. There is a lot to be improved on that front, but I think that Leo could follow a similar path: a minimal "static" documentation that shows how to start with Leo and after that a menu that installs and open and extensive list of Leo outlines that show particular possibilities of Leo in a particular context and beginner friendly tone: @buttons, Unit Testing, development workflows, data and documents workflows and so on. Think in something like [1], but [1] https://github.com/jupyter/jupyter/wiki/A-gallery-of-interesting-Jupyter-Notebooks Contributing new documents should be as easy as giving a small description of your contributed outline and the url where you can download the last version. Leo should be able to review if the installed local version of a document is the same as the last remote published one and update/install new documents as needed/required. Most of my documentation happens today in my own interactive outliner and not in Leo, but I remember having simple Leo outlines I wanted to share about my workflow with Markdown that where relatively self-contained via @buttons. Maybe today they're supersede by Leo developments regarding Markdown external files and they could contain a lot of newbie code, but at that moment I felt pretty proud of them. We could have a place where Leo users could share the knowledge they have by sharing .leo files that exemplify how Leo helps in making their concerns and workflows possible. For example, once Leo is installed, I would like to have a set of notebooks that show me how to use Leo to bootstrap itself and the Python ecosystem (specifically the data related one). A Leo notebook that installs Conda/Git and contains recipes/nodes to load interesting notebooks, converting from Org/Jupyter to Leo and so on. Hope this helps, Offray On 10/11/18 2:56 AM, Zoom.Quiet wrote: > <[email protected]> 于2018年10月11日周四 下午2:06写道： >>> Yes, i meet same problems, >>> but the reason is simple: >>> - Leo release so many years, but the core developer always only EKR >>> - so means more and more knowledge for EKR as natural truth, not need >>> explain >>> - and servicing big document.leo project is not funny and tired... v >> Now that I think about it, I think you hit the nail on the head. Edward >> knows the software and code too well, and so it's hard for him to see it >> from a new user's perspective. If anyone is up for it, it may be best that a >> revamped documentation is done by others, with Edward looking over to make >> sure it's not inaccurate. >> >> My smaller dream was that I become well versed enough in Leo programming >> that I would then write my own documentation as a series on my site - >> starting from the basics of scripting to more advanced usage. I wanted to >> take features I liked in Emacs and port them to Leo and show how it's done - >> mostly because I really think many, many programmers out there would use Leo >> if they only knew how to. People learn a fairly foreign language (Emacs >> Lisp) to customize their editor. Many more would rather just do it in >> Python. I don't know if I'll ever become knowledgeable enough to get to that >> point, though. >> > as ur another mail suggest: > I'm suggesting that there be an Examples directory in the > distribution, where any file in it or a sub directory of it is treated > as such a template. It would contain live documents for plugins, > workflows, debugging demos, design notes, generic add a language demo, > unit test demo, todo plugin demo, etc. > > ... > > in fact in any tech community, there is one hide rule: > propose by who, make it by who ;-) > > just like EKR, not understand literature programming, > so build Leo to make literature programming environment for everyone. > > base the document problems, u r so right: > - want EKR writing friendly document for fresh people, is not the good solve > - but start with anlifer uself, is very good: > -- fork Leo repo. > -- append Examples directory > -- start write down all kinds of u feel need demo/doc./test/... > > so EKR and other people can work with your fork, > when the Examples sub path, grow enough, Pull-Request back distribution repo. > Bazinga ;-) > you create new age for Leo document. > > > > > >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/leo-editor. >> For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
