Re: Leo's real weaknesses

Hi, Yes, the discussion about longer or shorter names is not fruitful. Is better to explore some changes, variations and ideas outside of Leo and see where makes sense bring them back here. Once live coding become available on Leo, anyone could make something like: from Leo import c as

Re: Leo's real weaknesses

On Sat, Jan 14, 2017 at 1:21 PM, vitalije wrote: I couldn't find my earlier works but I have (re)created some script that > can be used for experiments. In the attachment of this message is > `fossil-leo.leo` file which contains one @button script. > ​Thanks for this. I

Re: Leo's real weaknesses

On Fri, Jan 13, 2017 at 4:59 PM, Offray Vladimir Luna Cárdenas < off...@riseup.net> wrote: > sometimes one looks his own code and thinks that the future self would > write it, in a complete different fashion. > ​That often happens with me. But there is no way that I would consider renaming c,

Re: Leo's real weaknesses

On Fri, Jan 13, 2017 at 4:33 PM, Offray Vladimir Luna Cárdenas < off...@riseup.net> wrote: > Some years ago I proposed something for Leo, combining two technologies: > fossil and Yaml[1], for the same reasons exposed here: fossil a as easier, > self contained technology for working with files and

Re: Leo's real weaknesses

FYI the above script will create a repository in current directory. If you execute the following command: fossil ui leohistory.fossil (you may need to provide a full path to leohistory.fossil) it should open your default browser and show you the home page of the repository. There you can find

Re: Leo's real weaknesses

I couldn't find my earlier works but I have (re)created some script that can be used for experiments. In the attachment of this message is `fossil-leo.leo` file which contains one @button script. Before running this script one should provide that fossil executable is somewhere in the path.

Re: Leo's real weaknesses

As a fan of Fossil, I second the motion to perform the necessary archaeology :-). On Fri, Jan 13, 2017 at 12:42 PM Edward K. Ream wrote: > On Fri, Jan 13, 2017 at 2:22 PM, vitalije wrote: > > Fossil OTOH, keeps all its data in just one file which is in

Re: Leo's real weaknesses

he statement that 'c', 'g' and 'p' should have longer names. Here, I'd like to discuss Leo's /real /weaknesses. Some have recently been exposed as I study pyzo's operation and code. I'll also explain how they arose and what might be done about them. With one exception, these have nothing whate

Re: Leo's real weaknesses

Hi, Some years ago I proposed something for Leo, combining two technologies: fossil and Yaml[1], for the same reasons exposed here: fossil a as easier, self contained technology for working with files and Yaml as a diff friendly format to express graphs (trees with clones). At that time the

Re: Leo's real weaknesses

On Fri, Jan 13, 2017 at 2:22 PM, vitalije wrote: Fossil OTOH, keeps all its data in just one file which is in fact just > sqlite3 database file. > ​Interesting. ​> ​ If you are interested in those scripts I will try to find (or recreate) and share them. ​Of course I'm

Re: Leo's real weaknesses

I suppose it can be done with the git also. But in that case user would need to have git installed and also git would need to recreate '.git' subfolder inside temporary folder every time. Fossil OTOH, keeps all its data in just one file which is in fact just sqlite3 database file. One can

Re: Leo's real weaknesses

On Fri, Jan 13, 2017 at 4:53 AM, vitalije wrote: Converting from xml to (say) json, won't help. >> > IMHO it is not necessarily true. I don't suggest changing Leo document > format from xml to json or any other format. But there can be found a > scheme of encoding a Leo

Re: Leo's real weaknesses

> > Converting from xml to (say) json, won't help. > > IMHO it is not necessarily true. I don't suggest changing Leo document format from xml to json or any other format. But there can be found a scheme of encoding a Leo document in such a way that its changes can be expressed in a human

Re: Leo's real weaknesses

​​ ​​On Wed, Jan 11, 2017 at 3:57 PM, 'Terry Brown' via leo-editor < leo-editor@googlegroups.com> wrote: ​> ​ I'm not sure if that can be a blanket statement. I guess Leo doesn't have a defined boundary between declared API and internals subject to change - perhaps by default we've assumed the

Re: Leo's real weaknesses

From: Edward K. Ream <edream...@gmail.com> To: leo-editor <leo-editor@googlegroups.com> Sent: Wednesday, January 11, 2017 1:33 PM Subject: Re: Leo's real weaknesses On Wed, Jan 11, 2017 at 12:31 PM, 'Terry Brown' via leo-editor <leo-editor@googlegroups.com>

Re: Leo's real weaknesses

On Wed, Jan 11, 2017 at 12:31 PM, 'Terry Brown' via leo-editor < leo-editor@googlegroups.com> wrote: ​> I wouldn't be in a huge rush to eliminate wrappers. No worries. They can't be eliminated now, because doing so could break existing code. EKR -- You received this message because you are

Re: Leo's real weaknesses

1. Using wrapper classes for text editing The present Qt gui is, iirc, Leo's fourth gui.  Two preceded Leo in python.  Previously, the python version of Leo used the much weaker Tk gui. The pyzo code shows just how big a price Leo has paid for the wrapper text abstraction layer.  Otoh,

Leo's real weaknesses

Recent criticisms of Leo and its architecture have been wildly off the mark. The most ludicrous was the statement that 'c', 'g' and 'p' should have longer names. Here, I'd like to discuss Leo's *real *weaknesses. Some have recently been exposed as I study pyzo's operation and code. I'll also