Leo's future goals

Leo's overarching goals for the future are easily stated: 1. Improved cooperation with other editors & programs. 2. Better diagrams in Leo, with Joe Orr's work as an inspiration. See also, Mind in Motion. Both will likely benefit from embedding a client-server architecture into Leo. pyzo's yo

Re: Atom might be Leo's future

On Sat, Mar 10, 2018 at 8:04 PM, Thomas Passin wrote: > It seems to me that many python-based systems could be run in a Leo > process, which would give access to their internal APIs. The challenge > would be to get their input and output into Leo cells. > > For non-python systems, in some cases

Re: Atom might be Leo's future

It seems to me that many python-based systems could be run in a Leo process, which would give access to their internal APIs. The challenge would be to get their input and output into Leo cells. For non-python systems, in some cases there could be a python wrapper that handles communication (

Re: Atom might be Leo's future

On Wednesday, February 21, 2018 at 9:01:59 AM UTC-6, Edward K. Ream wrote: This video > > > is a very impressive overview of pycharm's features. Not sure every feature > of this video is availabl

Re: Atom might be Leo's future

On Wednesday, February 21, 2018 at 8:26:42 AM UTC-6, Edward K. Ream wrote: Work will continue "forever" on improving the pure python version of Leo. > This may include work on all the cool features we envy in atom! > Or pycharm. This video

Re: Atom might be Leo's future

On Wednesday, February 21, 2018 at 8:26:42 AM UTC-6, Edward K. Ream wrote: external gui plugins *might* launch a hidden version of Leo: > > python launchLeo.py --gui=vscode > Oops. I got this backwards. *Host plugins* would launch a hidden version of Leo. Edward -- You received this mes

Re: Atom might be Leo's future

On Wednesday, February 21, 2018 at 1:39:52 AM UTC-6, Edward K. Ream wrote: I wrote my last post in the middle of the night. It shows :-) After getting more sleep, and discussing the issues with Rebecca, more has become clear. Here is what I think I know for sure: *No forks, but...* Leo's code

Re: Atom might be Leo's future

​ ​​ On Tue, Feb 20, 2018 at 9:52 AM, Edward K. Ream wrote: ​> ​ Don't panic. Note the word "might" in the title. ​The process of "living with what I wrote" has *increased* my doubts about using atom or vscode. See below. ​ ​> Afaik, atom does everything it has *in common* with Leo significant

Re: Atom might be Leo's future

On Tue, Feb 20, 2018 at 11:00 PM, Xavier G. Domingo (xgid) < xgdomi...@gmail.com> wrote: > Wow, this is amazing! I had this exact same idea about two weeks ago, but > for taking the best of Leo to VSCode instead of Atom! > ​Many thanks, Xavier, for this. I did not know anything about VSCode befo

Re: Atom might be Leo's future

Regarding performance, VSCode is beating Atom by far according to Atom users themselves: https://github.com/atom/atom/issues/10188 On Wednesday, February 21, 2018 at 2:00:47 AM UTC-3, Xavier G. Domingo (xgid) wrote: > > Wow, this is amazing! I had this exact same idea about two weeks ago, but >

Re: Atom might be Leo's future

Wow, this is amazing! I had this exact same idea about two weeks ago, but for taking the best of Leo to VSCode instead of Atom! I've recently re-discovered VSCode thanks to a plugin made by a colleague at work and I'm nearly falling in love with it. Clean interface, quite fast (you have to try

Re: Atom might be Leo's future

On Wed, Feb 21, 2018 at 1:35 AM, Edward K. Ream wrote: > On Tuesday, February 20, 2018 at 10:17:52 AM UTC-6, Zoom.Quiet wrote: > > Thanks for these comments. It's good to know that Atom may not perfect. > Hehe. > > > ... has a large user... <-- that is maybe hallucination ;-) > > Is there any rea

Re: Atom might be Leo's future

On 2/20/18 11:17 AM, Zoom.Quiet wrote: On Tue, Feb 20, 2018 at 11:52 PM, Edward K. Ream > wrote: Don't panic.  Note the word "might" in the title. Before going further, please look at the Why Atom?

Re: Atom might be Leo's future

On Tuesday, February 20, 2018 at 10:17:52 AM UTC-6, Zoom.Quiet wrote: Thanks for these comments. It's good to know that Atom may not perfect. Hehe. > ... has a large user... <-- that is maybe hallucination ;-) Is there any reason you say this? > VSCode base same construct with Atom... > - ope

Re: Atom might be Leo's future

On Tue, Feb 20, 2018 at 11:52 PM, Edward K. Ream wrote: > Don't panic. Note the word "might" in the title. > > Before going further, please look at the Why Atom? > page. > It would also be good to install atom >

Atom might be Leo's future

Don't panic. Note the word "might" in the title. Before going further, please look at the Why Atom? page. It would also be good to install atom and read A

Re: ENB: Why python will remain Leo's future

On Mon, Feb 19, 2018 at 3:22 AM, jkn wrote: Rust is an interesting language, but it is totally unsuitable for >> non-professional programmers. >> > > I'd be interested in learning more about your views of why this is... > ​Rustaceans must be aware of lifetimes.​ ​ Pythonistas don't. Edward --

Re: ENB: Why python will remain Leo's future

Hi Edward On Sunday, February 18, 2018 at 9:53:38 PM UTC, Edward K. Ream wrote: > > On Friday, February 16, 2018 at 3:45:23 AM UTC-6, Edward K. Ream wrote: >> >> Rewriting Leo's core is out of the question. Python is: >> >> - Best for users as the simplest and most flexible scripting language. >>

Re: ENB: Why python will remain Leo's future

On Friday, February 16, 2018 at 3:45:23 AM UTC-6, Edward K. Ream wrote: > > Rewriting Leo's core is out of the question. Python is: > > - Best for users as the simplest and most flexible scripting language. > - Dynamic. Imagine doing @button in rust. > - The basis for Leo's API. > Rust is an inte

ENB: Why python will remain Leo's future

Rewriting Leo's core is out of the question. Python is: - Best for users as the simplest and most flexible scripting language. - Dynamic. Imagine doing @button in rust. - The basis for Leo's API. Instead, Leo can and should add support for the rust language #727

Re: Leo's future

Well having a not-yet-user posting in the forums is certainly exciting. I think one of the things that would help new users is more videos. We have some already and they are useful to see how things work, but not nearly enough. I think the total of our videos covers less than 1% of Leo's featur

Re: Leo's future

On 7/31/15 10:48 AM, john lunzer wrote: I would like to reiterate, because I don't want to come off as too critical, that I love what Leo can do! And with the refactoring plugin I'm writing I'm finding it more and more powerful every day. Leo is ready to get its name out there, but the communit

Re: Leo's future

On Wednesday, August 19, 2015 at 3:21:54 AM UTC-5, Edward K. Ream wrote: > > On Tue, Aug 18, 2015 at 8:35 PM, David McNab > wrote: > >> How does @clean handle it when a teammate does a major restructure of a >> module? For example, refactors a Python class into a base, a derived plus a >> mixin

Re: Leo's future

On Tue, Aug 18, 2015 at 8:35 PM, David McNab wrote: > How does @clean handle it when a teammate does a major restructure of a > module? For example, refactors a Python class into a base, a derived plus a > mixin, and moves 4 global functions into the base class as methods, and > moves 3 methods o

Re: Leo's future

Good question... and one I'm entirely unqualified to answer! ...Edward? -->Jake On 8/18/2015 9:35 PM, David McNab wrote: How does @clean handle it when a teammate does a major restructure of a module? For example, refactors a Python class into a base, a derived plus a mixin, and moves 4 globa

Re: Leo's future

How does @clean handle it when a teammate does a major restructure of a module? For example, refactors a Python class into a base, a derived plus a mixin, and moves 4 global functions into the base class as methods, and moves 3 methods of the class out into functions? (Just asking) On 19 August 2

Re: Leo's future

>However, many times people have convinced me that I should want something more >:-) or something less **cough (clones) cough** :-] On Tue, Aug 18, 2015 at 4:32 PM, Edward K. Ream wrote: > On Tue, Aug 18, 2015 at 12:06 PM, Kent Tenney wrote: > >> *checks pocket, finds 2 cents* > > > Or rather,

Re: Leo's future

On Tuesday, August 18, 2015 at 5:32:49 PM UTC-4, Edward K. Ream wrote: > > ​Yes. I have always done pretty much exactly what I wanted to do. > However, many times people have convinced me that I should want something > more :-)​ > > This may be a perceptual mistake in many cases. As I see it

Re: Leo's future

​​On Tue, Aug 18, 2015 at 12:06 PM, Kent Tenney wrote: *checks pocket, finds 2 cents* > ​Or rather, several gold pieces :-) You and Terry seem to understand me and my goals and motivations very well. I appreciate your comments.​ There's a tension between wanting Leo to gain widespread > appr

Re: Leo's future

On Tue, Aug 18, 2015 at 2:59 PM, David McNab wrote: > Hi Ed, thanks for your detailed response. > ​You're welcome. ​ > I got a bit of a rude shock a year ago when I took my present development > role. At first, I imported one of my job's codebases into a Leo tree, with > aim of continuing with

Re: Leo's future

screenshare in to a desktop running it. Unless the tablet is on a LAN near the desktop, and has a 10" screen, this is unworkable. ​Supporting tablets or smartphones requires support for Python and PyQt on those platforms. Iirc, Ville created a Leo reader fo

Re: Leo's future

to a >> desktop running it. Unless the tablet is on a LAN near the desktop, and has >> a 10" screen, this is unworkable. >> > > ​Supporting tablets or smartphones requires support for Python and PyQt on > those platforms. Iirc, Ville created a Leo reader for Androi

Re: Leo's future

On Tue, 18 Aug 2015 10:39:45 -0700 (PDT) holgersc...@googlemail.com wrote: > Hi Edward, > > I don't know how often this has been asked: > What if options would not be set via head or body of a node but be > attributes of this node? I think what you're suggesting would be, in Leo terminology, pu

Re: Leo's future

Hi Edward, I don't know how often this has been asked: What if options would not be set via head or body of a node but be attributes of this node? Of course not Class attributes but attributes of specific instances to keep everything smaller. Why I'm asking: Today I tried to integrate my code

Re: Leo's future

eenshare in to a >> desktop running it. Unless the tablet is on a LAN near the desktop, and has >> a 10" screen, this is unworkable. > > > Supporting tablets or smartphones requires support for Python and PyQt on > those platforms. Iirc, Ville created a Leo reader for Andro

Re: Leo's future

near the desktop, and has > a 10" screen, this is unworkable. > ​Supporting tablets or smartphones requires support for Python and PyQt on those platforms. Iirc, Ville created a Leo reader for Android, but I could be mistaken > > *I would suggest that Leo's future lies in a

Re: Leo's future

On Mon, Aug 17, 2015 at 7:53 PM, Dufriz wrote: For the umpteenth time (sorry about the abrasive tone): improving user > friendliness for non-technologically savvy users is paramount. This has > been pointed out and requested so many times in the past. > ​How many times do I have to say this? If

Re: Leo's future

On Monday, August 17, 2015 at 8:53:47 PM UTC-4, Dufriz wrote: > ... improving user friendliness for non-technologically savvy users is > paramount. This has been pointed out and requested so many times in the > past... I am very happy to hear that Edward thinks that most of the > essential stuf

Re: Leo's future

e than one developer to work on files at once I can't use Leo on my tablet or smartphone, unless I screenshare in to a desktop running it. Unless the tablet is on a LAN near the desktop, and has a 10" screen, this is unworkable. *I would suggest that Leo's future lies in a complete rebui

Re: Leo's future

On Wednesday, 29 July 2015 14:07:44 UTC+1, Edward K. Ream wrote: > > > Your comments, please. > > Edward > For the umpteenth time (sorry about the abrasive tone): improving user friendliness for non-technologically savvy users is paramount. This has been pointed out and requested so many times i

Re: Leo's future

I'm sure I'm not the only one who would like to thank you very deeply for your work over the past 20 years. It is obvious that Leo had a great champion with a fierce drive and determination to make Leo the great piece of software it is today. If you were to decide now to have Leo development ta

Re: Leo's future

​On Wed, Jul 29, 2015 at 8:07 AM, Edward K. Ream wrote: > In my mind, all essential aspects of Leo are complete. Sure, there will > always be improvements to be made, and I intend to keep making them, but > now that that we have @clean the most important work is complete. > ​ Recent discussions

Re: Leo's future

I would like to reiterate, because I don't want to come off as too critical, that I love what Leo can do! And with the refactoring plugin I'm writing I'm finding it more and more powerful every day. Leo is ready to get its name out there, but the community would be best served if our "marketing

Re: Leo's future

Perception becomes almost as important as function. > May I add: Function that isn't perceived, does not exist! Reinhard -- 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

Re: Leo's future

Hi, In response to the website search discussion I added issue #203 to help deal with a specific search problem. Lewis -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from th

Re: Leo's future

I can echo the sentiment that first impressions count, as much as we hate that they do. Going "mainstream" requires quite a bit of hoop jumping. Perception becomes almost as important as function. I can echo that my experience with the search feature on the website is that it barely works. I r

Re: Leo's future

> An excellent suggestion is to reach out to magazine editors, get them > excited... > How? Speaking of marketing: First impressions count! So: Update the documentation. I.E.: Searching for '@clean' from the homepage of Leo gives: 'Your search did not match any documents' The user interf

Re: Leo's future

Leo mode for vim ... vim gui Not sure what this looks like, open gvim and it looks like Leo, or open Leo and all vim features are available? Either one sounds daunting. the neovim project https://github.com/neovim/neovim seeks to ease extensibility. It seems like a problem with outreach is that L

Re: Leo's future

2015-07-29 21:07 GMT+08:00 Edward K. Ream : > In my mind, all essential aspects of Leo are complete. Sure, there will > always be improvements to be made, and I intend to keep making them, but now > that that we have @clean the most important work is complete. > @clean means auto clean not-realy

Leo's future

In my mind, all essential aspects of Leo are complete. Sure, there will always be improvements to be made, and I intend to keep making them, but now that that we have @clean the most important work is complete. Imo, Leo is good enough as it is. What's not so good is outreach to the rest of th

Re: Sqlite, leo's future file format?

On Thu, Sep 18, 2008 at 1:38 PM, Terry Brown <[EMAIL PROTECTED]> wrote: > > I've just written a through-the-web web authoring system which uses > a node hierarchy and stores the nodes as pickled objects in a sqlite3 > db. Some nodes have 5 MB .mp3 files as attributes, but this doesn't > seem to b

Re: Sqlite, leo's future file format?

I've just written a through-the-web web authoring system which uses a node hierarchy and stores the nodes as pickled objects in a sqlite3 db. Some nodes have 5 MB .mp3 files as attributes, but this doesn't seem to be a problem. So I'm impressed with the performance of sqlite, but I don't think t

Re: Sqlite, leo's future file format?

On Sat, Sep 6, 2008 at 5:03 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > Are you aware of Leo's support for zodb data stores? Afaik, nobody > has done anything at all with it. Perhaps there is a big untapped > potential in this area. Zodb is a big dependency, while sqlite is bundled with py

Re: Sqlite, leo's future file format?

On Sat, Sep 6, 2008 at 5:28 AM, Ville M. Vainio <[EMAIL PROTECTED]> wrote: > Sqlite databases are self-contained in one file, and it seems also the > author suggests sqlite as a possible application file format. Are you aware of Leo's support for zodb data stores? Afaik, nobody has done anythin

Sqlite, leo's future file format?

Back to this weekends brainstorming spree... Think about it. Sqlite databases are self-contained in one file, and it seems also the author suggests sqlite as a possible application file format. It would also seem to fit leo like a glove. It would get leo much closer to the goal of lazy loading