Re: A Recent Article by Me

[Edward K. Ream]

On Tue, Feb 20, 2018 at 5:40 PM, Satish Goda  wrote:

> This is awesome. I really think the following paragraph from your article
> summarizes the unparalleled utility of Leo.
>
> Outliners impose structure on documents. Sadly, they can also impose
> structure on our thinking, making creativity a lot harder. Leo is
> different. Instead of imposing structure, it allows you to impose your own
> infrastructure, and then be as creative as you want. This brings the
> necessary chaos of creativity to heel when it is time to produce the
> document. The node structure creates ultimate flexibility when it comes to
> ordering scenes in chapter. Say good-bye to copy and paste and hello to
> drag and drop.
>
> I shared your article to my followers on LinkedIn.
>

​Excellent.  Thanks for doing so.

Edward

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Edward K. Ream]

​
​​
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 significantly
better than Leo does.

​It might be true also of vscode.

But this does not mean that Leo itself (or Leo's users) would benefit from
hosting Leo on a javascript platform! The problem would be no-brainer if
there were an open source python platform of similar quality.

Hmm.  I just googled "open source python editor" and found this page
.  It mentions eric
, pycharm
 and Leo. True, some features of
pycharm are commercial , but
pycharm's commercial features seem much less important than its open source
features.

​> Atom has virtually everything, *except* those features that make Leo
what it is, namely scripting *in Python,* scripting API, clones, access to
outline data, @clean, etc. We might delegate everything else to atom ;-)
version of pycharm. I'm wondering why I never did this before!

​Or vscode, or eric, or pycharm.​

> The big question is, can Leo remain Leo when hosted on atom?

​Oh my. At last I see that embedding Leo in atom or vscode would *fork
Leo's code base*.  That's not going to happen while I am alive.

*Summary*

Embedding Leo in atom or vscode is out of the question.

Joe Orr's work is still valuable. It might be possible to use javascript
technologies from within Leo *as it is now*. We could consider arbitrarily
complex Leo plugins that would support Joe Orr's code, or atom or vscode.
The design of such plugins would make interesting thought experiments, at
the very least.

My new "next first step" will be to valuate eric and the *open source*
version of pycharm. I am eager to use the best features of each in Leo!

Let me repeat.  All conclusions are *still* provisional. Your comments have
been extremely valuable. Please keep them coming.

Edward

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Edward K. Ream]

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
before now.  I just installed it, and it feels much faster than atom.

I'll be studying VSCode, typescript and its ecosystem.​

​I imagine that plugins could be written in anything that ends up being js.

Edward

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: Adding Leo to Atom

[Edward K. Ream]

On Tue, Feb 20, 2018 at 8:15 PM, Zoom.Quiet  wrote:

>
>
>> - Opening a .leo file (in atom) will init *python state data* in the
>> python kernel. *Python code* in the kernel will load the .leo file and
>> create a representation (a tree of vnodes, or an sqlite db) of the outline 
>> *in
>> the kernel namespace*. The python code will pass a representation (as
>> json or cson) of the entire outline back to Leo's js plugin code.  This
>> will only happen once, when opening the outline.
>>
>
> means all Leo's commands/plugins will process by python self, not change?
>

​That is the idea.​

​ The js code in atom would call a python wrapper in the kernel.  This
wrapper would be similar to the Leo bridge.  It would get Leo's entire code
base using python imports.


>
>> - Leos' javascript code (in atom) will update the screen when inserting,
>> deleting, moving, changing and cloning nodes.  So the js code acts pretty
>> much like gui code. The js code must (probably) also update the python
>> representation in the kernel namespace for the outline.
>>
>
> Wow, means Atom only make GUI part,
> others actions all by python , same now, not change?
>

​Yes, that's the idea.  However, it's probably not so simple.  For example,
the mod_scripting plugin presently handles @button nodes.  The js code
would have to do some of the work. And there would be other complications.
​


> - The execute-script command (in atom) will send the to-be-executed script
>> to the kernel.  The kernel, using the state data for the outline, will run
>> the script and return the value of the script, and any side effects of the
>> script, again as json/cson.  Using this returned value, the gui code will
>> insert, delete, move, change and cloned nodes on the screen.
>>
>>
> means, Leo all kinds of commands/plugins will bind RESTful API,
> Atom answer user's action,
> sent/accept core API srv.
> Leo base API srv. action, process .leo/export files/...etc.
>

​Yes, in general, but many complications might appear.
​


> *Summary*
>>
>> Leo's plugin (javascript) acts like Leo's gui code. The plugin will also
>> handle some (most?) of Leo's commands.  Commands requiring extensive python
>> code will be passed to the python kernel (per-outline namespace).  Results
>> passed back to Leo's js plugin code then update the screen and Leo's js
>> data structures.
>>
>
> but, this plugin will very large , and the profit only:
> 0: new GUI
> 1: maybe new user from Atom user group
> not others?
>

​There are many advantages to atom besides a new gui.  These come from
node.js modules.​


CoffeeScript nature problem is:
> if some error, the debug report just for generated js not coffeescript,
> means, we can not know which line is error.
>
> so for efficiency,
> write nature JS, will debug quickly;
>
> but for Pythonisat, write JS will feeling so ugly.
>

​*If* I do this project I would use coffeescript2.​


​Edward​

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Xavier G. Domingo (xgid)]

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 
> 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 the cross-file search capabilities, even with regular 
> expressions, and with results being updated "on the fly" along your file 
> edits) and with a rich and constantly improving extensibility API 
> . Oh, and it 
> also uses Shift-Ctrl-P to open the Command Palette!
>
> I'm just starting to know the good and the ugly of VSCode, but I've seen 
> some really good design decisions so far and a constant focus on improving 
> the overall performance and UX of the editor. Another plus for me is that 
> it's mainly written in TypeScript, quite better than "plain" javascript.
>
> So well, I just wanted to say that I find your proposal really appealing. 
> I would really love to have all Leo features in VSCode in the near future!
>
> Either Atom or VSCode, I agree they *might* be the future of Leo! These 
> are really exciting times.
>
> Yours, 
> Xavier
>
> On Tuesday, February 20, 2018 at 12:52:38 PM UTC-3, 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 
>>  
>> and read Atom Basics 
>>  
>> page.  Make sure to try Shift-Ctrl-P :-)
>>
>> The atom editor deserves serious consideration as a "hosting platform" 
>> for Leo's technology, for at least the following reasons:
>>
>> - Afaik, atom does everything it has *in common* with Leo significantly 
>> better than Leo does.  That includes installing plugins and themes, 
>> managing the screen, search/replace, basic settings, minibuffer interface, 
>> syntax coloring, auto-completion, support for git, rendering markdown, 
>> IPython/Jupyter support, etc. Atom might win the "most cool features" award 
>> among all text editors and ide's.
>>
>> - Atom has superb docs, and is significantly easier for newbies to use 
>> than Leo.
>>
>> - Atom is "going places".  Atom has a large user base and many active 
>> devs. Atom boasts hundreds of plugins, including:
>>
>> hydrogen : Adds IPython-like 
>> features and was inspired by Light Table, with similar features. Another 
>> post will discuss how this might be adapted to form the basis of a Leo 
>> plugin for Atom. This apparently replaces the jupyter-notebook plugin.
>>
>> remote-edit : Supports browsing 
>> and editing remote files using FTP and SFTP.
>>
>> This page  
>> lists all atom plugins, sorted by most downloads.
>>
>> - Atom is a desktop App. From the Why Atom? 
>>  page:
>>
>> "Web browsers are great for browsing web pages, but writing code is a 
>> specialized activity that warrants dedicated tools. More importantly, the 
>> browser severely restricts access to the local system for security reasons, 
>> and for us, a text editor that couldn't write files or run local 
>> subprocesses was a non-starter."
>>
>> - Atom uses the *latest* version of the Chrome rendering engine.  From 
>> the Why Atom? 
>>  page:
>>
>> "Another great benefit [of Atom] is the guarantee that it's running on 
>> the newest version of Chromium. That means we can ignore issues like 
>> browser compatibility and polyfills. *We can use all the web's shiny 
>> features of tomorrow, today*."
>>
>> - Atom plays well with C++ (or Python): From the Why Atom? 
>>  page:
>>
>> "Interacting with native code is also really simple. For example, we 
>> wrote a wrapper around the Oniguruma regular expression engine for our 
>> TextMate grammar support. In a browser, that would have required adventures 
>> with NaCl or Esprima. Node integration made it easy."
>>
>> *Summary*
>>
>> Atom has virtually everything, *except* those features that make Leo 
>> what it is, namely scripting *in Python,* scripting API, clones, access 
>> to outline data, @clean, etc. We might delegate everything else to atom ;-)
>>
>> The big question is, can Leo remain Leo when hosted on atom?  I believe 
>> the answer is yes.  The hydrogen 

Re: Atom might be Leo's future

[Xavier G. Domingo (xgid)]

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 the cross-file search capabilities, even with regular 
expressions, and with results being updated "on the fly" along your file 
edits) and with a rich and constantly improving extensibility API 
. Oh, and it also 
uses Shift-Ctrl-P to open the Command Palette!

I'm just starting to know the good and the ugly of VSCode, but I've seen 
some really good design decisions so far and a constant focus on improving 
the overall performance and UX of the editor. Another plus for me is that 
it's mainly written in TypeScript, quite better than "plain" javascript.

So well, I just wanted to say that I find your proposal really appealing. I 
would really love to have all Leo features in VSCode in the near future!

Either Atom or VSCode, I agree they *might* be the future of Leo! These are 
really exciting times.

Yours, 
Xavier

On Tuesday, February 20, 2018 at 12:52:38 PM UTC-3, 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 
>  
> and read Atom Basics 
>  
> page.  Make sure to try Shift-Ctrl-P :-)
>
> The atom editor deserves serious consideration as a "hosting platform" for 
> Leo's technology, for at least the following reasons:
>
> - Afaik, atom does everything it has *in common* with Leo significantly 
> better than Leo does.  That includes installing plugins and themes, 
> managing the screen, search/replace, basic settings, minibuffer interface, 
> syntax coloring, auto-completion, support for git, rendering markdown, 
> IPython/Jupyter support, etc. Atom might win the "most cool features" award 
> among all text editors and ide's.
>
> - Atom has superb docs, and is significantly easier for newbies to use 
> than Leo.
>
> - Atom is "going places".  Atom has a large user base and many active 
> devs. Atom boasts hundreds of plugins, including:
>
> hydrogen : Adds IPython-like 
> features and was inspired by Light Table, with similar features. Another 
> post will discuss how this might be adapted to form the basis of a Leo 
> plugin for Atom. This apparently replaces the jupyter-notebook plugin.
>
> remote-edit : Supports browsing and 
> editing remote files using FTP and SFTP.
>
> This page  
> lists all atom plugins, sorted by most downloads.
>
> - Atom is a desktop App. From the Why Atom? 
>  page:
>
> "Web browsers are great for browsing web pages, but writing code is a 
> specialized activity that warrants dedicated tools. More importantly, the 
> browser severely restricts access to the local system for security reasons, 
> and for us, a text editor that couldn't write files or run local 
> subprocesses was a non-starter."
>
> - Atom uses the *latest* version of the Chrome rendering engine.  From 
> the Why Atom? 
>  page:
>
> "Another great benefit [of Atom] is the guarantee that it's running on the 
> newest version of Chromium. That means we can ignore issues like browser 
> compatibility and polyfills. *We can use all the web's shiny features of 
> tomorrow, today*."
>
> - Atom plays well with C++ (or Python): From the Why Atom? 
>  page:
>
> "Interacting with native code is also really simple. For example, we wrote 
> a wrapper around the Oniguruma regular expression engine for our TextMate 
> grammar support. In a browser, that would have required adventures with 
> NaCl or Esprima. Node integration made it easy."
>
> *Summary*
>
> Atom has virtually everything, *except* those features that make Leo what 
> it is, namely scripting *in Python,* scripting API, clones, access to 
> outline data, @clean, etc. We might delegate everything else to atom ;-)
>
> The big question is, can Leo remain Leo when hosted on atom?  I believe 
> the answer is yes.  The hydrogen  
> package hints at the way forward.  More details in another post or two.
>
> My next prototype will be an atom plugin, following this excellent 
> tutorial .
>
> All comments welcome.
>
> Edward
>

-- 
You received this message because 

Re: ENB: Adding Leo to Atom

[Zoom.Quiet]

ENB <-- means ?

On Wed, Feb 21, 2018 at 2:32 AM, Edward K. Ream  wrote:

> This is blue sky thinking. Nothing is certain.
>
> The goal: *turn Atom into Leo in the simplest way possible*.
>
> The simplest thing that could possibly work might be to loosely base the
> leo plugin on the existing hydrogen plugin
> .
>
> Please enable the hydrogen plugin to Atom and follow along this simple
> example.
>
> 1. Create a new .py file and save it. Add this line:
>
> import os
>
> Select this line and hit Ctrl-enter (hydrogen:run). A check mark appears
> after the line.
>
> 2. Add this line, select it and hit Ctrl-enter again.
>
> os
>
> You should get something like this:
>
> os ||
>
> The vertical bars denote a faint box.. This indicates that "os" is part of
> a persistent namespace!
>
> Behind the scenes, hydrogen sends the expression "os" to a "kernel".
> Details fuzzy.
>
> Just this may be enough to form the basis of Leo support in atom!
> Something like this.  Details *very* fuzzy:
>
> - Javascript code (in atom) will draw Leo outlines.  This code will be
> based on core (atom) tree code.
>
>
this way is stable, because JS process XML is stable;


> - Opening a .leo file (in atom) will init *python state data* in the
> python kernel. *Python code* in the kernel will load the .leo file and
> create a representation (a tree of vnodes, or an sqlite db) of the outline *in
> the kernel namespace*. The python code will pass a representation (as
> json or cson) of the entire outline back to Leo's js plugin code.  This
> will only happen once, when opening the outline.
>

means all Leo's commands/plugins will process by python self, not change?


>
> - Leos' javascript code (in atom) will update the screen when inserting,
> deleting, moving, changing and cloning nodes.  So the js code acts pretty
> much like gui code. The js code must (probably) also update the python
> representation in the kernel namespace for the outline.
>
>

Wow, means Atom only make GUI part,
others actions all by python , same now, not change?


> - The execute-script command (in atom) will send the to-be-executed script
> to the kernel.  The kernel, using the state data for the outline, will run
> the script and return the value of the script, and any side effects of the
> script, again as json/cson.  Using this returned value, the gui code will
> insert, delete, move, change and cloned nodes on the screen.
>
>
means, Leo all kinds of commands/plugins will bind RESTful API,
Atom answer user's action,
sent/accept core API srv.
Leo base API srv. action, process .leo/export files/...etc.


> *Summary*
>
> Leo's plugin (javascript) acts like Leo's gui code. The plugin will also
> handle some (most?) of Leo's commands.  Commands requiring extensive python
> code will be passed to the python kernel (per-outline namespace).  Results
> passed back to Leo's js plugin code then update the screen and Leo's js
> data structures.
>
>
but, this plugin will very large , and the profit only:
0: new GUI
1: maybe new user from Atom user group
not others?


> An experienced atom programmer might be able to do this in a few days.  It
> will take me much longer—perhaps weeks or longer. That doesn't bother me.
> I will learn a lot along the way, including a lot about js/coffeescript
> tooling.
>
> Edward
>
> P.S.  Yesterday I learned that new js standards do *not* invalidate
> coffeescript (cs).  Instead, cs2 now generates "new" javascript directly.
> cs2 will break some cs1 code, but that's not a big deal and it doesn't
> affect a possible Leo plugin for atom.
>
>
CoffeeScript nature problem is:
if some error, the debug report just for generated js not coffeescript,
means, we can not know which line is error.

so for efficiency,
write nature JS, will debug quickly;

but for Pythonisat, write JS will feeling so ugly.


> Amazingly (to me) lots of js programmers seem to hate coffeescript.  But
> that's not my problem, since atom can be programmed in either js or cs2.
>
>
see: Vanilla JS http://www.vanilla-js.com/

the most powerful JS platform .


> EKR
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

-- 
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 

Re: Atom might be Leo's future

[Zoom.Quiet]

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 reason you say this?
>
> > VSCode base same construct with Atom...
> > - open big file slow more and more
> > - crash by memory broken
>
> This page
> 
> shows how to find very slow plugins.
>
> > for now Chrome become corrupt quickly,
>
> Atom uses Chromium rendering, not Chrome itself.  Don't know if this makes
> a difference.
>

we know Chromium is the Chrome opensource version,
except some Google advertisement components, Chromium is same Chrome,
but Chromium is radical than Chrome,
Chromium is the beta version for Chrome,
Chromium user just as Chrome's duty tester.

in fact , the Chrom* fast core reason -> V8 engine, is swollen by node.js .

of course Chrom* code tree is the one of best opensorce browser project,
but Atom not browser,
Leo also not.


>
>
> Edward
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: A Recent Article by Me

[Satish Goda]

This is awesome. I really think the following paragraph from your article 
summarizes the unparalleled utility of Leo.

Outliners impose structure on documents. Sadly, they can also impose 
structure on our thinking, making creativity a lot harder. Leo is 
different. Instead of imposing structure, it allows you to impose your own 
infrastructure, and then be as creative as you want. This brings the 
necessary chaos of creativity to heel when it is time to produce the 
document. The node structure creates ultimate flexibility when it comes to 
ordering scenes in chapter. Say good-bye to copy and paste and hello to 
drag and drop. 

I shared your article to my followers on LinkedIn.

Cheers,
Satish.

On Thursday, February 15, 2018 at 11:50:11 AM UTC-8, Chris George wrote:
>
> https://refiction.com/resource-reviews/leo-editor-for-writers
>
> The constraint was 650 words, no images.
>
> Hopefully this will bring a few more writers to Leo.
>
> Chris
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Shrinking pane contents

[SegundoBob]

Recently I switched from using my desktop and a mouse to using my laptop 
with a touchpad.  Much too often the contents of a Leo-Editor pane suddenly 
shrinks or expands.  Usually the text in the body pane shrinks to so tiny 
that the whole pane contents are just a few dots.  When this happens there 
is also a blue vertical bar on the left side of the body pane.  Sometimes 
the font becomes larger.  Sometimes the font becomes just a little 
smaller.  This clearly happens in response to something that I'm doing, but 
I have been unable to identify what causes it.  It could be key presses.  
It could be touchpad touches.  It could be a combination of the two.  Since 
I don't know why it happens, I also don't know how to undo it.  
Fortunately, it is not saved between sessions, so exiting and re-entering 
Leo-Editor undoes the problem.

Since it always only affects a single Leo-Editor pane, I think it is 
probably done by Leo-Editor, Qt4, or the free-layout code. I don't see how 
code specific to my laptop could be doing it.  My laptop is a Dell Latitude 
E6220.

Does anyone have any ideas that might help me?

Thanks.

SegundoBob

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Miles Fidelman]

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?

page. It would also be good to install atom

and read Atom Basics

page.  Make sure to try Shift-Ctrl-P :-)

The atom editor deserves serious consideration as a "hosting
platform" for Leo's technology, for at least the following reasons:



And here I was hoping you meant Atom & AtomPub - 
https://en.wikipedia.org/wiki/Atom_(Web_standard)


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

ENB: Adding Leo to Atom

[Edward K. Ream]

This is blue sky thinking. Nothing is certain.

The goal: *turn Atom into Leo in the simplest way possible*.

The simplest thing that could possibly work might be to loosely base the 
leo plugin on the existing hydrogen plugin 
.

Please enable the hydrogen plugin to Atom and follow along this simple 
example.

1. Create a new .py file and save it. Add this line:

import os

Select this line and hit Ctrl-enter (hydrogen:run). A check mark appears 
after the line.

2. Add this line, select it and hit Ctrl-enter again.

os

You should get something like this:

os ||

The vertical bars denote a faint box.. This indicates that "os" is part of 
a persistent namespace!

Behind the scenes, hydrogen sends the expression "os" to a "kernel".  
Details fuzzy.

Just this may be enough to form the basis of Leo support in atom!  
Something like this.  Details *very* fuzzy:

- Javascript code (in atom) will draw Leo outlines.  This code will be 
based on core (atom) tree code.

- Opening a .leo file (in atom) will init *python state data* in the python 
kernel. *Python code* in the kernel will load the .leo file and create a 
representation (a tree of vnodes, or an sqlite db) of the outline *in the 
kernel namespace*. The python code will pass a representation (as json or 
cson) of the entire outline back to Leo's js plugin code.  This will only 
happen once, when opening the outline.

- Leos' javascript code (in atom) will update the screen when inserting, 
deleting, moving, changing and cloning nodes.  So the js code acts pretty 
much like gui code. The js code must (probably) also update the python 
representation in the kernel namespace for the outline.

- The execute-script command (in atom) will send the to-be-executed script 
to the kernel.  The kernel, using the state data for the outline, will run 
the script and return the value of the script, and any side effects of the 
script, again as json/cson.  Using this returned value, the gui code will 
insert, delete, move, change and cloned nodes on the screen.

*Summary*

Leo's plugin (javascript) acts like Leo's gui code. The plugin will also 
handle some (most?) of Leo's commands.  Commands requiring extensive python 
code will be passed to the python kernel (per-outline namespace).  Results 
passed back to Leo's js plugin code then update the screen and Leo's js 
data structures.

An experienced atom programmer might be able to do this in a few days.  It 
will take me much longer—perhaps weeks or longer. That doesn't bother me. I 
will learn a lot along the way, including a lot about js/coffeescript 
tooling.

Edward

P.S.  Yesterday I learned that new js standards do *not* invalidate 
coffeescript (cs).  Instead, cs2 now generates "new" javascript directly.  
cs2 will break some cs1 code, but that's not a big deal and it doesn't 
affect a possible Leo plugin for atom.

Amazingly (to me) lots of js programmers seem to hate coffeescript.  But 
that's not my problem, since atom can be programmed in either js or cs2.

EKR

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Edward K. Ream]

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...
> - open big file slow more and more
> - crash by memory broken

This page 

 
shows how to find very slow plugins.

> for now Chrome become corrupt quickly,

Atom uses Chromium rendering, not Chrome itself.  Don't know if this makes 
a difference.

Edward

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Atom might be Leo's future

[Zoom.Quiet]

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
> 
> and read Atom Basics
> 
> page.  Make sure to try Shift-Ctrl-P :-)
>
> The atom editor deserves serious consideration as a "hosting platform" for
> Leo's technology, for at least the following reasons:
>
> - Afaik, atom does everything it has *in common* with Leo significantly
> better than Leo does.  That includes installing plugins and themes,
> managing the screen, search/replace, basic settings, minibuffer interface,
> syntax coloring, auto-completion, support for git, rendering markdown,
> IPython/Jupyter support, etc. Atom might win the "most cool features" award
> among all text editors and ide's.
>
> - Atom has superb docs, and is significantly easier for newbies to use
> than Leo.
>
> - Atom is "going places".  Atom has a large user base and many active
> devs. Atom boasts hundreds of plugins, including:
>

... has a large user... <-- that is maybe hallucination ;-)
VSCode base same construct with Atom,
and now has same problems:
- open big file slow more and more
- crash by memory broken
- ...

in fact, most problem 's root just come from --> Chromium
Chromium/Chrome grasp the world marketplace,
now base quality, just base google's android and AD pv

for now Chrome become corrupt quickly,
in the true life, i main browser is always FireFox v56;
the important action in Safari,
only the gmail/facebook/youtube/... need anti-GFW action , in Chrome.



>
> hydrogen : Adds IPython-like
> features and was inspired by Light Table, with similar features. Another
> post will discuss how this might be adapted to form the basis of a Leo
> plugin for Atom. This apparently replaces the jupyter-notebook plugin.
>
> remote-edit : Supports browsing and
> editing remote files using FTP and SFTP.
>
> This page 
> lists all atom plugins, sorted by most downloads.
>
>
as same reason, like NPM grown so high-speed,
the Atom plugin grown high-speed,
but for the function, always not good enough than sublime text ecology...



> - Atom is a desktop App. From the Why Atom?
>  page:
>
> "Web browsers are great for browsing web pages, but writing code is a
> specialized activity that warrants dedicated tools. More importantly, the
> browser severely restricts access to the local system for security reasons,
> and for us, a text editor that couldn't write files or run local
> subprocesses was a non-starter."
>
> - Atom uses the *latest* version of the Chrome rendering engine.  From
> the Why Atom?
>  page:
>
> "Another great benefit [of Atom] is the guarantee that it's running on the
> newest version of Chromium. That means we can ignore issues like browser
> compatibility and polyfills. *We can use all the web's shiny features of
> tomorrow, today*."
>
> - Atom plays well with C++ (or Python): From the Why Atom?
>  page:
>
> "Interacting with native code is also really simple. For example, we wrote
> a wrapper around the Oniguruma regular expression engine for our TextMate
> grammar support. In a browser, that would have required adventures with
> NaCl or Esprima. Node integration made it easy."
>
> *Summary*
>
> Atom has virtually everything, *except* those features that make Leo what
> it is, namely scripting *in Python,* scripting API, clones, access to
> outline data, @clean, etc. We might delegate everything else to atom ;-)
>
>
agree, hosting base Atom, is better than re-build Leo's core by rust


> The big question is, can Leo remain Leo when hosted on atom?  I believe
> the answer is yes.  The hydrogen 
> package hints at the way forward.  More details in another post or two.
>
> My next prototype will be an atom plugin, following this excellent
> tutorial .
>
>
Yes, as NPM tutorial, node.js 's all kinds of tutorial is beauty than
python's,
but that is can not fixed the JS nature problems with burn.


> All comments welcome.
>
> Edward
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at 

Atom might be Leo's future

[Edward K. Ream]

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 Atom Basics 
 page.  
Make sure to try Shift-Ctrl-P :-)

The atom editor deserves serious consideration as a "hosting platform" for 
Leo's technology, for at least the following reasons:

- Afaik, atom does everything it has *in common* with Leo significantly 
better than Leo does.  That includes installing plugins and themes, 
managing the screen, search/replace, basic settings, minibuffer interface, 
syntax coloring, auto-completion, support for git, rendering markdown, 
IPython/Jupyter support, etc. Atom might win the "most cool features" award 
among all text editors and ide's.

- Atom has superb docs, and is significantly easier for newbies to use than 
Leo.

- Atom is "going places".  Atom has a large user base and many active devs. 
Atom boasts hundreds of plugins, including:

hydrogen : Adds IPython-like features 
and was inspired by Light Table, with similar features. Another post will 
discuss how this might be adapted to form the basis of a Leo plugin for 
Atom. This apparently replaces the jupyter-notebook plugin.

remote-edit : Supports browsing and 
editing remote files using FTP and SFTP.

This page  
lists all atom plugins, sorted by most downloads.

- Atom is a desktop App. From the Why Atom? 
 page:

"Web browsers are great for browsing web pages, but writing code is a 
specialized activity that warrants dedicated tools. More importantly, the 
browser severely restricts access to the local system for security reasons, 
and for us, a text editor that couldn't write files or run local 
subprocesses was a non-starter."

- Atom uses the *latest* version of the Chrome rendering engine.  From the Why 
Atom?  
page:

"Another great benefit [of Atom] is the guarantee that it's running on the 
newest version of Chromium. That means we can ignore issues like browser 
compatibility and polyfills. *We can use all the web's shiny features of 
tomorrow, today*."

- Atom plays well with C++ (or Python): From the Why Atom? 
 page:

"Interacting with native code is also really simple. For example, we wrote 
a wrapper around the Oniguruma regular expression engine for our TextMate 
grammar support. In a browser, that would have required adventures with 
NaCl or Esprima. Node integration made it easy."

*Summary*

Atom has virtually everything, *except* those features that make Leo what 
it is, namely scripting *in Python,* scripting API, clones, access to 
outline data, @clean, etc. We might delegate everything else to atom ;-)

The big question is, can Leo remain Leo when hosted on atom?  I believe the 
answer is yes.  The hydrogen  package 
hints at the way forward.  More details in another post or two.

My next prototype will be an atom plugin, following this excellent tutorial 
.

All comments welcome.

Edward

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: effective collaborate with .leo for doc.?[via]Advices for Leo documentation in Chinese translated version?

[Zoom.Quiet]

On Tue, Feb 20, 2018 at 12:45 AM, Edward K. Ream  wrote:
> On Mon, Feb 19, 2018 at 9:33 AM, Zoom.Quiet  wrote:
>> after test, i confirm:
>>
>> - change @rst -> @clean, will lost so many rST need support by Leo
>> - and @rst really can not auto merge changed from out files
>
>
> Yes, this is a problem. I don't know of any simple solution.
>

for my experience, the old version of Leo base Tangle & Untangle make
3 worlds exchange:
0: product world -> out files
1: think world -> outlines
2: work world -> edit pane

but Leo support more and more commands (like @others <>...)
that make the one action pair Tangle & Untangle can not simple support
all kinds of commands expand actions,
so EKR build new file type commands (like @rst @clean), include
special Tangle processes;
but product world -> think world, is more complex...?

but @clean can base 'Recovered Nodes' auto merged product world change,
why others file type nodes can not?

in face, git/hg/cvs/... all kinds of VCS can:
0: auto fix most conflict
1: if not, will export good structural diff log

so for Leo reflect these info. just 2 ways:
0: perfect understand conflict/diff, and re-write right node content
1: not re-write any node, just insert nodes report the conflict/diff,
help people result them

i hope Leo support the simple way:
just insert alert nodes near conflict contents,
and lock the save action, until fixed all alert nodes ; -)

> I would consider writing scripts that would read/write parts of LeoDocs.leo
>
> to some external file.  It would even be possible to execute these scripts
> automatically using, say, Leo's 'save2' and 'open2' events.  See this page.
>
http://leoeditor.com/writingPlugins.html#summary-of-event-handlers

WoW ... Leo support s many events now, that look like some thing
in the deep base is maybe not lite enough?

> Edward
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.



-- 
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.