Re: Might be interesting for Leo WebApp

[Matt Wilkie]

 
>
> I just stumbled upon a web outliner:
>>
>> https://dynalist.io/
>>
> Even without source code, it has good ideas about its use and how it 
> presents its tutorial in the live demo.
>

2 things from https://dynalist.io/why that immediately jump out at me as 
very good ideas: 

   - `[[` combined with find-as-type to create a link to anywhere 
   - Move with find-as-type to move anywhere

Really they're the same idea with different verbs: link, move, copy. I like 
the concept of replacing {action}{navigate}{target} with {action}{target}. 
Spiritually similar to Leo *clone-to-at-spot *and *clone-to-last-node* but 
without predefined destinations.

Matt

-- 
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: LeoWapp plans

[Matt Wilkie]

>
> I think "Flexx uses tornado" was a crossing of threads (ha ha ha), I 
> don't think it does. 
>

I know nothing about web sockets or the frameworks discussed in this 
thread, but the docs say 
 *"Flexx 
further depends on the following packages (all are pure Python, and the 
latter three are projects under the flexxui umbrella): Tornado, 
PScript,Webruntime,Dialite". *So yes it uses Tornado, but maybe not for 
sockets -- there is wording in 
https://flexx.readthedocs.io/en/stable/app/api.html?highlight=tornado 
indicating that while Tornado is required right now they're leaving the 
door open for different back ends in future.

Matt

-- 
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: File changes outside of Leo

[Rob]

Thanks, Edward. This has been really tricky to track down, but that helps 
narrow it down. This is *not* a Leo issue, but perhaps Leo's code can help 
me figure out what's going on.

Rob...

On Thursday, November 1, 2018 at 10:46:03 AM UTC-4, Edward K. Ream wrote:
>
> On Fri, Oct 19, 2018 at 4:34 PM Rob > 
> wrote:
>
> So, two questions for the Leo gurus:
>>
>>1. What does Leo `see` in the files that triggers the message and the 
>>dialog?
>>
>> Iirc, Leo looks at the actual modification dates.  This is done at idle 
> time. For all the details, see the ExternalFilesController class in 
> leoExternalFiles.py. Here is the docstring:
>
> A class tracking changes to external files:
> - temp files created by open-with commands.
> - external files corresponding to @file nodes.
> This class raises a dialog when a file changes outside of Leo.
> [snip]
>
> HTH.
>
> 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.

The "skeleton" branch contains recent work on LeoWapp

[Edward K. Ream]

I am switching to a new branch because of some strange interaction with the 
leowapp.py plugin and .leo files.

Given the nature of the work, I probably should have done this sooner.

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: LeoWapp plans

[Edward K. Ream]

On Thursday, November 1, 2018 at 10:04:08 AM UTC-5, Edward K. Ream wrote:

With every step I take on this project, the goal seems to get closer faster 
> than expected.
>

I expect to complete the so-called skeleton in a day or three.  When that 
happens, devs will be able to prototype LeoWapp with their favorite 
framework.  They will use their framework to create Leo's javascript 
widgets. Starting with the skeleton, devs will fill in the details of 
communicating between python and javascript.  

To repeat, it's reasonable to experiment with multiple prototypes.  The 
skeleton will handle *everything* involving the interface with Leo's core. 
The skeleton will be in the devel branch. Devs should create separate git 
branches for individual prototypes.  I'll be creating a "flexx" branch when 
the skeleton is complete.

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: LeoWapp plans

[Edward K. Ream]

On Thursday, November 1, 2018 at 5:53:39 AM UTC-5, Edward K. Ream wrote:

Rev 64742bc16 in dev demonstrates the main idea. 
>
> Starting Leo with `leo --gui=browser` successfully goes through Leo's 
> startup logic and calls BrowserGui.runMainLoop, which in turn runs all 
> Leo's unit tests and exits:
>
 
[snip] 
 

> This is mostly a fake, because BrowserGui is a subclass of NullGui, and 
> NullGui is designed to pass all unit tests.
>

Aha.  *The BrowserGui must use string widgets*, just like the NullGui 
does!  Indeed, there are no other widgets to use!  This means that (in a 
limited sense, see below) the BrowserGui really and truly *does *already 
pass all unit tests.

I'm dithering about whether the BrowserGui class should actually be a 
subclass of NullGui.  There are arguments to be made each way.  In any 
case, the BrowserGui must override all (or almost all) methods of the 
NullGui class, because in addition to updating the string widgets the 
BrowserGui must *also* pass on those changes to the javascript.

*Symmetry*

It's important to understand the *inherent *symmetry between the python and 
javascript sides.  When using the BrowserGui, all unit tests use the 
high-level api to "drive" the python code.  That's why all the unit tests 
pass, and should *continue* to pass when changes to the string widgets get 
passed on to the javascript widgets.

Similarly, when the javascript code changes the js widgets, those changes 
must be passed to python. From a *communication *standpoint, the situation 
is completely symmetric.  Changes to the python widgets get passed on to 
javascript, and vice versa.

The details of the communication need not be, and probably will not be, so 
symmetric.  The python widgets change as the result of calls to the 
high-level api, but the javascript code is free to "summarize" changes to 
the js widgets.

*Summary*

The BrowserGui class *already *implements string widgets. This suffices to 
have all unit tests pass now, and they should naturally *continue* to pass 
as work progresses.

The BrowserGui methods (for the high-level api) must also call their 
corresponding js methods (except during unit testing?)  to keep the js 
widgets in sync. Symmetrically, the javascript code must update the python 
string widgets when the js widgets change.

With every step I take on this project, the goal seems to get closer faster 
than expected.

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: File changes outside of Leo

[Edward K. Ream]

On Fri, Oct 19, 2018 at 4:34 PM Rob  wrote:

So, two questions for the Leo gurus:
>
>1. What does Leo `see` in the files that triggers the message and the
>dialog?
>
> Iirc, Leo looks at the actual modification dates.  This is done at idle
time. For all the details, see the ExternalFilesController class in
leoExternalFiles.py. Here is the docstring:

A class tracking changes to external files:
- temp files created by open-with commands.
- external files corresponding to @file nodes.
This class raises a dialog when a file changes outside of Leo.
[snip]

HTH.

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: LeoWapp plans

[Edward K. Ream]

On Thu, Nov 1, 2018 at 5:53 AM Edward K. Ream wrote:

> The skeleton will provide explicit redirection methods for each and every
member of the high-level api...
> the BrowserGui class [will be] a subclass of LeoGui, not NullGui.  This
will force the BrowserGui class to implement all methods of the high-level
api that subclasses of LeoGui are required to implement.
>These methods will like all call something like bg.message(kind, *args,
**kwargs).

Not quite. What these methods do may depend on the framework.

Maybe in flex we can redirect to js using something that looks like python,
but the most general form of the calls will be: `bg.message(kind,
payload)`, where the exact form of the payload depends on the framework.

In any case, this is all the more reason to use a separate BrowserGui
method for each method of Leo's high-level api.

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: LeoWapp plans

[Edward K. Ream]

On Wednesday, October 31, 2018 at 3:22:44 PM UTC-5, Edward K. Ream wrote:

This is close to my present plans, which is to create what might be called 
> a skeleton browser gui.
>

Rev 64742bc16 in dev demonstrates the main idea. 

Starting Leo with `leo --gui=browser` successfully goes through Leo's 
startup logic and calls BrowserGui.runMainLoop, which in turn runs all 
Leo's unit tests and exits:

def runMainLoop(self, fileName=None):
'''The main loop for the browser gui.'''
if fileName:
print('LeoWapp running: %s...' % g.shortFileName(fileName))
else:
print('LeoWapp running...')
if 1: # Run all unit tests.
path = g.os_path_finalize_join(
g.app.loadDir, '..', 'test', 'unittest.leo')
c = g.openWithFileName(path, gui=self)
c.findCommands.ftm = g.NullObject()
# A hack. Maybe the NullGui should do this.
c.debugCommands.runAllUnitTestsLocally()
print('calling sys.exit(0)')

sys.exit(0)

This is mostly a fake, because BrowserGui is a subclass of NullGui, and 
NullGui is designed to pass all unit tests.

But still, the work so far will likely be the *only* changes to Leo's 
core.  As expected, they have been minimal.

*Next Phase*

At present, the BrowserGui class contains a __getattr__ method, but in fact 
this wasn't needed and actually complicated subclassing BrowserGui from 
NullGui.

bg.__getattr__ is:

def __getattr__ (self, attr):
'''Handle an missing attribute.'''
if attr in (
'frameFactory',
'set_minibuffer_label',
):
# These are optional ivars.
raise AttributeError
# Simulate the handling of the function call.
return self.message(attr)

The idea is that bg.message is a stand in for code that would redirect 
calls to javascript.

However, when I wrote this I realized that there doesn't seem to be a way 
make those calls with any arguments.  Perhaps there is a clever way.  But 
it doesn't matter. Imo, __getattr__ is usually too clever by half, and this 
is no exception.

Instead, the skeleton will provide explicit redirection methods for each 
and every member of the high-level api.  This brute force approach will 
simplify debugging, which __getattr__ *always* complicates.

*Summary*

Work so far has gone *exactly* as expected. To do:

- Make the BrowserGui class a subclass of LeoGui, not NullGui.  This will 
force the BrowserGui class to implement all methods of the high-level api 
that subclasses of LeoGui are required to implement.

- These methods will like all call something like bg.message(kind, *args, 
**kwargs).

- bg.message is supposed to pass messages to the js framework, whatever it 
is.

Until bg.message becomes functional, most gui-related unit tests should 
fail.  That's actually progress.

I expect to complete the skeleton today.  At that point, anyone should be 
able to use the skeleton on whatever gui framework they like.  If you are 
interested in doing so, please do your work in a separate git branch.

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: Proposal: eliminate --script and --script-window command-line options

[Edward K. Ream]

On Thursday, November 1, 2018 at 2:29:27 AM UTC-5, Edward K. Ream wrote:

I was shocked yesterday by how baroque Leo's --script logic is
>

Part of this complexity arises from a failure to refactor code.  Yesterday 
I added the app.createBrowserGui.  It took much longer than expected due to 
logic that is unnecessarily convoluted by handling --script.

Yes, I could refactor the code now, but that would be much simpler if 
--script just went away.  But to repeat, there is no particular rush. The 
work has already been done.

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.

Proposal: eliminate Leo's run-unit-tests externally commands

[Edward K. Ream]

If we can eliminate --script, we probably can also eliminate Leo's various 
commands that execute unit tests in a separate process.

This page 
 
tells how to run unit tests externally using Leo's bridge. Note in 
particular that the code calls c.debugCommands.runSelectedUnitTestsLocally() 
!  Btw, the code should probably just call runAllUnitTestsLocally(), rather 
than rely on the name of a node in unitTest.leo.

I would very much like to eliminate these commands, for at least two 
reasons:

- Leo's unit tests contain special cases for tests run externally.  It 
might be possible to eliminate those special cases.

- The code that runs unit tests externally is horrible.

*Summary*

As with the previous proposal, the question is whether there is *any* 
situation in which Leo's run-unit-tests-externally commands are useful.  
Your comments please.

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.

Proposal: eliminate --script and --script-window command-line options

[Edward K. Ream]

Don't panic.  This is only a proposal. 

I was shocked yesterday by how baroque Leo's --script logic is, and further 
surprised about how much easier it is to bypass --script with an external 
python script that uses Leo's bridge.  Btw, this page 
 
shows how to invoke Leo's bridge using an elisp script.

Heh.  This reply 
, 
written yesterday, recreated the code described here 
,
 
in the LeoBridge documentation. Which illustrates Sapphira's point 
 that 
it's not always easy to remember or locate where all the useful snippets of 
code are.

Aside: Terry points out here 
that 
you can not just run leoBridge from Leo, because the leoBridge module is 
designed to run a separate copy of Leo.

*Summary*

The --script option has limited use cases.  The question is whether there 
are *any* situations in which --script is essential.  I doubt it, but I 
won't do anything until I hear all your comments.  There is no particular 
rush.

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.