Re: Licensing concerns raised by new terms of service for GitHub

On Wed, Mar 1, 2017 at 4:57 PM, David Szent-Györgyi wrote: > I don't know that this is an issue, but a change of terms associated with > an essential service need to be checked with care. > ​I care nothing for such things.​ ​ In practice, nobody is going to be complaining

Re: A sprint (real or virtual) about Leo 5.6

Maybe. Aiming Pharo was good enough in my case. Other languages could come after, using similar ideas to the ones in Org, Beaker or Jupyter. The nature of prototyping and refactoring can be different in Python, so I would let people with more experience on it take the final design decision.

Licensing concerns raised by new terms of service for GitHub

I don't know that this is an issue, but a change of terms associated with an essential service need to be checked with care. According a blog entry posted on March 1 by Debian Developer Joey Hess, The new TOS is potentially very bad for copylefted Free Software. It > potentially neuters it

Re: A sprint (real or virtual) about Leo 5.6

I think limiting it purely to python would be aiming too low. But even if it was it would likely be easy to extend via native subprocess package or the third-party sh package (one of my favorite packages). On Wednesday, March 1, 2017 at 10:50:25 AM UTC-5, Offray Vladimir Luna Cárdenas wrote: >

Re: Installation - suggested cleanups

On Wednesday, February 22, 2017 at 7:19:04 AM UTC-6, lewis wrote: May I suggest some improvements to the installation documents? They are not > general in nature but quite specific, just as you requested. > I've just made *all *the changes you suggested here

tables.py documentation

>From the 5.6 thread: > [...] tables.py is a start. Aah, I thought tables.py was a planned plugin, and hadn't realized there's already something implemented. Is the current version of tables.py a work-in-progress, or should the implemented features already work - and if so, how to use it? I

Re: tables.py documentation

On Wed, Mar 1, 2017 at 10:16 AM, Arjan wrote: > From the 5.6 thread: > [...] tables.py is a start. > > Aah, I thought tables.py was a planned plugin, and hadn't realized there's > already something implemented. > > Is the current version of tables.py a work-in-progress >

Re: A sprint (real or virtual) about Leo 5.6

I agree. I'm now making table formating on org-mode and literate computing on Grafoscopio. If I need to prioritize a feature that would attract more diverse users to Leo would be literate computing. That has been our case with Grafoscopio and our Data Week hackathon+workshop[1] have

Re: A sprint (real or virtual) about Leo 5.6

While it would be pretty great to have full auto-reformatting ascii org-mode tables my inclination is that there are higher priority org-mode features that should be tackled first (for example, functionality enabling literate programming). On Wednesday, March 1, 2017 at 8:39:25 AM UTC-5, Arjan

Re: A sprint (real or virtual) about Leo 5.6

On Wed, Mar 1, 2017 at 7:39 AM, Arjan wrote: > > In particular, emulating org-mode tables (including its spreadsheet > features) seems like a lot of work. > So I'm hoping it's important to others as well, and will turn out to be > doable! > ​It's certainly doable.

Re: A sprint (real or virtual) about Leo 5.6

> In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work. I use Leo primarily as an information manager (as well as for writing LaTeX), and I very frequently need to capture some tabular information. For me this would be a central feature for Leo