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 comma
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 have put your documentat
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,
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
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 t
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. Fossi
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 fact just
> sqlite3 database file.
>
>
>
he
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 explain
how they a
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 i
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 interested ;-)
EKR
--
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
acces
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 document in such a way tha
>
> 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 readab
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 st
From: Edward K. Ream
To: leo-editor
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
wrote:> I wouldn't be in a huge rush to eliminate
wrappers.
No worries. T
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 sub
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, havin
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 st
18 matches
Mail list logo