Re: Discuss: a proposed answer to python issue #33337

[Terry Brown]

I wonder if a couple of demos would help, "see how much better this is"
rather than "ask me about how much better this is".  Maybe a comparison
like: https://gist.github.com/kennethreitz/973705
which compares `urllib2` to `requests` code to do the same thing.
And perhaps some context like "I want to know if this seems like a
candidate for inclusion before I put together all the integrated docs. /
tests / implementation pull request" to make it obvious you not expecting
someone else to do all that.

A slightly different route might be to do the above demo / comparison stuff
in a fully fledged package on GitHub / pypi / readthedocs so that you can
get some feedback from people trying it out then propose getting into core
libs by referencing the package.  Maybe you've already started in that
direction, not sure.

Cheers -Terry

On Tue, Jan 14, 2020 at 12:30 PM Edward K. Ream  wrote:

> Here is the first draft of a reply to Python issue #7
> . This long-dormant issue discusses
> possible improvements to python tools.
>
> I would appreciate it if you would read the thread in detail, and let me
> know if the following reply seems on topic and useful. Thanks.
>
> = Start Post
>
> > So if users want to write tools that manipulate Python code, the standard
> library doesn't provide them with great options.
>
> > I suggest the following plan:
>
> Hello all,
>
> I would like to suggest another possibility.
>
> For about three months I have been obsessed with the general problem of
> manipulating Python source code *easily*. I have long experience with such
> tools.  Along the way I have studied the
> [asttokens](https://pypi.org/project/asttokens/),
> [fstringify](https://pypi.org/project/fstringify/), and
> [black](https://pypi.org/project/black/) projects.
> Imo, each in its own way illustrates that something significantly better
> would be welcome. Each project uses complex, idiosyncratic, opaque
> generators to generate results. What if something much simpler were
> possible?
>
> In late October, 2019 I completed a token-based version of fstringify. I
> could have stopped there, but then a new thought intruded. What if we could
> define a **token-order traversal** of parse trees? This new idea sparked an
> avalanche of new ideas. I couldn't let them go.
>
> After three months of literally day and night development this single idea
> has turned into a major new tool, contained at present in [leoAst.py](
> https://github.com/leo-editor/leo-editor/blob/fstrings/leo/core/leoAst.py).
> The code is simple, general, flexible, and fast, in stark contrast to the
> tools mentioned above.
>
> Leo's [issue #1440](https://github.com/leo-editor/leo-editor/issues/1440)
> (Unify the ast and token worlds)
> contains extensive documentation for this project. The first comment
> contains an overview of the project, the second comment contains a Theory
> of Operation, and the third contains a History of the Project, with links
> to the many Engineering Notebook (ENB) post that I wrote along the way.
>
> Imo, the TokenOrderGenerator (TOG) and TokenOrderTraverser (TOT) might be
> candidates for inclusion in the standard library, but first you Python devs
> will want to decide whether this project is actually something that is even
> vaguely of interest to you :-)
>
> I will be happy to answer any questions you may have. Please let me know
> your thoughts.
>
> Edward K. Ream
> An old man, crazy about computer programming
>
> = End Post
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/c70a9009-31d5-4cc4-b8d4-6e3af34d6d9f%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46RmMgwVzuvRdU6G%2BgWR346rkNy61scpSPc0F4BUNqDzuw%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Terry Brown]

On Sat, 28 Dec 2019 02:17:06 -0800 (PST)
"Edward K. Ream"  wrote:

> Bob's remarks yesterday about unit testing had me look at Leo's unit 
> testing framework with new eyes. 
> 
> #1467  suggest
> using traditional unit tests everywhere, or maybe almost everywhere.

Sounds like a good idea.  I suspect pytest https://docs.pytest.org/
is used by major projects more routinely than Python's "built-in" library, so I
would evaluate that before making the switch.

Cheers -Terry

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20191228123737.5a80d28b%40lakeview.

Re: Weird space character

[Terry Brown]

"Vanilla" LaTeX systems tend to use `pdflatex` to process things, and don't
understand unicode inputs without extra fiddling.  If you use XeTeX
(`xelatex`), it assumes unicode by default and makes things simpler - in a
lot of cases it can be a drop in replacement.  I think TeXLive supports
either, pandoc can certainly use either.

It's really bad when you go from 27 μg/L nitrate (micro-grams per liter) in
your drinking water to 27 g/L because LaTeX doesn't render the μ :-S

Cheers -Terry



On Fri, Oct 18, 2019 at 7:50 AM Rob  wrote:

> I re-read the error message in the LaTeX processor and perhaps I should
> clarify.
>
> Keyboard character used is undefined in inputencoding`utf8'.
>
> Reviewing the documentation for that package (inputenc) suggests the error
> is because there is no corresponding glyph to map to output. So, it's
> really a function of the processor's inability to deal with the character.
>
> After show-invisibles I see all the regular spaces as dots. The offending
> character doesn't have anything, just looks like a space, making it
> difficult to find (see screenshot). Not sure what, if anything can done
> about it.
>
> Thanks for the suggestion to use show-invisibles. It doesn't show lie
> feeds, though (see screenshot from Notepad++). Don't know how important
> that is, though.
>
> Rob...
>
> [image: 191018 Leo utf8.png]
>
> [image: 191018 NP++ utf8.png]
>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/4df9f0af-3133-4a08-929c-503e887fc0a8%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46Q%2BpQwDnXq9M0--00k_gZrWjKgTHb%2BykpUOk3ZFsB4pHw%40mail.gmail.com.

Re: Chris: cause of outline artifact?

[Terry Brown]

On Sun, 8 Sep 2019 13:25:23 -0700 (PDT)
Chris George  wrote:

> After extensive testing I have determined that my initial conclusions
> hold.
> 
> With all else being equal (this took some effort), if the python 
> environment leois running under is native to the OS the stylesheet is 
> flawless.
> 
> If leo is running under a venv of any flavor (including conda) the 
> artifacts appear.
> 
> Changing the stylesheet while using the venv doesn't work. Gammaray
> doesn't help. As far as it is concerned it is the same object with
> the same properties. 
> 
> I am stumped.

Could something else like screen dpi determination be different?

Can you run the OS native version (partially) in the venv?  Perhaps
just get Python from the venv not the Qt stuff - you'd have to tell the
venv to use system libs.  Then just PyQt from the venv not Python / Qt,
etc. if that pattern makes sense.

Cheers -Terr

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190908154933.1e63e7fe%40lakeview.

Re: Refactoring probably means using signals

[Terry Brown]

When we talked about this previously I looked at
https://pythonhosted.org/blinker/  and it seemed quite good, trying to find
it again I
also see
https://github.com/dgovil/PySignal
"A purely Python implementation of the Qt signal system with no QObject
dependencies"
if you want to think about something that doesn't tie you to Qt / allows a
null-gui Leo state machine kind of thing.

Cheers -Terry

On Fri, Aug 23, 2019 at 8:11 AM Edward K. Ream  wrote:

> Leo's code is a behemoth. Nothing we can do is going to drastically shrink
> it, or make it a snap to understand or change.
>
> Imo, using Qt's signals more effectively is likely to be the best way to
> simplify Leo's code *just a little bit.*  This page
> 
> explains the benefits.
>
> Signals aren't a panacea. Understanding signals and their interactions
> isn't trivial.  However, cff  gives an excellent overview.
>
> I don't have any immediate plans to use more signals in Leo.  However, I
> would welcome any experiments in this direction.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/c744c586-929e-4229-b2b0-9c4166d40eb1%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46TwNtxQ%2BWconi2dFLF9iJmMOXHGWkoK2LexsRyLEGQf-g%40mail.gmail.com.

Re: New Themes

[Terry Brown]

There is the Ctrl-+/- / Ctrl-mousewheel font zoom functionality to
consider.  I don't think it was incompatible with themes, it just required
specific naming conventions... maybe, I don't remember the details.
Anyway, just pointing out that factor's in there to be considered.

Cheers -Terry

On Tue, Aug 20, 2019 at 10:44 AM Chris George  wrote:

> It looks like the themes are supplanting font info but not anything else.
> For example, if I specify a setting in a theme file it gets overridden by
> myLeoSettings.leo which is the expected behaviour. Having the font info in
> a theme override that is inconsistent but could/should be offered as a
> choice. Or we should pick one way of doing it and eliminate the choice.
>
> I have always thought it rather puzzling to have self-contained themes and
> then an entirely different way to set fonts.
>
> My preference is to set everything related to UI in the theme.
>
> I think that choice is Leonine. Whenever I propose a new way to do
> something I try to phrase it such that there should always be an @bool to
> offer choice so people can bend Leo to their own preferences. I believe
> that the default should be the theme as it gives new users one place to go
> to modify their UI experience.
>
> I have totally ignored the entire "other way" as it may well be someone
> else's preference. But for new users, it is terribly confusing.
>
> Chris
>
> On Tue, Aug 20, 2019 at 6:50 AM Edward K. Ream 
> wrote:
>
>>
>>
>> On Tue, Aug 20, 2019 at 8:32 AM Matt Wilkie  wrote:
>>
>>> A structural problem: theme font-size overrides myLeoSettings.leo, which
>>> I assume applies for all settings. I expect myLeoSettings to always have
>>> the last say.
>>>
>>
>> Hmm.  I'm not sure what I expect.
>>
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS03aB3BDf%3DTDKei80NCXWrw61Tpq2bYN3UBQ_iPrn%3DV9Q%40mail.gmail.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CADWQas0RPe-Qsm3%2Ba1rYkb%3D_v496KFKZRXZkMnPd1-A%3DmPp2-g%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46TddBoBk2pWgDWofEPMjoatmqAZne5znoKT8PMh%3Dm39Qw%40mail.gmail.com.

Re: Round-trip to shell script

[Terry Brown]

On Tue, 13 Aug 2019 08:57:03 -0700 (PDT)
Rob  wrote:

> There was also a reference to the leoscreen.py plugin, but that won't
> load w/o errors; perhaps not compatible w/ Python 3?

Not sure about Python 3 compatibility, but it works exclusively with
the `GNU screen` terminal multiplexer, a unix thing.  Very handy in
that context because you can interact with any command line driven
thing (Python, R, SQL, Bash, etc., etc.) from the Leo body pane, but no
use outside that context.

Cheers -Terry

> On Tuesday, August 13, 2019 at 11:39:08 AM UTC-4, Rob wrote:
> >
> > Thanks, will take a look.
> >
> > On Tuesday, August 13, 2019 at 11:33:33 AM UTC-4, gar wrote:
> >>
> >> Look at the plugins. 
> >> I didnt try any, but looks like 'at_produce' or 'interact' plugins
> >> are for you.
> >>
> >>>
> >>>
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190813112648.392213cb%40lakeview.

Re: Clearing uAs

[Terry Brown]

On Thu, 8 Aug 2019 14:40:23 -0700 (PDT)
Rob  wrote:

> Don't think it's a bug in backlinks.py as the same thing happens with
> Tags. I'll file a bug report anyway.

Yep, I misinterpreted your workflow, looks like the bug's in
clear-node-uas

Cheers -Terry

> Rob...
> 
> On Thursday, August 8, 2019 at 5:35:08 PM UTC-4, Terry Brown wrote:
> >
> > On Thu, 8 Aug 2019 14:14:36 -0700 (PDT) 
> > Rob > wrote: 
> >
> > > Attempting to clear up some missing backlink errors, I use the 
> > > commands, show-node-uas, then clear-node-uas. After the clear 
> > > command, I would expect the .leo file to be 'dirty' so as to
> > > prompt to save it. It doesn't. Is my expectation incorrect ? 
> > > 
> > > Rob... 
> > > 
> >
> > Your expectation seems reasonable. 
> >
> > Probably a bug in backlinks.py, not dirtying the outline after 
> > altering the .uAs. 
> >
> > Cheers -Terry 
> >
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190808165122.3c045889%40lakeview.

Re: Clearing uAs

[Terry Brown]

On Thu, 8 Aug 2019 14:14:36 -0700 (PDT)
Rob  wrote:

> Attempting to clear up some missing backlink errors, I use the
> commands, show-node-uas, then clear-node-uas. After the clear
> command, I would expect the .leo file to be 'dirty' so as to prompt
> to save it. It doesn't. Is my expectation incorrect ?
> 
> Rob...
> 

Your expectation seems reasonable.

Probably a bug in backlinks.py, not dirtying the outline after
altering the .uAs.

Cheers -Terry

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190808163504.3b537aaa%40lakeview.

Re: Leo and fossil merged with Rust

[Terry Brown]

Hah - convergent evolution, I've been looking at Jupyter lab. in that kind
of context recently too.

The rest of this is off-topic, but I encourage people to play with the
Jupyter *lab* (not notebook) UI for Leo ideas.
It's basically multiple notebooks in multiple kernels plus consoles and
regular text file editing, file browsing, etc.

Here's an amusing trick to get Google to give you a free computer (for 12
hours, but then another one, and so on).

Sign up for

https://colab.research.google.com/

now you have a Jupyter *notebook* on a machine somewhere which can mount
your Google drive.  But no one who's used Jupyter lab. wants a Jupyter
notebook.  No problem, this notebook:
https://medium.com/@swaroopkml96/jupyterlab-and-google-drive-integration-with-google-colab-42a8d64a9b63
lets you run Jupyter lab. in the notebook, then you can access the lab. UI
instead.

I guess the machines are for learning machine learning, but there seems to
be no restriction on what you do with them, they're Ubuntu 18.04.  I think
they only last for 12 hours but if you mount your google drive storage
there is permanent.  I also noticed going from free 15 Gb Google drive
storage to 100 Gb is quite affordable, $16/*year* maybe?

I think something was broken in the above recipe for me, so I'll post the
code blocks I'm using below.

Leo docker wise not really, although I think I recently tested this Leo as
a web app. hack and found it still worked:
https://github.com/tbnorth/leo-docker  so that is Leo running in a headless
Docker container available via the web.

Cheers -Terry

Block 1

!pip install jupyterlab

Block 2

from google.colab import drive
drive.mount('/content/gdrive', force_remount=True)

Block 3

jupyter_running = !jupyter notebook list | grep 
if not jupyter_running:
  !mkdir -p /root/.jupyter
  !echo '{ "NotebookApp": { "password": "sha1:6f..MAKE YOUR OWN..9c" } }' >
/root/.jupyter/jupyter_notebook_config.json
  print(open("/root/.jupyter/jupyter_notebook_config.json").read())
  get_ipython().system_raw('jupyter lab &')
!ssh -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -R
YOURNAMEHERE:80:localhost: serveo.net 1>/dev/null

(the MAKE YOUR OWN etc. parts are explained in the linked article)


On Tue, Jul 30, 2019 at 9:39 AM Kent Tenney  wrote:

> Indeed.
> I haven't used Leo in a while, been playing with docker containers
> which configure and serve Jupyter lab on non-gui machines.
> This time machine kind of capability is the kind of thing to lure
> me back to Leo.
>
> Terry, I remember you mentioning that you're using Docker, do
> you have Leo related Dockerfile or docker-compose.yml ?
>
> Thanks,
> Kent
>
>
> On Mon, Jul 29, 2019 at 2:31 PM Terry Brown  wrote:
>
>> That is very cool.  I hope Kent sees it, he's talked about such things
>> more than once.
>>
>> Cheers -Terry
>>
>> On Mon, Jul 29, 2019 at 2:11 PM vitalije  wrote:
>>
>>> It has been a very long time since I've got this idea of combining Leo
>>> with fossil. For all these years I felt that there was a great potential in
>>> this mixture, but I haven't got the time to do anything about it until
>>> recently.
>>>
>>> Fossil uses an extremely good algorithm to calculate the difference
>>> between two texts. And the deltas produced by this algorithm are very
>>> compact and nice to work with. If the input texts are texts, than the delta
>>> is also a plain text. I have ported this algorithm from C in which fossil
>>> is originally written, to Rust programming language. The ported code is
>>> published on crates.io as fossil-delta
>>> <https://crates.io/crates/fossil-delta>. Using this library, I wrote a
>>> small web server which accepts snapshots sent from Leo periodically at idle
>>> time and calculates the delta between the previous one and the current one,
>>> and stores those deltas in the sqlite database. The server also serves
>>> small web application that allows user to browse history of any recorded
>>> Leo outline. Using two scale widgets user can choose any recorded version
>>> of the outline shape, and history of the selected node.
>>>
>>> Sending snapshots from Leo is done by the plugin which keeps track of
>>> the time passed since the last Leo command has been executed. When 5s pass
>>> since the last executed command, Leo calculates the snapshot and if it is
>>> different than the previous one it sends it in separate thread to the
>>> server. The whole process is almost unnoticeable by the user. The server
>>> stores the deltas in the database file (one database per Leo outline) which
>>> is located in the same folder as the Leo document, and 

Re: Leo and fossil merged with Rust

[Terry Brown]

That is very cool.  I hope Kent sees it, he's talked about such things more
than once.

Cheers -Terry

On Mon, Jul 29, 2019 at 2:11 PM vitalije  wrote:

> It has been a very long time since I've got this idea of combining Leo
> with fossil. For all these years I felt that there was a great potential in
> this mixture, but I haven't got the time to do anything about it until
> recently.
>
> Fossil uses an extremely good algorithm to calculate the difference
> between two texts. And the deltas produced by this algorithm are very
> compact and nice to work with. If the input texts are texts, than the delta
> is also a plain text. I have ported this algorithm from C in which fossil
> is originally written, to Rust programming language. The ported code is
> published on crates.io as fossil-delta
> . Using this library, I wrote a
> small web server which accepts snapshots sent from Leo periodically at idle
> time and calculates the delta between the previous one and the current one,
> and stores those deltas in the sqlite database. The server also serves
> small web application that allows user to browse history of any recorded
> Leo outline. Using two scale widgets user can choose any recorded version
> of the outline shape, and history of the selected node.
>
> Sending snapshots from Leo is done by the plugin which keeps track of the
> time passed since the last Leo command has been executed. When 5s pass
> since the last executed command, Leo calculates the snapshot and if it is
> different than the previous one it sends it in separate thread to the
> server. The whole process is almost unnoticeable by the user. The server
> stores the deltas in the database file (one database per Leo outline) which
> is located in the same folder as the Leo document, and has the '.history'
> appended to its name. For example: outline test.leo will have it's history
> stored in the database test.leo.history in the same folder.
>
> Below is the link to the video demonstration (if you have read everything
> above you can skip to the 3:00). There are some issues with the sound which
> I couldn't fix, but there are captions in English.
>
> The demo 
>
> Vitalije
>
> PS: the outline is about 210Kb, and database with about 625 recorded
> versions is about 450Kb. Those 625 versions were recorded during the 30
> hours time span.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/897a3b7a-554b-4db6-8501-ebafc1746214%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46QO%2B_nGcyPs-OV1V8aUbr1JZAooF0CT98NK63XhGTUuCQ%40mail.gmail.com.

Re: Leo and black

[Terry Brown]

Now that I think about it I started using Black before I stopped using
Leo.  I disagree with Vitalije's assessment of how often you'd execute it,
I found I quite often wanted a node tidied up.  But I would agree with
Vitalije on taking a minimalist light weight approach to using Black in
Leo.  I just set up a button to run it on the current node - thinking at
the time how cool it is that Leo makes doing that so easy.

Totally unrelated PSA: rabbitMQ - high performance cross language / cross
machine (cloud) message queue system - I'm probably just late to the party,
but it seems like the missing link in easy decoupling / connecting of
software.  Not saying it has some immediate relevance to Leo, just that
it's good to know about such things in general.

Cheers -Terry

On Mon, Jul 29, 2019 at 8:07 AM vitalije  wrote:

>
>
> On Monday, July 29, 2019 at 2:44:10 PM UTC+2, Edward K. Ream wrote:
>>
>> So it looks like Leo could optionally run blacken-node whenever selecting
>> and/or unselecting a node for which @language python is in effect.
>>
>>
> That would be rather invasive and most of the time unnecessary spending
> CPU time. Selecting nodes is already too complicated and not very fast (to
> say the least). Please don't add any more burden to it. Instead let the
> user decide when to execute this command. If one wishes to perform it on
> every node selection, then it would be trivial to add it as a plugin so
> that the Leo's core dealing with selecting nodes, remains free of this
> feature.
>
> The benefit of having this command executed is a rather rare thing. One
> must:
>
>1. write Python code
>2. write a lengthy line of code that could be split by this command
>
> How many times one can have these conditions met? Against how many node
> selections where these conditions are not fulfilled? I believe the ratio is
> negligibly small.
>
> Vitalije
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/ec0a3148-9636-4977-b134-aa75ca421913%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46TcSzopm6M3PurA8XeM%2BA%3DGuw-%3DB7rC%2BJ%2B-ekOgeNqa-w%40mail.gmail.com.

Re: Leo and black

[Terry Brown]

I've been using black for quite a while.  I agree it's probably not
fast enough to continuously reformat a file as you type, but that would
probably be annoying.  I just have a "run black on file" shortcut

noremap l mtgg!Gblack -S -q -l 79 -`t

that binds \l to run black, including setting a mark (t) and jumping
back to it when done.

Python mode in vim runs 2-3 checkers on save, one of which reports
PEP-8 violations, so I run it when I see that, or when I've typed
something in a lazy mess and want it cleaned up.

Cheers -Terry

On Sun, 28 Jul 2019 14:03:36 -0700 (PDT)
"Edward K. Ream"  wrote:

> The black python formatter is worthy of 
> serious consideration.  Its best feature is line wrapping 
> , moderated by a 
> maximum line length setting (code setting in the API and/or
> command-line arg).
> 
> The "black" branch
>  contains
> experimental code to reformat @file nodes using black.  At present,
> the code only reports the diffs that would be produced if the code
> were actually changed.
> 
> After playing with black for awhile (with various values of the line
> length setting),  my reactions were:
> 
> 1. This is pretty much how I break lines myself.
> 2. Why didn't anybody think about doing this before?
> 3. Leo's beautify commands should do something similar.
> 
> 
> *Problems with black*
> 
> Leo's beautify commands are token oriented.  In contrast, black's
> code is based on parse trees.  Parse trees would seem like the
> industrial-strength way. Alas, black looks considerably times slower
> than Leo's beautify commands.  Speed matters a lot if one is
> intending to "blacken" code on the fly.  Otoh, I may be
> misunderstanding the underlying speed of black.
> 
> One of my speed experiments was to blacken an entire file at once.
> This sidesteps problems with using Leonine syntax (@doc parts,
> section references, Leo directives) on a node-by-node basis.  Alas,
> this experiment failed because *black thinks Leo's sentinel comments
> should have a space between the '#" and the '@'*. Yes, I could
> monkey-patch black's comment check to work around this, but it would
> be very ugly, and would probably difficult to do accurately in all
> situations.
> 
> *Improving Leo's beautify commands*
> 
> An alternative to using black itself would be to improve Leo's
> existing beautify commands so they follow black's line-breaking
> strategy.  I believe this would be relatively straightforward.  This
> would be a major departure for Leo's beautify commands.  At present,
> these commands never insert or delete newlines. Still I plan to
> experiment with allowing the beautify commands to insert or delete
> newlines.
> 
> *Summary*
> 
> Black's line breaking algorithm is good enough to justify black's
> basic premise:
> 
> [When using black], you agree to cede control over minutiae of 
> hand-formatting.
> In return, *Black* gives you speed, determinism, and freedom from 
> [pep8-based] nagging about formatting.
> You will save time and mental energy for more important matters.
> 
> Because of the problems with black discussed above, I'll look into
> adding black's line-breaking algorithm to Leo's beautify commands.
> The ultimate goal would be to adjust all lines as we type.
> 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190728171458.0eaaf106%40lakeview.

Re: Encrypt/decrypt node's content with master password

[Terry Brown]

Can't comment on it status working wise, but the sticky nodes plugin has an
encrypted sticky note option.

It's only available if it finds the right library, and only encrypts one
node at a time.  I think it's reasonably secure, it uses AES encryption and
puts the base64 encoded result in the Leo node, displaying the decrypted
text in a temporary popup editor so there shouldn't be any chance of it
being written to file.  No comment on in memory attacks though.

Cheers -Terry

On Fri, Jul 26, 2019 at 8:18 AM Chris George  wrote:

> The stickynotes plugin might do what you want.
>
> HTH,
>
> Chris
>
> On Fri, Jul 26, 2019 at 2:04 AM gar  wrote:
>
>> Leo penetrates to more aspects of my life/
>> Today I started to use Leo for storing private info.
>> It's very bad, since data is stored as a plain text and furthermore -
>> under VCS
>>
>> So now I need a plugin which encrypts/decrypts the whole node content
>> with master password and stores hashed data in .leo file.
>> Since as I learnt before almost every my insane idea is already
>> implemented - I am asking: did anyone already developed such a function?
>> If so - please, share it for me.
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/leo-editor/af7911c0-ffb5-42be-be75-1c955d665de1%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CADWQas0LPWc%2B8o7Vh8fJdWAU2hwDj4%2BOLgwPf8mQTHMiph_UJA%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46SB%2BeK2oQPMnVCHgEd2j2WDFR2%2B2iZu-jHu3jXmqbVGRA%40mail.gmail.com.

Re: Completion madness

[Terry Brown]

On Fri, Jun 21, 2019 at 12:34 PM Edward K. Ream  wrote:

> Still it's *crucial* to make haste slowly by creating issues for
> *everything* that needs attention.  Some mornings I spend hours making
> notes in Leo, then making issues or posts from those notes.  Today was one
> of those days.
>
>
 So naturally what you need is to spend time fiddling with a new tool...

https://github.com/github/hub

A command line tool that can be used for creating issues on GitHub

hub issue create -a tbnorth -l "blocker,infrastructure" -m "Don't
forget to do blah blah"


 would create an issue on GitHub for the repo. the command line's cd'ed to.

So you could automate issue creation from leo nodes.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46RhSQyBT8F1LCFV_Qj77OhW6g5SNmTfatfJ384y_N7vDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Leo 6.0 requires Python 3.6 or later

[Terry Brown]

On Thu, 20 Jun 2019 13:26:53 -0700 (PDT)
Rob  wrote:

> Needs to be on the same line. However, I get this error:

I just tested it and it worked for me using two lines.

Here's my exact leo.bat:



call c:\Users\TBrown02\local\mc2\Scripts\activate.bat 
c:\Users\TBrown02\local\mc2\envs\leo

python c:\Users\TBrown02\Desktop\leo-editor-devel\launchLeo.py




In the above c:\Users\TBrown02\local\mc2 is equivalent to your
C:\Users\rob_iawac46\.conda

Cheers -Terry
 
> D:\Utility Apps\Leo Resources>echo off
> activate does not accept more than one argument:
> ['C:\\Users\\rob_iawac46\\.conda\\envs\\leo', 'python',
> 'D:\\Synced\\github repos\\leo\\launchLeo.py']
> 
> Looks like I can't pass the script file as an argument to the python 
> command, which is itself an argument.
> 
> Rob...
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190620154917.32e0a263%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Leo 6.0 requires Python 3.6 or later

[Terry Brown]

On Thu, 20 Jun 2019 12:19:10 -0700 (PDT)
Rob  wrote:

> Doesn't work, perhaps I'm not understanding something.
> 
>1. I created an Anaconda environment (leo) which includes Python
> 3.7 and PyQt (among other things).
>2. I created the following batch file (paths match my file paths).
> 
> echo off
> 
> CALL  C:\ProgramData\Anaconda3\Scripts\activate.bat 
> C:\Users\rob_iawac46\.conda\envs\leo python "D:\Synced\github 
> repos\leo\launchLeo.py"

CALL C:\ProgramData\Anaconda3\Scripts\activate.bat 
C:\Users\rob_iawac46\.conda\envs\leo

python "D:\Synced\github repos\leo\launchLeo.py"

the way the web page I linked to was formatted made it hard to tell
whether there was a line-break there or not, but I think there should
be.

If that doesn't work open a regular cmd shell window, cd to the folder
where the above batch file is, and run the batch file by typing its
name, hopefully that will preserve any useful feedback.

Cheers -Terry

> echo on
> 
> I even tried with echo on to see if I could see what was going on. No
> luck. Also tried the string after python w/o the double-quotes;
> doesn't work either.
> 
> Rob...
> 
> On Thursday, June 20, 2019 at 2:01:52 PM UTC-4, Terry Brown wrote:
> >
> > Looks like you'd need something along these lines:  
> > https://stackoverflow.com/questions/42602024/windows-shortcut-to-run-python-script-in-anaconda-command-prompt
> >
> > replacing "jupyter lab" with "python c:\some\path\to\launchLeo.py".
> >
> > Not knowing your skill set let me know if more detail woudl be
> > helpful :)
> >
> > Cheers -Terry
> >
> >
> > On Thu, Jun 20, 2019 at 12:34 PM Rob  > > wrote:
> > >
> > > Thanks, Terry. I was able to launch Leo from an Anaconda shell.
> > > How do I 
> > translate that to a Windows shortcut like I had before?
> > >
> > > Rob...
> > >
> > > On Thursday, June 20, 2019 at 1:22:19 PM UTC-4, Terry Brown wrote:
> > >>
> > >> I think activating an Anaconda environment requires more steps.  
> > Easiest way for testing is to launch the Anaconda shell from the
> > start menu.
> > >>
> > >> If your ultimate goal is launching from an icon there are more
> > >> steps, 
> > but initial testing the shell's the way to go.
> > >>
> > >> Cheers -Terry
> > >>
> > >>
> > >> On Thu, Jun 20, 2019 at 12:04 PM Rob  wrote:
> > >>>
> > >>> PS D:\Synced\github repos\leo>
> > >>> c:\ProgramData\Anaconda3\python.exe 
> > launchLeo.py
> > >>> Traceback (most recent call last):
> > >>>   File "launchLeo.py", line 7, in 
> > >>> import leo.core.runLeo
> > >>>   File "D:\Synced\github repos\leo\leo\core\runLeo.py", line
> > >>> 27, in 
> > 
> > >>> import leo.core.leoApp as leoApp
> > >>>   File "D:\Synced\github repos\leo\leo\core\leoApp.py", line
> > >>> 22, in 
> > 
> > >>> import sqlite3
> > >>>   File "C:\ProgramData\Anaconda3\lib\sqlite3\__init__.py", line
> > >>> 23, in 
> > 
> > >>> from sqlite3.dbapi2 import *
> > >>>   File "C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py", line
> > >>> 27, in 
> > 
> > >>> from _sqlite3 import *
> > >>> ImportError: DLL load failed: The specified module could not be
> > >>> found.
> > >>>
> > >>> I verified that the last file mentioned: 
> > "C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py" exists. What does
> > 'DLL load failed...' mean?
> > >>>
> > >>> Rob...
> > >>>
> > >>> On Thursday, June 20, 2019 at 12:08:36 PM UTC-4, Edward K. Ream
> > >>> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Jun 20, 2019 at 10:58 AM Rob  wrote:
> > >>>>>
> > >>>>> Now I can't run Leo at all.
> > >>>>
> > >>>>  
> > >>>>>
> > >>>>> Any ideas on what to try next?
> > >>>>
> > >>>>
> > >>>> Open a console first.  Then run python from the console.  That
> > >>>> way 
> > the console will remain open and you can see what went wrong.
> > >>>>
> > >>>> Edward
>

Re: Leo 6.0 requires Python 3.6 or later

[Terry Brown]

Looks like you'd need something along these lines:
https://stackoverflow.com/questions/42602024/windows-shortcut-to-run-python-script-in-anaconda-command-prompt

replacing "jupyter lab" with "python c:\some\path\to\launchLeo.py".

Not knowing your skill set let me know if more detail woudl be helpful :)

Cheers -Terry


On Thu, Jun 20, 2019 at 12:34 PM Rob  wrote:
>
> Thanks, Terry. I was able to launch Leo from an Anaconda shell. How do I
translate that to a Windows shortcut like I had before?
>
> Rob...
>
> On Thursday, June 20, 2019 at 1:22:19 PM UTC-4, Terry Brown wrote:
>>
>> I think activating an Anaconda environment requires more steps.  Easiest
way for testing is to launch the Anaconda shell from the start menu.
>>
>> If your ultimate goal is launching from an icon there are more steps,
but initial testing the shell's the way to go.
>>
>> Cheers -Terry
>>
>>
>> On Thu, Jun 20, 2019 at 12:04 PM Rob  wrote:
>>>
>>> PS D:\Synced\github repos\leo> c:\ProgramData\Anaconda3\python.exe
launchLeo.py
>>> Traceback (most recent call last):
>>>   File "launchLeo.py", line 7, in 
>>> import leo.core.runLeo
>>>   File "D:\Synced\github repos\leo\leo\core\runLeo.py", line 27, in

>>> import leo.core.leoApp as leoApp
>>>   File "D:\Synced\github repos\leo\leo\core\leoApp.py", line 22, in

>>> import sqlite3
>>>   File "C:\ProgramData\Anaconda3\lib\sqlite3\__init__.py", line 23, in

>>> from sqlite3.dbapi2 import *
>>>   File "C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py", line 27, in

>>> from _sqlite3 import *
>>> ImportError: DLL load failed: The specified module could not be found.
>>>
>>> I verified that the last file mentioned:
"C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py" exists. What does 'DLL
load failed...' mean?
>>>
>>> Rob...
>>>
>>> On Thursday, June 20, 2019 at 12:08:36 PM UTC-4, Edward K. Ream wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Jun 20, 2019 at 10:58 AM Rob  wrote:
>>>>>
>>>>> Now I can't run Leo at all.
>>>>
>>>>
>>>>>
>>>>> Any ideas on what to try next?
>>>>
>>>>
>>>> Open a console first.  Then run python from the console.  That way the
console will remain open and you can see what went wrong.
>>>>
>>>> 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-e...@googlegroups.com.
>>> To post to this group, send email to leo-e...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/leo-editor.
>>> To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/b556f104-7c41-4b5a-b8fb-c18070ba0697%40googlegroups.com
.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/0d5b19b5-6818-45f2-b31c-c9acc731a35c%40googlegroups.com
.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46ScXnYB3rz2KsjHBG5FPcCVNMTGGEVwAHiEozgY4TF%2BoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Leo 6.0 requires Python 3.6 or later

[Terry Brown]

I think activating an Anaconda environment requires more steps.  Easiest
way for testing is to launch the Anaconda shell from the start menu.

If your ultimate goal is launching from an icon there are more steps, but
initial testing the shell's the way to go.

Cheers -Terry


On Thu, Jun 20, 2019 at 12:04 PM Rob  wrote:

> PS D:\Synced\github repos\leo> c:\ProgramData\Anaconda3\python.exe
> launchLeo.py
> Traceback (most recent call last):
>   File "launchLeo.py", line 7, in 
> import leo.core.runLeo
>   File "D:\Synced\github repos\leo\leo\core\runLeo.py", line 27, in
> 
> import leo.core.leoApp as leoApp
>   File "D:\Synced\github repos\leo\leo\core\leoApp.py", line 22, in
> 
> import sqlite3
>   File "C:\ProgramData\Anaconda3\lib\sqlite3\__init__.py", line 23, in
> 
> from sqlite3.dbapi2 import *
>   File "C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py", line 27, in
> 
> from _sqlite3 import *
> ImportError: DLL load failed: The specified module could not be found.
>
> I verified that the last file mentioned: 
> "C:\ProgramData\Anaconda3\lib\sqlite3\dbapi2.py"
> exists. What does 'DLL load failed...' mean?
>
> Rob...
>
> On Thursday, June 20, 2019 at 12:08:36 PM UTC-4, Edward K. Ream wrote:
>>
>>
>>
>> On Thu, Jun 20, 2019 at 10:58 AM Rob  wrote:
>>
>>> Now I can't run Leo at all.
>>>
>>
>>
>>> Any ideas on what to try next?
>>>
>>
>> Open a console first.  Then run python from the console.  That way the
>> console will remain open and you can see what went wrong.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/b556f104-7c41-4b5a-b8fb-c18070ba0697%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46RncXxVpZ4_ehEUk88WYwQMsgwqVSz8rWdzxf1d1n-Y2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use the bridge, Luke

[Terry Brown]

On Wed, 19 Jun 2019 00:52:54 -0500
"Edward K. Ream"  wrote:

> On Tue, Jun 18, 2019 at 6:27 PM Terry Brown 
> wrote:
> 
> Then I'm not sure that there's really anything to do.   Python's
> > well integrated into vim, so you can just use leoBridge as usual.
> 
> 
> Cool.
> 
> > I guess I can do something to verify that, but I can't see why it
> > wouldn't work.
> >
> 
> Please do.  That would be helpful.

Ok, this script appends the outline headlines, indented, to the current
vim buffer:

import leo.core.leoBridge as leoBridge
import vim

controller = leoBridge.controller(
gui='nullGui',
loadPlugins=True,  # True: attempt to load plugins.
readSettings=True,  # True: read standard settings files.
silent=True,  # True: don't print signon messages.
verbose=False,  # True: print informational messages.
)

g = controller.globals()
c = controller.openLeoFile("/home/tbrown/.leo/del.leo")


def dent(node, result, level=0):
result.append('  ' * level + node.h)
for child in node.children:
dent(child, result, level + 1)
return result


result = []
dent(c.hiddenRootNode, result)

vim.current.buffer[-1:] = result


It can be invoked with

:py import leodent

assuming it's in a file leodent.py and on the Python path.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190619073845.72437544%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Use the bridge, Luke

[Terry Brown]

On Tue, 18 Jun 2019 17:20:37 -0500
"Edward K. Ream"  wrote:

> On Tue, Jun 18, 2019 at 2:22 PM Terry Brown 
> wrote:
> 
> > > Thanks. I didn't know that. In that case the entire vim plugin
> > > would be based on this
> > > <http://leoeditor.com/leoBridge.html#the-basics>. Care to give it
> > > a go?
> >
> > Not without much more specific objectives ;-)
> 
> The objective is simply to be able to access Leo outline from either
> python or vim script.  In python, all that is needed is access to c
> and g.  From c, we get c.p and all the generators.

Then I'm not sure that there's really anything to do.   Python's
well integrated into vim, so you can just use leoBridge as usual.  I
assume - I guess I can do something to verify that, but I can't see why
it wouldn't work.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190618182730.0cbb2997%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Use the bridge, Luke

[Terry Brown]

On Tue, 18 Jun 2019 11:31:30 -0700 (PDT)
"Edward K. Ream"  wrote:

> 
> 
> On Tuesday, June 18, 2019 at 12:38:51 PM UTC-5, Terry Brown wrote:
> >
> > A lot of vim plugins are written in Python, so perhaps you could
> > use that instead of vimscript.
> >
> 
> Thanks. I didn't know that. In that case the entire vim plugin would
> be based on this <http://leoeditor.com/leoBridge.html#the-basics>.
> Care to give it a go?

Not without much more specific objectives ;-)

vim doesn't always come with Python support installed, but I'm guessing
more often than not.  Also it's not hard to compile vim from scratch,
so in cases where Python's missing, it's probably not hard to add.

Given that, I don't think any RPC / client-server vimscript <->
leo_bridge_server.py plumbing would be worth the effort, just write the
vim part in Python, and therefore just use leoBridge as usual.

So then what?  vim can use a Leo file as a data structure, but how does
it navigate the Leo file?  vim's https://github.com/scrooloose/nerdtree
and https://github.com/majutsushi/tagbar#screenshots plugins both
implement tree navigation, but I haven't looked at either enough to
know if they can be re-purposed.  I feel that this looks like possibly
low hanging fruit, but would turn into a bigger project.  And there are
other options for editing Leo files.  Leo, for example ;-)

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190618142228.0e42abb0%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Use the bridge, Luke

[Terry Brown]

A lot of vim plugins are written in Python, so perhaps you could use that
instead of vimscript.

Cheers -Terry

On Tue, Jun 18, 2019 at 12:07 PM Edward K. Ream  wrote:

> Integrating pyzo into Leo fails because pyzo's shell can't control Leo's
> gui.  However, such scripts *could *access the data in Leo outlines using 
> Leo's
> bridge .  That is, Leo's bridge
> supports *restricted Leonine scripts*.  This in no way tempts me to embed
> pyzo's shell, debugger, etc. into Leo ;-)
>
> It is easy to start Leo's bridge from pyzo, or IPython, or any other
> python environment. It's an alternative to leo --ipython, for example.
>
> I have just created #1213
> : support Leo's
> bridge in vim.  This would be a separate from Leo's vim.py plugin, and
> might have advantages for some vim users. It would be written in vim
> script . Anyone interested in this
> project? I'll be glad to answer any questions you may have.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/2a72fe65-4817-40fa-b48a-32902dfce416%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46RGnJR7qO%2BF0uwtyAWo8n2URR5d_n5s5xphyp0qYGR8ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bookmarks plugin for docks

[Terry Brown]

Bookmarks isn't particularly entangled in the old UI, I had it working in
my attempt at a docks based UI.

I don't really see it as different from the other plugins listed in #1154
, it has state
persistence, but I don't think that's a GUI tied issue.

That said, the old GUI worked by letting plugins register as things that
could provide a widget for the GUI to manage.  It also handled persistence
in that process.  In that context bookmarks.py would work equally well in a
new GUI that registers a list of things that can provide widgets to manage.
If the new model is for each plugin to understand the GUI and manage itself
within it, then there might be more work to be done.

Cheers -Terry


On Wed, Jun 12, 2019 at 11:06 AM Edward K. Ream  wrote:

>
>
> On Wed, Jun 12, 2019 at 8:31 AM lewis  wrote:
>
> I have found Leo's Bookmarks plugin a very useful tool. With the
>> introduction of docks it is no longer available unless you use the
>> --no-dock option, but then you lose dock features.
>> Is there any prospect of there being a compatible plugin enabling a
>> Bookmark panel to be inserted or merged into a dock?
>>
>
> bookmarks.py is a hard case. It's entangled with the old gui. It would
> need a rethink/rewrite for docks.
>
> The plugins listed in #1154
> should port to
> using docks without much fuss.  I'll likely to that before 6.0b1.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CAMF8tS3NK-gM3KqV-ZBN4XvLRcBNhrw_-oRnqvhrJvOJhD4anw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46Q%2B8YvxRYQ%3DMkFdJr7aXaxVTOauQ2PJCuwM9RBh1MOcqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: No python 2 work after December 1, 2019

[Terry Brown]

Not sure about that, my
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"
is running 2.7 by default, and I'm sure I did a fresh install, not an
upgrade.  99.5% sure anyway ;-)

But I do think Python 3 is *installed* by default on 18.04.  3.6.7
currently.

Cheers -Terry

On Wed, Jun 5, 2019 at 9:36 AM Josef  wrote:

> Correction:
>
> as far as I heard, Python 3 is already the default on the currrent Ubuntu
> 18.04 LTS. I was under the wrong assumption that Python 2 is the default,
> because when I upgraded from 16.04 LTS to 18.04 LTS the default Python
> installation did not change from 2 to 3.
>
> Sorry, if I caused any confusion.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/b2f938c9-6d81-4674-aae6-71c1a7182dc8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46Q_oWJCqx3N7qxtN88-Jsg5SYkK8EJscDFMU2%2Bv-p%2BVTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of docking code

[Terry Brown]

On Tue, 28 May 2019 14:52:58 -0500
"Edward K. Ream"  wrote:

> The drawback is that Leo's main window must contain all the docks.
> Leo has always had this constraint, 


Not really, NestedSplitter has an open window function that allows any
pane to be moved to another window.


> but it does make using multiple
> monitors less enticing ;-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190528150012.57daf2dc%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Persistent persistence...

[Terry Brown]

Just a couple of dock related thoughts.

To replace the functionality of the NestedSplitter interface the dock
layout needs to support multiple (named) persistent layouts of plugin
docks (widgets in docks, really, plugins don't need to know about
docks specifically).  I used this to make Leo into things like a DB
schema editor and a graph editor and a todo / calendar manager.

I had this kind of persistence mostly working in my attempt at docks,
if that's a useful reference.  Basically plugins register as widget
providers and the layout machinery works down the list of providers
asking who can provide "X" when it's restoring a layout.

I assume you're allowing all docks to be tabbed docks?  So essentially
every "pane" becomes (optionally) a "tab-pane".  This lets you have a
lot of widgets "on-hand" without consuming lots of screen space.

Also I'm not sure if you still have a central widget, but the that a
central widget can't be dragged into a different dock relationship or
receive incoming dragged docks(*) seems like it would be an
unnecessarily confusing asymmetry.

* I guess it could receive them for left/right/above/below, but not as
a tab sibling, so still confusing.

General thoughts but mainly just a reminder that NestedSplitter
persists plugin widget layouts.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190528093752.0a9ed70a%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Please read and discuss: Always use docks?

[Terry Brown]

On Fri, May 24, 2019 at 12:45 PM Edward K. Ream  wrote:

> On Fri, May 24, 2019 at 11:18 AM Terry Brown 
> wrote:
>
> > - A central widget allows the user to drag dock widgets to any area at
>> any time.  Without a central widget you can only drag a widget to an area
>> that already contains a dock.  Once an area becomes empty it can't be used!
>>
>> but I never found using only one area to be a constraint - all possible
>> arrangements were still possible.  My approach explicitly used only one
>> area, and you can't pull the last dock out of a nest of docks, so there was
>> never an empty window issue.
>>
>
> Chris George already as indicated that he wants to undock/float all his
> widgets. My experiments show that having a central widget will reduce
> significant confusion.
>

I spent a lot of time on this, so I'm fairly confident a central widget is
not needed and not helpful.  For Chris, you start with three docked
widgets, in the same dock area, mimicking the vanilla Leo layout.  Just
drag two of them out, separately, and you have all your widgets undocked (3
top level windows).  You can drag any one of them back into a docked
relationship with any other.  If one of them was a central widget, you
wouldn't be able to freely re-dock between arbitrary pairs of windows, and
it would be really confusing.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAFPg46R12xh%3D4y4ywDxuQO-z468MRhV%2BdpP7ZLgq%2BEujFucNHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please read and discuss: Always use docks?

[Terry Brown]

I think a having a docking interface and the NestedSplitter (Easter-egg
splitter right click) interface is kind of redundant, they both do similar
things with similar goals and having them co-exist long term probably
doesn't make sense.

Vocab: Leo's log-pane is so called for historical reasons, it's a tab-pane
containing log, spell, find, and other widgets, so I'll call it the
tab-pane.

The NestedSplitter interface lets you freely arrange all widgets (body,
tree, log, spell, find, todo, quick-nav, graph, tags, anything else put in
the tab-pane).

Until the dock interface lets you do that, you'd lose functionality
removing NestedSplitter.  Allowing free arrangement of all widgets with
docks is what I attempted to do, dock interface wise, but gave up.

Basically I think the dock ui needs to let you arrange all widgets, not
just the big three (tree / body / tab-pane).  Currently I think what it's
added over the NestedSplitter interface is more intuitive arrangement
(mouse dragging! ;-) and different aesthetics. On aesthetics, if it doesn't
already have one, the dock ui probably needs a toggle for display of the
dock titles, seeing long term labeling the tree the tree etc. is a waste of
screen space.

You said

> - A central widget allows the user to drag dock widgets to any area at
any time.  Without a central widget you can only drag a widget to an area
that already contains a dock.  Once an area becomes empty it can't be used!

but I never found using only one area to be a constraint - all possible
arrangements were still possible.  My approach explicitly used only one
area, and you can't pull the last dock out of a nest of docks, so there was
never an empty window issue.

Hopefully this new approach (using docking for just the big-three widgets
initially) will allow an incremental implementation of a full dock UI,
maybe first adding support for todo / graph / tags / quick-nav / back-links
etc. etc., then finally breaking the log, spell and find widgets out of the
tab-pane, which was the can of worms I ran away from.

Cheers -Terry



On Fri, May 24, 2019 at 10:10 AM Edward K. Ream  wrote:

> Yesterday Leo's new docking interface saw first light.  It's in the "dock"
> branch. You can take a look by setting --dock in the command line. I am
> eating my own dog food without serious problems.  There are two bugs that
> must be fixed.
>
> This post discusses whether Leo's legacy gui (look and feel) has any
> long-term future. This is a thinking out loud post, and I definitely want
> your opinions.
>
> *Important*: I have no plans to do anything drastic any time soon.  I may
> replace --dock by --no-dock, to make docking the default, but Leo's legacy
> gui will continue work* exactly* as before for quite a while.  If I do
> retire Leo's legacy gui, it will likely be done in Leo 6.1, not 6.0, unless
> we all, unanimously, fall in love with docks.
>
> *Important*: it will be much easier to follow along if you actually play
> with the new gui before reading on.
>
> *The new gui*
>
> The Outline dock is the central widget
> .  The outline dock
> can't be deleted, moved or floated, which is no real restriction at all.
> See below. The Log dock resides in the left dock area; the Body dock
> resides in the bottom dock area. This means that the Body dock gets the
> full width of the main window.
>
> *Important:* The user can change the default placement of the Log and
> Body docs (in relation to the Outline doc) by dragging the docks.  Leo will
> save and restore any changes, so the defaults above don't really matter.
> (Saving/restoring doesn't work perfect at present.  That's one of the bugs
> that must be fixed.)
>
> I am in the midst of re-doing the add-editor command.  It will likely use
> Qt's splitDockWidget
> method to do the
> gui work.  This promises to be a big visual improvement over Leo's legacy
> add-editor command.
>
> *The central widget*
>
> Qt does not *require* a central that main windows have a central widget,
> despite what obsolete docs may say.  However, there are two big advantages
> to having a central widget:
>
> - It's not possible to have an empty Leo main window, as in the last
> screen shot in Chris George's recent post
> .
>
> - A central widget allows the user to drag dock widgets to any area at any
> time.  Without a central widget you can only drag a widget to an area that
> already contains a dock.  Once an area becomes empty it can't be used!
>
> At present I am leaning towards making central widget be a dock widget
> that can't be moved, floated or deleted.  This makes the central widget
> look like a dock (with the Outline label).  I think this visual uniformity
> is good, but it does obscure the fact that the Outline is a central
> widget.  I'll be experimenting further with this.
>
> *Bugs*
>
> Two bugs 

Re: Proposal: use QDockWidget for Leo's main window

[Terry Brown]

On Sun, 19 May 2019 08:23:58 -0700 (PDT)
"Edward K. Ream"  wrote:

> This post discusses #1150 
> .  Don't
> panic. Nothing is settled yet, and I'll consider your comments
> seriously.
> 
> Using Qt's Dock widget *might* improve Leo substantially.  It would 
> certainly making integrating Leo and pyzo easier, but that's a
> secondary concern.  The proposal must stand on its own merits.
> 
> *Background*
> 
> Using a Dock might seem a no-brainer.  Qt docks allow users freedom
> to position, move and resize *dockable *widgets. Even better, Qt can 
> automagically save and restore user changes!

To layout, not the state of the widget in the dock.

> Alas, QDock's require a so-called *central widget*.  This
> significantly restricts the design choices.  Everything must be
> placed *around* the central widget: above, below, left or right of it.

When I was trying to do this it seems sufficient to just use the left
side dock for everything, and have no main widget.  That gives you
complete freedom of layout and no "more equal than others" widget.

Cheers -Terry

> Pyzo is a good example of Qt's dock.  Please play around with it to
> get a feel for how it works. In pyzo, the central widget holds a
> tabbed widget containing all the user's files (pyzo editors).
> 
> *The proposal*
> 
> The obvious thing to do would be to put Leo's *entire* main window
> into the central widget. This would work, but I think there is a
> better way:
> 
> *Remove Leo's Tab Pane from the main window*
> 
> I think this makes sense! The benefits:
> 
> - More freedom to arrange and size components of the Tab Pane.
> - Greater width for the tree pane, when the tree appears above the
> body pane.
> - One less splitter in the main window.
> 
> In addition to the benefits of using a top-level QDockWidget
> mentioned above, Leo will need neither the Easter Egg interface nor
> the nested splitter machinery. Plugins will simply create dockable
> widgets.  I am prepared to do the retro-fitting.
> 
> I don't see any major drawbacks. Without *additional* changes,
> multiple body panes will work just as before. However, we could
> imagine additional body panes placed as *dockable* widgets outside
> the main window.  This seems like another advantage of the proposal.
> 
> BTW, Leo will likely still support the toggle-split direction
> command.  Its effect will be simpler.
> 
> *Summary*
> 
> Imo, it makes sense to remove Leo's Log Pane from Leo's main window
> when using a top-level QDockWidget.  I see no significant drawbacks
> to doing so.  It will require significant behind-the scenes work,
> which will be my responsibility. 
> 
> These are early days for this proposal.  Please let me know what you
> think.
> 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190519102911.6866190e%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Freemind Import command?

[Terry Brown]

On Thu, 16 May 2019 17:23:50 -0500
"Edward K. Ream"  wrote:

> On Thu, May 16, 2019 at 4:29 PM Seth Johnson
>  wrote:
> 
> > The other imports in the File->Import Files menu give me a file
> > selection window, but it appears the menu item for Freemind lacks a
> > command/function call.
> >
> 
> This command requires lxml .  Try
> installing it.  This importer appears to be the only code in Leo that
> uses lxml.  Have no idea why, or where the code came from.

Heh - I may have written it when I switched from Freemind to Leo :)

At the time lxml had better support for XPath than core Python libs,
not sure if that's still true.  Recent work makes me still prefer XPath
over DOM traversal, so if lxml is still the leader XPath wise I'd still
lean towards it - I know it's actively maintained.

Cheers -Terry

> Anyone want to convert the code to use xml.etree.ElementTree?
> 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190516222012.48ccac3a%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: discuss: Use markdown for Leo's documentation #1147

[Terry Brown]

On Tue, 14 May 2019 20:26:47 -0700 (PDT)
Matt Wilkie  wrote:

> 
> >
> > What I like about AsciiDoc is the code snippets support and the way
> > it declares tables. But Pandoc can read ASCIIDoc [...]
> >
> 
> (?) This seems to be in the air or incomplete according to 
> https://github.com/jgm/pandoc/issues/1456. (From the ycombinator
> thread, which by the way also highlights another consideration:
> Asciidoc readability of nested lists in plain text is somewhat
> compromised relative to Markdown.)

The R software community and in particular the ~commercial RStudio
front end are I think helping to drive the markdown -> pandoc pipeline,
so it might be more mature / maintained than some other input formats
for pandoc.  Not really sure, seeing I haven't really used any other
input formats.

> I have generally high opinion of pandoc. It has saved me many hours
> of frustration more than once. 
> 
> It's hard to install automatically on Windows (it's not just `pip
> install pandoc`, last time I checked), but easier than AsciiDoctor
> which is in Ruby.

Sometimes I find conda, anaconda's package manager, usually installed
via miniconda, works where pip doesn't, and visa versa.  I think I've
been able to install pandoc in Windows with conda, although I've been
using Windows less, again, recently.

Cheers -Terry

> --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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190515071451.7f354f51%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: discuss: Use markdown for Leo's documentation #1147

[Terry Brown]

On Tue, 14 May 2019 16:07:15 -0500
Kent Tenney  wrote:

> I don't use a lot of rst capability, but really depend on
> .. contents::
> 
> to generate links to sections in a document
> anyone found a way to do that in Markdown?

I think pandoc will generate tocs from markdown, I know it will if the
target's PDF, but presumably other targets too.

But pandoc uses lots of extensions.

Cheers -Terry

> Thanks,
> Kent
> 
> On Tue, May 14, 2019 at 3:12 PM Matt Wilkie  wrote:
> 
> > Hi Terry! thanks for chiming in
> >
> > The problem is that markdown's what everyone uses / expects.  So the
> >> downside to anything that's not markdown is that people won't know
> >> it, whereas they would know markdown.
> >>
> >
> > A salve for this is Markdown compatibility, via AsciiDoctor, though
> > it remains to be tested how much of the itch that would absolve.
> >
> > https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#markdown-compatibility
> >
> > --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.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/leo-editor/3e92270d-237c-43bf-9ce0-a6df1366bf89%40googlegroups.com
> > 
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190514163749.046bcee8%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: discuss: Use markdown for Leo's documentation #1147

[Terry Brown]

On Tue, 14 May 2019 03:50:46 -0700 (PDT)
"Edward K. Ream"  wrote:

> Anyone think AsciiDoctor is a bad idea?

I think it's easy to argue that there are better (more expressive /
extensible) text dialects than markdown.  restructuredText is an obvious
example.

The problem is that markdown's what everyone uses / expects.  So the
downside to anything that's not markdown is that people won't know it,
whereas they would know markdown.

Pandoc markdown has enough extensions to allow research papers to be
written in it (tables, figures, captions, citations, cross references
etc.) but it's more a collection of plugins adopting assorted
variations than a coherent whole.

I wish restructuredText or something like it had won the text markup
war and not markdown, but it didn't.

I haven't used asciiDoc but I've heard of it often enough to think it's
a persistent ecosystem, it's just a matter of balancing functionality
with familiarity across possible contributors.

Cheers -Terry

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20190514084648.65712dd5%40lakeview.
For more options, visit https://groups.google.com/d/optout.

Re: Ahas: the way forward

[Terry Brown]

On Tue, 9 Apr 2019 08:57:03 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Tuesday, April 9, 2019 at 8:28:22 AM UTC-5, Edward K. Ream wrote:
> 
> > Neither Leo's code base nor Leo's ecosystem will change in any 
> incompatible way.
> 
> I plan to experiment with using a QDockWidget at Leo's top level.  As 
> mentioned recently, the QDockWidget is not as flexible as I would
> like. One trick might be to use a tiny/invisible central widget, with
> the goal of allowing more flexible placements of *all* widgets.  An
> easy, standalone, prototype will soon show whether this has any
> chance of working.
> 
> Using QDockWidget in any way *might* require changes to plugins that
> put widgets in Leo's Log pane. I'll consider making such widgets
> dockable, provided of course that Leo does, in fact, ever use
> QDockWidget.

I had done, meh, 72% of this work in the qdock-layout branch, not to be
confused with the qt_docks branch, an earlier attempt that didn't get
as far.

It's not that hard if you ignore Kent, who will want persistence of
multiple named layouts.  Unfortunately he's right, having to rearrange
your workspace every time you start is unacceptable, and persistence
makes it much harder.

At least you can avoid my earlier mistake of failing to properly
understand QMainWindow.saveState().  I spent a lot of time with
complicated code trying to save and restore the layout myself with
QDockWidget's rather limited API, before realizing the
QMainWindow.saveState() was what I needed.

I never completed the project because of what was, for me, an
insurmountable amount of complexity in initialization with find and
spell tabs in the log pane etc.

Cheers -Terry

-- 
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: Ahas: the way forward

[Terry Brown]

On Tue, 9 Apr 2019 06:28:22 -0700 (PDT)
"Edward K. Ream"  wrote:

> 1. There is no need for Leo's --session-save & --session-restore
> command-line arguments!
> 
> Doh!  Leo can adopt the following strategy:
> 
> - If the command line contains file names, Leo will load only those
> files.
> - When Leo exits, it will always act as if --session-save were given.
> - When Leo starts without file arguments, it will use the
> --session-save data, if those data have ever been saved before.
> - Otherwise, this is the very first time Leo has ever started, in
> which case Leo will load the workbook file.

I'm not familiar with --session-save & --session-restore, but I assume
they support multiple named sessions?  Not sure how the new scheme
manages switching between sessions.

Cheers -Terry

-- 
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: Not-clones that act like clones

[Terry Brown]

On Sat, 9 Mar 2019 10:49:19 -0800 (PST)
vitalije  wrote:

> For HTML and CSS there are a lot of pre-processors for example: pug
> for HTML and sass for css. Both of them have more than one way to
> define some section once and use it anywhere you like it. Basically
> you write source files in pug and sass format, and then compile those
> source files into the final HTML and CSS files. It requires some
> knowledge of new languages like pug and sass, but allows you to write
> much less source code for producing the same HTML and CSS.

There's also the Jinja2 templating system which is written in / uses
Python.  Bit of a learning curve but handy if you already know Python.
Used by the Django web app. stack.  They don't use Jinja2 directly, but
the templating system is almost the identical so if you ever think you
might want to work with Django there's some pay off there.

I wouldn't recommend the leo-cloud plugin, it wasn't designed with
multiple instances in one file in mind.

Cheers -Terry

> Vitalije
> 
> On Saturday, March 9, 2019 at 7:18:39 PM UTC+1, Rob wrote:
> >
> > Thanks for clarifying, Vitalije. Yes, I'm the only one who would
> > edit them and I don't use external editors, so clones would
> > certainly be the easiest way to do that. I use \include{file.tex}
> > for LaTeX documents, but don't know about a similar mechanism for
> > html or css documents. Any of the other suggestions are way too
> > complicated; especially compared to clones.
> >
> >> As long as you are not using any other editor to edit those files
> >> and you are the only one who edits them, it is safe to use
> >> cross-file clones for this kind of problem.

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

Get started with Org mode without Emacs

[Terry Brown]

https://opensource.com/article/19/1/productivity-tool-org-mode?utm_medium

Cheers -Terry

-- 
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: looking for pre-existing text format for defining event dates in Leo

[Terry Brown]

On Wed, 30 Jan 2019 02:20:20 -0800 (PST)
jkn  wrote:

> Hi all
>I would quite like to use Leo to remind me of events - a bit like
> a locally-based version of Google Calendar. So (I guess) I would have
> a special node(s) with a list of events in some form:
> 
> "3rd Friday of each month; pay XXX bill"

For this kind of thing I just recently found
https://dateutil.readthedocs.io/en/stable/rrule.html
after having been looking for such a thing for some time.

Cheers -Terry

> "Aug 31st each year: Aunt Amelia's Birthday"
> "23rd February: one-off concert date"
> 
> and then have a script to tell me eg. "all the events next week", or
> similar
> 
> I'm happy to have fun ;-) working on the script, but I wonder about
> the format for defining the events. I am imagining that there is
> already some markdown-type format for defining events like this, and
> I'd like to use a 'standard' if possible. Can anyone point me at
> prior art for this kind of thing?
> 
> Thanks
> Jon N
> 

-- 
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: Fixing Qt5 problems

[Terry Brown]

On Sun, 6 Jan 2019 14:53:08 -0600
"Edward K. Ream"  wrote:

> In theory, I suppose, setting a style class is more flexible, but
> here we are dealing with a Qt bug, so limiting ourselves to a simple
> workaround is plenty good enough. The only actual change to code was
> in QtStatusLineClass.put_helper.

When I started looking at this I noticed the log pane gets highlighted in 5.7
but not 5.9... maybe too much of a nit to bother with?

Cheers -Terry

-- 
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: Fixing Qt5 problems

[Terry Brown]

On Sun, 6 Jan 2019 09:22:16 -0600
Terry Brown  wrote:

> I can take a quick look if it helps.  I did introduce the use of the
> ~= operator, which makes Qt stylesheets more like their more mature
> cousin, CSS stylesheets.

I see there's already a style branch - I don't want to duplicate effort, let me
know if you want me to address this issue.

I was thinking that as well as setting the .style_class attribute to a space
separated list of classes, the .set_style method could set or remove individual
._style_info, ._style_error etc. attributes on widgets that could be targeted
with `=` instead of `~=`.

Cheers -Terry

-- 
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: Fixing Qt5 problems

[Terry Brown]

On Sun, 6 Jan 2019 04:07:05 -0800 (PST)
"Edward K. Ream"  wrote:

> Older versions of Leo switched colors using code.  It will be
> necessary to do so again. We can't wait for Qt to fix this problem.
 
I don't think using code is essential, although it's an option.

>From #804:

Seeing that bug shows no signs of being fixed, we might have to degrade
to something like

QLineEdit#status1[info="true"]

which would mean code changes too.

So yes of course code will change, but styling can still be managed by the
stylesheet and won't require setting / updating / reloading of any separate
@color info_color = fuchsia kind of thing.

I can take a quick look if it helps.  I did introduce the use of the ~=
operator, which makes Qt stylesheets more like their more mature cousin, CSS
stylesheets.

Cheers -Terry

> 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: edit-pane-csv separator

[Terry Brown]

On Wed, 2 Jan 2019 06:28:15 -0800 (PST)
Josef  wrote:

> Hi Terry,
> 
> sorry it took me a while to get back to you - too much pre-Christmas
> stress.
> 
> Yes, a button to toggle the pane would be fine, I should have thought
> of this. The main issue though is the remembering of the settings,
> since there are many variants of CSV files.

Ok, e74e4e2 lets the CSV edit pane remember per node settings.  It will
work best if you don't move from node to node with the pane open, but
instead open and close the pane on a single node using a button.  Here's
code for the button:


from leo.plugins.editpane.csvedit import LEP_CSVEdit
s = c.free_layout.get_top_splitter()
csv = s.findChild(LEP_CSVEdit)
if csv:
csv.parent().parent().parent().close()
else:
c.k.simulateCommand("edit-pane-csv")


Cheers -Terry

 
> On Sunday, December 2, 2018 at 4:15:45 PM UTC+1, Terry Brown wrote:
> >
> > On Fri, 30 Nov 2018 06:58:59 -0800 (PST) 
> > Josef > wrote: 
> >
> > > Hi Terry, 
> > > 
> > > after using edit-pane-csv for some time now, I have one big wish 
> > > left: it would be great if Leo could remember the settings for
> > > each file, at least for @clean nodes. Ideally the csv pane would
> > > stay open for these nodes. 
> >
> > Would a button that toggled the pane work?  I can't remember if the 
> > code has an easy way to set initial settings, but perhaps per-node 
> > settings could be saved in p.v.u. 
> >
> > Cheers -Terry 
> >
> > > I have many csv files around, which I need to maintain manually
> > > on a regular basis, so it would be nice if Leo could remember the
> > > settings for each of these files, and it would be even better if
> > > I would not have to run the command edit-pane-csv on each file
> > > every time after I closed the associated Leo file. 
> > > 
> > > Cheers - Josef 
> > > 
> > > On Friday, August 10, 2018 at 5:38:37 PM UTC+2, Terry Brown
> > > wrote: 
> > > > 
> > > > On Fri, 10 Aug 2018 08:14:53 -0700 (PDT) 
> > > > Josef > wrote: 
> > > > 
> > > > > Hi Terry 
> > > > > 
> > > > > I tried 
> > > > > 
> > > > > Leo 5.7.4 devel, build 20180807122609 
> > > > > 
> > > > > and it did not work right away with a .latex file. It seems
> > > > > to get confused by the @language latex in the first line. It
> > > > > worked when I removed it. 
> > > > > 
> > > > > It would be nice if it would ignore leo directives. 
> > > > 
> > > > Hmm, it doesn't pay any attention to leo directives, and just 
> > > > defaults to ',' CSV mode.  Not sure what was going on there. 
> > > > 
> > > > > Another quirk is, that every line needs to have the same
> > > > > number of separators, but particularly when editing latex
> > > > > tables by hand one does not always enter all cells if they
> > > > > are empty anyway. This probably is a limitation of the Python
> > > > > CSV library, though. 
> > > > 
> > > > True... hmm, the design is that a series of lines with the same 
> > > > number of separators is what *defines* a table.  Probably 
> > > > reasonable for CSV, but I can see the issue with LaTeX. 
> > > > 
> > > > The simplest way I can think of addressing that would be some
> > > > way to normalize the number of delimiters in a table, either
> > > > have the user select the whole table or incrementally bring in
> > > > lines from above / below the table, adding empty cells to them. 
> > > > 
> > > > But if I remember LaTeX tables, that will impact line drawing, 
> > > > "1 & 2 \\" vs "1 & 2 & & \\" in a four column table for
> > > > example, the first leaves the rest of the line blank whereas
> > > > the second displays empty cells, if you're drawing lines
> > > > between cells that is.  I think. 
> > > > > I think it would also be nice if it could figure out the 
> > > > > separator by itself and start up with a good suggestion,
> > > > > similar to the "sniffer" tool in the CSV module. 
> > > > 
> > > > Might be doable, although I'm guessing that usually you'd only
> > > > need to change it once per session, and having it guess too
> > > > often might make it less flexible in terms of editing different
> > > > table types in the same node etc.  I did think of adding a
> > > > presets dropdown for CSV / tab / LaTeX / pipe etc. 
> > > > 
> > > > > That all said, thank you very much for this command. It makes
> > > > > my life a lot easier. 
> > > > 
> > > > Glad to hear it. 
> > > > 
> > > > Cheers -Terry 
> > > > 
> > > 
> >
> 

-- 
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: Moving on from Leo

[Terry Brown]

On Sun, 30 Dec 2018 11:37:04 -0800 (PST)
Matt Wilkie  wrote:

> I almost forgot: you have a new job! Congratulations!  I hope this
> next endeavour unleashes all kinds of fresh growth and learning, and, 
> adequate-plus-one (or two) remuneration. :-)

Thanks Matt and everyone else who's said kind things, I appreciate it.

Cheers -Terry


-- 
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: The future of Leo

[Terry Brown]

On Sun, 23 Dec 2018 05:53:15 -0800 (PST)
"Edward K. Ream"  wrote:

> We can make Leo more accessible by integrating Leo's essentials into
> emacs, vim, pyzo or even atom.

I was going to say that I don't understand this project because I'm not
sure which parts of Leo you're talking about, but #1025 certainly helps
on that front.  Still not quite sure about the boundaries.

FWIW, Vim seems to have good Python integration, and I suspect a significant
proportion of the more modern / actively developed plugins are written in
Python.  Ultisnips, for example, an abbreviations like plugin.

Python enabled Vims maintain a Python state.  In RHEL 7 I found it hard
to get Python 3 running, Ubuntu supports 2/3 easily.

Cheers -Terry 

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

Moving on from Leo

[Terry Brown]

I'm sorry to say that I'm moving away from involvement in Leo.  This is
due to no one reason but the combination of a number of factors, most
of which are external to Leo (different job, other projects).  I told
Edward about this a couple of days ago.

The specific factor prompting this announcement is that I recently gave
Vim a second (third?) look, and have switched to using it as my day to
day development environment.  So as I'm not using Leo I'm not working
on its development.

I've enjoyed working on Leo and with Edward and everyone else here and
will keep reading the email list.  It's a great community with lots of
interesting ideas.

Cheers -Terry

-- 
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: For Matt and other devs: leo/dist/git_install.py installs Leo using *only* git

[Terry Brown]

On Tue, 11 Dec 2018 14:08:14 -0800 (PST)
Matt Wilkie  wrote:

> Marked for study.
> Thank you Edward, Speed. :)
> 
> My first question is why? Meaning: I don't understand the problems
> it's solving. At first reading I thought it was for disconnected
> environments because of the zip archives, but there's also talk of
> pulling updates from Github so that doesn't quite fit. Python and Pip
> themselves are headless, so it's not getting around `pip install leo`
> and it's still using pip anyway.  Ohhh, is it because default `pip
> install leo` demands PyQt and other unwanted dependencies?

I tested

git clone --depth 1 https://github.com/leo-editor/leo-editor.git

in the docker image python:latest which conveniently contains bash and
git, and it seemed sufficient to create a leoBridge controller:
http://leoeditor.com/leoBridge.html

You just need to do `export USER=aUser` because USER is otherwise unset
and of course you can't ask for it graphically.

So headless Leo seems straight forward?

Cheers -Terry
 
> 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: edit-pane-csv separator

[Terry Brown]

On Fri, 30 Nov 2018 06:58:59 -0800 (PST)
Josef  wrote:

> Hi Terry,
> 
> after using edit-pane-csv for some time now, I have one big wish
> left: it would be great if Leo could remember the settings for each
> file, at least for @clean nodes. Ideally the csv pane would stay open
> for these nodes.

Would a button that toggled the pane work?  I can't remember if the
code has an easy way to set initial settings, but perhaps per-node
settings could be saved in p.v.u.

Cheers -Terry

> I have many csv files around, which I need to maintain manually on a 
> regular basis, so it would be nice if Leo could remember the settings
> for each of these files, and it would be even better if I would not
> have to run the command edit-pane-csv on each file every time after I
> closed the associated Leo file.
> 
> Cheers - Josef
> 
> On Friday, August 10, 2018 at 5:38:37 PM UTC+2, Terry Brown wrote:
> >
> > On Fri, 10 Aug 2018 08:14:53 -0700 (PDT) 
> > Josef > wrote: 
> >
> > > Hi Terry 
> > > 
> > > I tried 
> > > 
> > > Leo 5.7.4 devel, build 20180807122609 
> > > 
> > > and it did not work right away with a .latex file. It seems to
> > > get confused by the @language latex in the first line. It worked
> > > when I removed it. 
> > > 
> > > It would be nice if it would ignore leo directives. 
> >
> > Hmm, it doesn't pay any attention to leo directives, and just
> > defaults to ',' CSV mode.  Not sure what was going on there. 
> >
> > > Another quirk is, that every line needs to have the same number
> > > of separators, but particularly when editing latex tables by hand
> > > one does not always enter all cells if they are empty anyway.
> > > This probably is a limitation of the Python CSV library, though. 
> >
> > True... hmm, the design is that a series of lines with the same
> > number of separators is what *defines* a table.  Probably
> > reasonable for CSV, but I can see the issue with LaTeX. 
> >
> > The simplest way I can think of addressing that would be some way
> > to normalize the number of delimiters in a table, either have the
> > user select the whole table or incrementally bring in lines from
> > above / below the table, adding empty cells to them. 
> >
> > But if I remember LaTeX tables, that will impact line drawing, 
> > "1 & 2 \\" vs "1 & 2 & & \\" in a four column table for example,
> > the first leaves the rest of the line blank whereas the second
> > displays empty cells, if you're drawing lines between cells that
> > is.  I think. 
> > > I think it would also be nice if it could figure out the
> > > separator by itself and start up with a good suggestion, similar
> > > to the "sniffer" tool in the CSV module. 
> >
> > Might be doable, although I'm guessing that usually you'd only need
> > to change it once per session, and having it guess too often might
> > make it less flexible in terms of editing different table types in
> > the same node etc.  I did think of adding a presets dropdown for
> > CSV / tab / LaTeX / pipe etc. 
> >
> > > That all said, thank you very much for this command. It makes my
> > > life a lot easier. 
> >
> > Glad to hear it. 
> >
> > Cheers -Terry 
> >
> 

-- 
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: Oh my: fast, incremental redraws are doable in any gui

[Terry Brown]

On Mon, 26 Nov 2018 05:13:38 -0800 (PST)
"Edward K. Ream"  wrote:

> This may be true now, but perhaps Almar will be open to adding new
> methods to the TreeWidget or TreeItem classes.  Assuming that's
> possible :-) And assuming a real performance gain would result.

You can just subclass them?

Cheers -Terry

-- 
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: How to get viewrendered pane size?

[Terry Brown]

On Mon, 12 Nov 2018 21:16:49 -0800 (PST)
pimgeek  wrote:

> I want to create a changePaneSize @command in myLeoSettings.leo, but
> don't know how to get and change pane size, what should I do?

Probably the easiest thing is to arrange the panes as you want them,
then right click the divider between panes (doesn't matter which one),
select 'Save Layout', and give the layout a name.  It should persist
after that.

Cheers -Terry

-- 
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: Learning flexx, part 2, and LeoWapp status

[Terry Brown]

On Thu, 8 Nov 2018 08:47:39 -0800 (PST)
"Edward K. Ream"  wrote:

> On Thursday, November 8, 2018 at 7:04:05 AM UTC-6, Edward K. Ream
> wrote:
> 
> *How to communicate between components?*

I'd evaluate the emit / react ( / action) framework too - avoids having
to have everything know about everything else.

Cheers -Terry

> [big snip]
> 
> Happily, flexx properties provide everything needed.  Apparently, 
> > properties must be used to communicate even between different
> > flx.Widgets. That is, the ivars of one widget are not accessible to
> > other flx.Widgets. So the example code above might better be
> > rewritten this way:
> >
> > class LeoMainWindow(flx.Widget):
> > 
> > """
> > Leo's main window, that is, root.main_window.
> > 
> > Each property x below is accessible as root.main_window.x.
> > """
> > 
> > body = flx.AnyProp(settable=True)
> > log = flx.AnyProp(settable=True)
> > minibuffer = flx.AnyProp(settable=True)
> > status_line = flx.AnyProp(settable=True)
> > tree = flx.AnyProp(settable=True)
> >
> > def init(self, body, outline):
> > with flx.VBox():
> > with flx.HBox(flex=1):
> > tree = LeoTree(outline, flex=1)
> > log = LeoLog(flex=1)
> > body = LeoBody(body, flex=1)
> > minibuffer = LeoMiniBuffer()
> > status_line = LeoStatusLine()
> > self._mutate_body(body)
> > self._mutate_log(log)
> > self._mutate_minibuffer(minibuffer)
> > self._mutate_status_line(status_line)
> > self._mutate_tree(tree)
> >
> 
> I buried the lede big time here.  I wanted to emphasize that *all* 
> flx.Widgets have a root ivar 
> ,
>  
> which is the LeoApp instance.  So it's easy to add to the log
> widget!  For example, here is the event handler in the LeoTree class:
> 
> @flx.reaction(
> 'tree.children**.checked',
> 'tree.children**.selected',
> 'tree.children**.collapsed',
> )
> def on_event(self, *events):
> 
> log = self.root.main_window.log
> for ev in events:
> id_ = ev.source.title or ev.source.text
> kind = '' if ev.new_value else 'un-'
> s = kind + ev.type
> log.put('%s: %s' % (lpad(s, 15), id_))
> 
> Recall that pscript does not support features such as "10%s" which is
> why the code above does padding by hand using the global lpad
> function. Finally, here is log.put:
> 
> def put(self, s):
> self.ace.setValue(self.ace.getValue() + '\n' + s)
> 
> 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.

Not Leo in Flexx

[Terry Brown]

I could have sworn I'd posted about this, but can't find the post - I'd
be curious if anyone remembered a posting along these lines.  Pffft.

For a while (since Aug. 9 2018 according to git) I've been fiddling
with a Flexx based app. that is Leo like.  But not Leo.  It's an
experiment with a different data model (VDCG, Vaguely Directed Cyclic
Graphs).  Nodes / edges are stored in a DB.  Edges belong to sets, or
graphs.  Nodes can occur in multiple graphs.  Sort of sea of nodes /
colored threads / Kent's extra dimensions (maybe).  So when you want
the list of children for a node, you have to specify the graph, a node
has a different set of children in each graph.

The initial question is can you navigate this using a tree?  So I have
a tree widget that supports moving nodes, and string widgets to edit
the name and "body" of the node.  Data on a node is generalized as a
dict / JSON string, so nodes having a head / body is an option, not a
requirement.  Fiddling with questions about whether you should see
nodes from two or more graphs under a node at the same time, etc.

App. components aren't directly connected, they broadcast messages that
other components can react to, or not.  Insert node, for example,
broadcasts a msg. ('insert_node') from the JS tree component.  The
"core" (Python) component hears that, changes the DB, and broadcasts a
msg. ('node_inserted') telling any listening widgets about that change.

Leaving a lot of rough edges (focus, can't manipulate top level nodes,
keyboard nav. of tree etc.) while I try and work out if this model
(VDCG) is usable.

No particular point to this message other than that I could have sworn
I'd written this before, but see no evidence that that's the case.

Tangentially, I've also been using vim a lot for day to day work.  I
see the Ace editor has a vim keyboard mode.

Cheers -Terry

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

[Terry Brown]

Flexx is very different from other frame works because you write everything in 
Python. You might try writing a web gui in Vue, React, or JQuery to get 
something more typical.

Cheers - Terry 

On November 3, 2018 3:11:12 PM CDT, "Edward K. Ream"  
wrote:
>On Saturday, November 3, 2018 at 6:57:36 AM UTC-5, Edward K. Ream
>wrote:
>
>The skeleton defines browser-based wrappers for Leo's gui classes. The 
>> skeleton is intended to be a common front end for frameworks such as
>flexx.
>>
>
>This organization does not look likely to survive first contact with
>the 
>flex classes.  Still, I'm glad to have done what I did first.  It will 
>serve as a history.
>
>It's time to integrate the skeleton with a framework.  I'll start with 
>> flexx.  This will show where the skeleton needs more work, perhaps
>even a 
>> rethink.
>>
>
>A rethink is likely, but that does not bother me.  The flexx way may be
>
>simpler than what I had envisioned.  In any case, the present classes
>in 
>leowapp.py can be changed easily.
>
>The flexx work will be done in a new flexx branch.  I'll update the 
>> skeleton branch as needed.
>>
>
>I'll probably continue to do work in the skeleton branch. Rather than 
>create a new branch, I'll create a new plugin, say leoflexx.py.  A few 
>tweaks to the gui-related startup code in leoApp.py should suffice to 
>choose between various options for --gui=browser.
>
>This scheme should be more convenient than switching between different 
>branches.  Instead, I'll just work on leoflexx.py, and update
>leowapp.py as 
>appropriate as my ideas evolve.
>
>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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Terry Brown]

On Thu, 1 Nov 2018 20:41:48 -0700 (PDT)
Matt Wilkie  wrote:

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

Ah, good catch - I was aware of the other dependencies which are Flexx
offshoots, but overlooked Tornado.

If Flexx ends up with no role beyond passing messages between Leo and
Javascript, it would probably be better to just use Tornado or
something to do that.

Cheers -Terry

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

[Terry Brown]

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

Flexx completely hides the websockets part, it's more like React (I
think, having used that once), but basically signals / listeners /
actions / reactions. It actually takes a while to understand what part
of the code's running in JS and what part in Python, seeing it's all
authored in Python.  Then you run into things like "%06x" % n not
converting n to a hex string on the JS side.  But overall the
translation from core Python to JS is quite impressive, as in so
transparent you don't even notice it.

Cheers -Terry

On Wed, Oct 31, 2018 at 10:17 AM vitalije  wrote:
>>
>> Does that mean you think the flexx framework is a good idea? Or do you mean 
>> that Tornado itself would be the framework?
>
>
> I don't know about flexx. But you wrote above that flexx uses tornado for 
> websockets. I conclude from that tornado is lower level than flexx. And I 
> have implemented some websocket using tornado and it seems to me that it can 
> achieve on its own what you need for LeoWapp.
>
> For websocket to work there must be some thread which would check socket and 
> call appropriate methods/functions when websocket has been open, closed, or 
> new message has arrived. This thread should also take your outgoing messages 
> and send them to the browser. Tornado has built in IOLoop which handles all 
> threads and user doesn't have to do anything about threads except to call 
> IOLoop.start once. This is very similar like starting gui application by 
> starting mainloop.
>
> In essence web-socket programming is then very much like GUI programming. You 
> define methods that will be called when connection is established (at that 
> time one usually stores the sender address for later communication); then on 
> each received message (which is just an object of bytes type), you need to 
> decode this message (for example json.loads(msg)), and depending on decoded 
> message content perform appropriate action. This action may be to reply with 
> some value that browser has asked for, or to change something in Leo outline, 
> or to execute script and return result. For events that are generated inside 
> Leo (for example when outline needs to be redrawn) websocket handler should 
> send a message to browser informing about changes.
>
> Vitalije
>
> --
> 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.

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

[Terry Brown]

I mentioned this elsewhere, but just want to say Flexx is different in
that it translates Python to javascript, although not really, really
it lets you write javascript using Python syntax.  So its intent is
that you don't write javascript, and if you do it that way, you
probably won't be able to swap out frameworks easily. OTOH there's
always a point where you're committed to a framework - an interface
written in React or Vue is like an interface written in Qt.  But
Flexx's expected model for communication between the Python and
javascript sides is perhaps less swap out able. You could just use it
as a message pipeline, but there are probably other options for that.

And I'd expect this project to be significantly bigger than the curses project.

Cheers -Terry

On Wed, Oct 31, 2018 at 5:44 AM Edward K. Ream  wrote:
>
> On Wednesday, October 31, 2018 at 5:32:33 AM UTC-5, Edward K. Ream wrote:
>
>> flexx looks like exactly what LeoWapp needs, but I won't commit to flexx 
>> until much later, if at all.
>
>
> I forgot to mention two things:
>
> 1. Studying vue.js is high on my list.  An important goal of LeoWapp is to 
> support Joe Orr's work.
>
> 2. LeoWapp will undoubtedly be significantly easier than Leo console gui.  My 
> goal is to have unit tests fail in a day or two.
>
> 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.

-- 
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 will use WebSockets and Python 3

[Terry Brown]

On Tue, 30 Oct 2018 12:16:34 -0500
"Edward K. Ream"  wrote:

> I've gotten the first few Flexx examples working.  The widgets look
> ugly, but perhaps that will not be an issue in the long run...

I'm not sure how that will play out, for example can you integrate
Flexx with other layers like Bootstrap?

It can embed editors like Ace:
https://flexx.readthedocs.io/en/stable/examples/editor_ace_src.html#editor-ace-py

and use frameworks like d3:
https://flexx.readthedocs.io/en/stable/examples/d3_collision_src.html#d3-collision-py

Flexx's tree is fairly basic, no keyboard nav. etc., if I were
attempting what you're attempting I'd look at using
http://www.inspire-tree.com/ from Flexx - Offray pointed out Inspire Tree 
recently.

I'm not saying that's an easy way to go, but it might give you a head
start vs. adding features to Flexx's tree.

Cheers -Terry

-- 
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 will use WebSockets and Python 3

[Terry Brown]

On Tue, 30 Oct 2018 11:50:12 -0500
"Edward K. Ream"  wrote:

> On Tue, Oct 30, 2018 at 11:07 AM Terry Brown 
> wrote:
> 
> I do wonder if it's necessary to include development of a websockets
> > layer in LeoWapp.  Maintenance burden, complexity, all that.
> >
> > Flexx is a Python framework that uses websockets, there are probably
> > others.
> >
> > Also there a lots of web app. frameworks (Flask, Django, etc.) which
> > don't use websockets by default (they use regular AJAX), but can.
> 
> That welcome news. I agree we should use the highest level tools
> available.
> 
> I'll study Flexx, Flask and Django next.  I had no idea they could use
> websockets.
> 
> What framework do you prefer?

They're all very different.  I've used Django quite a bit in the past,
and would again for large web based applications.  It handles user
logins, rights management, templates, database binding and updating,
form generation, etc. etc.  Probably not the right weight for LeoWapp.
I don't know what it's like for web-sockets, "Django Channels" use
web-sockets, that's all I know.

Haven't used Flask, just fiddled with tutorial.  No idea if its
websocket support is very mature / well integrated.

Am playing with Flexx experimenting with visualizing multiple graphs,
thought I'd mentioned that although not seeing the post now.

Flexx uses web-sockets by default / exclusively, so it's probably going
to be the most solid there.

Flexx's approach is idiosyncratic enough that you're probably stuck
with it if you use it (it translates Python to Javascript :-) but there
might be options which let you separate the transport layer.  Certainly
this would be the case if you were using regular AJAX, I'm less
familiar with options for websockets.

I'm thinking the decision that LeoWapp will use websockets is fine, but
you won't always see the performance benefits of websockets over AJAX.
On a local machine AJAX should be fast enough, seeing the "network" is
basically in memory, and over remote links I suspect (not sure) that
you'll need good low latency connectivity or the network will be the
bottleneck, not the transport protocol.  Don't want to dissuade you
from websockets, just that AJAX is more common and therefore easier for
Google to answer random questions etc. etc.

Cheers -Terry

-- 
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 will use WebSockets and Python 3

[Terry Brown]

On Tue, 30 Oct 2018 08:51:18 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Tuesday, October 30, 2018 at 5:54:39 AM UTC-5, Edward K. Ream
> wrote:
> 
> It's troubling to disable security checks, even temporarily. I'm a
> bit 
> > surprised that such matters weren't mentioned in the websockets 
> > documentation
> > .
> 
> The left-hand panel contains links to the full documentation,
> including security.  It's time to study...

I do wonder if it's necessary to include development of a websockets
layer in LeoWapp.  Maintenance burden, complexity, all that.

Flexx is a Python framework that uses websockets, there are probably
others.

Also there a lots of web app. frameworks (Flask, Django, etc.) which
don't use websockets by default (they use regular AJAX), but can.

Cheers -Terry

-- 
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 will use WebSockets and Python 3

[Terry Brown]

https://github.com/flexxui/flexx
provides websocket based Python browser GUI connections.
John Lunzer pointed it out here:
https://github.com/leo-editor/leo-editor/issues/338#issuecomment-289618411

I've been using it in my recent (non-Leo) experiments in this area.

Cheers -Terry

On Mon, 29 Oct 2018 03:55:21 -0700 (PDT)
"Edward K. Ream"  wrote:

> Yesterday I started work in earnest on the leowapp.py plugin.  The
> gui work is complete for now: the web page contains the outline, body
> and log panes and the minibuffer.
> 
> Attempting two-way communication encountered a roadblock.  Putting 
> "require(http)" in a client-side script fails with the console
> message:
> 
> ReferenceError: require is not defined
> 
> We can not use a node.js server in the browser, as explained here 
> 
> .
> 
> With my new insights about sockets, I saw that the proper question is
> *not*:
> 
> Can javascript create *servers *in browsers?
> 
> but instead:
> 
> Can javascript create *sockets *in browsers?
> 
> The answer to this question is an emphatic yes 
> .
>  
> This leads to WebSockets ,
> with this tutorial
> .
> 
> *Summary*
> 
> WebSockets is perfect for LeoWapp: high performance, two-way
> communication, supported by all major browsers.  LeoWapp is essential
> if Leo's browser gui is to have the fine granularity I envisaged in
> the initial design.
> 
> web.py  or requests 
>  might replace the aging,
> ugly, python-side guts of leowapp.py. (The present code barfs on POST
> requests). We shall see. requests is part of the Anaconda distro,
> web.py is not.
> 
> Edward
> 
> P. S. Imo, LeoWapp should *require *Python 3. I see no justification 
> supporting Python 2 in leading-edge web work.  Comments in the 
> documentation for the requests package indicate that there are
> serious problems in attempting to do so.
> 
> 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: At last I understand sockets and servers

[Terry Brown]

On Sun, 21 Oct 2018 21:20:33 -0500
"Edward K. Ream"  wrote:

> Hmm.  Is Leo as a web app is feasible? Leo's scripting features make
> it extremely dangerous. If run on a server, Leo becomes an
> unverifiable cgi script. This looks like a gotcha.  Am I missing
> something?

Sandboxing / encapsulation with Docker or some similar container system
seems like the easy way.  Containers are much lighter than VMs, so you
should be able to run many sessions, depending on hardware etc.

Docker containers start fast enough if you're running something
long-lived like a session on leoBridge.py or something that runs for
the same length of time as a typical Leo session.  I *think* they'd be
too slow to exist transiently and respond to single requests, although
maybe hot cache on a suitable machine could run that way.  But I'm
guessing you're looking for something more persistent, anyway.

I just tried starting a Docker environment I have based on
conda/miniconda3 which is based on debian, and it starts in under a
second.  It has tex-live / numpy / matplotlib (which pulls in a chunk
of Qt), so it's probably similar in size to something that would run
Leo.

Cheers -Terry

-- 
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: At last I understand sockets and servers

[Terry Brown]

On Sun, 21 Oct 2018 10:44:21 -0500
"Edward K. Ream"  wrote:

> On Sun, Oct 21, 2018 at 10:37 AM Cormac Williams
>  wrote:
> 
> > 
> 
> Hi.  Welcome to the discussion.
> 
> > Sockets and protocols are great, except if you want to hang it on
> > the internet, in which case you are far better using tried and
> > tested methodologies and frameworks.
> 
> I didn't mean to imply that sockets are all there are to the internet.
> Presumably a mature server like Apache will be required.
> 
> > Actually, I'd say use tried and tested for even local service. A
> > specialist protocol is only really required if you are doing
> > something radically different from what has come before, which I
> > get the feeling we are not talking about here.
> 
> We can start by assuming ajax
> , using
> http.

I wonder if Cormac was thinking of frameworks like Django, but perhaps
more appropriate (lighter) for Leo, Flask?  Django and Flask have
sub-components that handle translation between URL and Python code, and
I think there're libraries which *just* do that.  Flask's extra
features may or may not be useful.  Also being aware of WSGI is probably
good, but perhaps still a level lower than you need to be.

Also mod_http.py plugin allows execution of arbitrary Python code in a
running Leo, so there's that to look at too.

I've seen setup using Apache at the very front of a web-app hosting
ecosystem, with nginx (another web server) behind that handling
requests to actual backend services in Python (maybe by WSGI, not
necessarily).  At some level on all these systems though Python ends up
handling the request, so for development at least, you usually see
Python serving the web part.

Cheers -Terry


-- 
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: Docker for LeoVue etc.

[Terry Brown]

On Wed, 17 Oct 2018 03:30:46 -0500
"Edward K. Ream"  wrote:

> I assume that a machine must be running the guacamole server to be
> accessible via the client.
> 
> Edward

No, it needs to be running a remote access protocol like VNC
(vnc-server, not vnc-client) or RDP.  And it needs to be accessible to
a machine running the guacamole server network wise.  VNC/RDP is fairly
trivial to install, not true of guacamole.

So normally machine A is running the guacamole server, it can connect
to machines B, C, and D which are running VNC / RDP.  And someone
connects to A from E using a browser, and can then view B / C / D.

If you (a) had network connectivity from E to C, and (b) had vnc-client
software installed on E, you could access C from E without guacamole.
But (a) and (b) are often not true and (a) is sometimes insurmountable,
so guacamole is useful.

My Docker container makes A and B the same machine, running a VNC
server as well as guacamole.  Which is probably typical of people using
guacamole to access their personal desktops via the web, but guacamole
is designed to provide a gateway to whole offices / institutes of
machines, not just one.

Cheers -Terry

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

Leo as a web app.

[Terry Brown]

Here's a Dockerfile that let's Leo (The Python3 / PyQt4 version) run in
a web browser.  This is cheating, and I think I demoed this years ago
without Docker, but it might be useful for someone.

Would be interested to hear if anyone tries it / runs in to issues.
Easier to understand if you're familiar with Docker, but I don't think
it needs any special Docker knowledge to get it running.

Almost forgot the link :)

https://github.com/tbnorth/leo-docker

Cheers -Terry

-- 
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: About separate processes and threads

[Terry Brown]

On Tue, 16 Oct 2018 04:36:31 -0700 (PDT)
"Edward K. Ream"  wrote:

> The original Dreaming Big Dreams thread suggested reorganizing Leo
> into more separable pieces, perhaps using a client/server
> architecture or other forms of interprocess communication (IPC).

Here's a presentation I just gave:
https://tbnorth.github.io/multiproc/

So processes *can* share memory, although the sharing is managed with
IPC calls.  My presentation's for distributed processing of data in
NumPy, CPU intensive, not necessarily relevant to whatever it is you're
considering for Leo.

Cheers -Terry

> Here I'd like to present what little I know about IPC, servers and 
> threads.  The purpose is continue the conversation, and to expose my
> own misconceptions.  Please comment.
> 
> *Separate processes share no data*
> 
> Some kind of IPC is required. There seems to be no end of such
> mechanisms:
> 
> - pyzo uses yoton .
> - neovim uses msgpack plus
> vim-related wrappers.
> - LeoVue uses node.js client-server architecture.
> - Jupyter uses another client-server
> architecture.
> - All other client/server architectures have/are their own forms of
> IPC.
> 
> I have no idea what would be best for a more "distributed" version of
> Leo. Does anyone have any organizing principles or ideas they would
> like to share?
> 
> *Separate threads share (almost?) all data*
> 
> Debuggers need access to the program under test, so must run in a
> separate *thread* rather than a separate process.  Otoh, both the
> debugger and the program under test could run in a separate process
> from the IDE.  In that case, the processes would have to communicate
> via IPC.
> 
> The shared data between threads causes well-known problems.  Race 
> conditions can result.  Python's queue.Queue is one (low performance)
> way of avoiding some, but not all, of the problems.
> 
> Leo's new debugger contains a listener, in the main thread, that
> receives requests from the debugger thread.  The debugger thread is
> driven by commands from the main thread.  None of the code could be
> called elegant. It has a chance of working because *only *the
> g.app.xdb ivar is set by both threads. It must be set/cleared very
> carefully. As I write this, I suspect that the present code, while
> not *necessarily* wrong, would likely benefit from a lock
> on
> this ivar.
> 
> *Summary*
> 
> There seems to be too many choices for IPC.  Your comments, please.
> Please correct me if I have said something dubious.
> 
> 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: Docker for LeoVue etc.

[Terry Brown]

On Tue, 16 Oct 2018 05:46:00 -0500
"Edward K. Ream"  wrote:

> On Mon, Oct 15, 2018 at 3:23 PM Terry Brown 
> wrote:
> 
> > Responding to Chris's comments re cPanel / LeoVue etc., just a PSA,
> > Docker is easier and more useful than you think ;-)
> >
> 
> Thanks for this.  Despite the work I did on #735 (how to install and
> run LeoVue) <https://github.com/leo-editor/leo-editor/issues/735> I
> don't remember much about node.js.
> 
> It would be best to make a Docker image for Leo, but running GUI
> apps. is

I'm not sure why I wrote "best", I probably meant to say "easy".

> > really only straightforward in unix/X11, much more trouble in
> > Windows.
> 
> Really?  Iirc, LeoVue runs on Windows.  What are the specific
> problems?

Sloppy writing on my part.  I was talking about Leo, not LeoVue.
container / host network connections are easy in Docker, and because
X11 runs over a network (kind of) it's easy to open GUI apps. from a
container on the host desktop.

Also Docker's just less convenient on Windows, passing paths, finding a
decent terminal, that kind of thing.

I'm wondering though if I can add Leo to a container running Apache
Guacamole, making Leo a containerized web app., probably more of a
novelty than anything.

Cheers -Terry

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

Docker for LeoVue etc.

[Terry Brown]

Responding to Chris's comments re cPanel / LeoVue etc., just a PSA,
Docker is easier and more useful than you think ;-)

It sits less comfortably in Windows than it does in Linux, but it
gives an extremely clear cut curated environment and is really not
complicated to use if you're at all familiar with the command line.

Here's a page on dockerizing a node app.:

https://nodejs.org/en/docs/guides/nodejs-docker-webapp/

But my more general point is that Docker's much easier than you think,
and much lighter weight than using virtual machines for clean /
disposable environments.  I with I'd looked into it years ago.

It would be east to make a Docker image for Leo, but running GUI apps.
is really only straightforward in unix/X11, much more trouble in
Windows.

Cheers -Terry

-- 
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: Dreaming big dreams

[Terry Brown]

On Sat, 13 Oct 2018 06:06:29 -0500
"Edward K. Ream"  wrote:

> > .../foo/test/test_my_module.py->test_my_func()
> > 
> Thanks for this.  So for every @file x.py, we would create an @file
> test/x.py. It's a reasonable solution.
> 
> Leo makes the idea of "near" meaningless, there's plenty of ways to
> jump between these pieces of code easily.
> > 
> Hmm.  This suggests creating unl's linking code to their tests. These
> tests could be @test nodes or @file nodes containing, say, pytest
> test functions. I should have thought of this before.  It's a great
> solution.

You don't really even need an UNL, if you have a convention a button
can work out whether you're looking at the test or the code, and switch
between them, see
https://groups.google.com/d/msg/leo-editor/pdvXCZePi_I/8a4gtobvAwAJ

Cheers -Terry

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

Three dimensional graphs

[Terry Brown]

Funny you should bring up a third dimension, I've been experimenting
with something along these lines, although not within Leo :-/  No
doubt inspired by various discussions on this list (sea of nodes,
colored threads, Kent's mysterious extra dimensions :-).  Data model
is basically a set of nodes shared between a set of graphs.  So nodes
might be things like a reference to a filesystem file, or a todo item,
or some notes, and the graphs might have names like "Files", "Todo",
"Kanban", "Tests", "Docs". The idea is that the same nodes can
participate in different graphs.  Data's stored in a DB.

I haven't got very far yet, basically trying to work out if this can
be visualized with a tree (specifically, can you represent more than
on graph in the same tree), and how to do that.

Cheers -Terry

-- 
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: Dreaming big dreams

[Terry Brown]

On Mon, 8 Oct 2018 02:58:28 -0700 (PDT)
"Edward K. Ream"  wrote:

> - Why can't we put unit tests near the code being tested?

I'd argue (for Python) for using the best in class unit testing
framework's practice.  pytest puts tests for

.../foo/my_module.py->my_func()

in

.../foo/test/test_my_module.py->test_my_func()

Leo makes the idea of "near" meaningless, there's plenty of ways to
jump between these pieces of code easily.

As you said elsewhere "One of my biggest mistakes has been not using
existing tools.", I'll explain my feeling's towards Leo's unit testing
framework.  I am (approximately) a Python developer, not a Leo
developer.  So having to take the time to learn Leo's personal unit
testing framework, knowing I'm going to want to use pytest for any
other project, causes me to not write unit tests for Leo.

> - Why can't we use javascript, or prolog within Leo?

The richtext plugin runs a WYSIWYG HTML editor in javascript in Leo, so
I think javascript shouldn't be hard.  Chances are the plugins broken /
needs maintenance, and while we could blame Qt's web support history
for that, to be fair all code needs maintenance.

Cheers -Terry

-- 
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: Persistent ID for @auto nodes

[Terry Brown]

On Wed, Sep 26, 2018 at 10:25 AM Edward K. Ream  wrote:
>
> On Wednesday, September 26, 2018 at 5:58:18 AM UTC-5, Edward K. Ream wrote:
>
>> It highlights the problem of learning and remembering what Leo can do.
>>
>> Words are not the answer: there are too many of them already.
>>
>> I think pictures would work better.  I've created a project called 
>> "Screenshots tell the story" as a partial remedy.
>
> My present plan is to put lots of screen shots on various pages by scaling 
> them to a small size, with a reminder to readers that they can view the 
> full-size version using the "view image" feature in their favorite browser.  
> The present way is too clunky, imo.

Indeed.  But believe it or not, there isn't a zoom function in
https://www.jqueryscript.net/tags.php?/image%20zoom/ that does exactly
what you want, zoom an image to 100% when clicked. Most of them show a
magnifying glass over the image, the minority that pop up the full
image don't scale it to 100%.  Well they do, but only if it fits
comfortably on the screen to start with.  I guess it wouldn't be so
hard to write one, but hard to believe there's not one that meets such
simple requirements when there's 50?+ to choose from.

Cheers -Terry

> Leo's tutorials should benefit from screen shots.  For example, it would 
> simplify the discussion of @button.
>
> Leo's home page uses this technique. It now reminds viewers that they can see 
> the full-sized image.
>
> 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.

-- 
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: Reversing relationships

[Terry Brown]

Possibly the backlinks plugin might be useful to you, not sure.

Cheers -Terry

On Tue, 25 Sep 2018 15:58:32 -0700 (PDT)
Israel Hands  wrote:

> Assuming my information tree is only one child deep and looks a bit
> like this-
> 
> Parent 1
> Contains nodes - A B C D
> 
> Parent 2
> Contains nodes B C D E
> 
> Parent 3
> Contains nodes A C D E
> 
> etc.
> 
> and I want the best way to reverse the relationship - 
> 
> So 
> 
> Node A 
> Is in - Parent 1 and Parent 3
> 
> Node B
> Is in - Parent 1 and Parent 2
> 
> Node C
> is in - Parent 1 and Parent 2 and Parent 3 
> 
> a view or filter would be fine rather than a restructuring. But it
> would be nice if it could be displayed in the 'Edit' pane rather than
> the output of a search in the log pane - is that possible? Well I
> know it is possible but is there some clever Leonine way that already
> exists to do this?
> 
> ta
> 
> IH

-- 
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: Need help with bidirectional relationships with differing commentary on each side

[Terry Brown]

On Sat, 1 Sep 2018 23:04:03 -0700 (PDT)
Sapphira Armageddos  wrote:

> - UNLs: Straightforward, but can lead to needing to manually copy the
> individual UNLs to track bidirectional relationships across files.
> Also allows for commentary on those relationships.
> 
> - Backlinks: Tried the plugin, liked it, but, storing additional data
> for the relationship (name, commentary) requires an intermediate
> node. Sometimes that commentary differs per character despite it
> being the same relationship type. Also doesn't handle cross file
> bidirectional relationships.

I think you've explored most of the obvious options.  There's also a
tagging plugin, but not sure that would be relevant.  The issue of
needing an intermediate node is a common one in graph relationships -
you could have edges that carry as much data as nodes, but just when
you think the problem's solved, the information on an edge becomes
complicated enough to make you want a hierarchical representation for
it, and now you want sub-nodes on an edge's info... :)  Well, I've seen
it go that way anyway, I guess I'd say use an intermediate node - I
think the backlinks plugin shows the name of a couple of levels of
nodes in links, although I can't remember the details top of head.

Cheers -Terry

-- 
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: seeking guidance on using Leo collaboratively with Git

[Terry Brown]

On Mon, 27 Aug 2018 10:55:13 -0700 (PDT)
Phil  wrote:

> Thanks for that, it's helpful. But the notion of a reference file
> begs the question of who maintains *that* file. In my project, both
> my partner and I are continually creating new content, which means
> that we would both need to make changes to the reference file. This
> impedes the efficiency that we could achieve by working concurrently
> - we would instead need to take turns updating the reference file.
> 
> Maybe I'm still missing something?

I'd do something like this:

 - each have your own Leo file, which is your personal view of the
   project, so the fact they're different might be quite convenient.
 - use something like the active_path plugin (or a script / button
   whatever) to make adding references to new external files trivial.
   In the case of the active_path plugin you just double click the
   directory node to show unloaded files in that directory.
 - if you want to backup you personal Leo files in the shared git repo.
   you could, in some folder like .../etc/usr/phil/SomeProject.leo and
   .../etc/usr/philscollaborator/TheProject.leo
 - or you could see that perhaps the .leo file is surprisingly low
   value, depending on what you put in it, the low chance of losing it
   and the ease of recreating it with the above active_path etc.
   approach might make it not worth backing up
 - if your storing to do items or using @clean with edited node
   arrangements or similar you will want to back up the .leo file,
   either in the shared git repo. or some other way, perhaps your
   systems regular nightly backup ;-)

Cheers -Terry


> On Monday, August 27, 2018 at 10:42:37 AM UTC-5, Edward K. Ream wrote:
> 
> > On Mon, Aug 27, 2018 at 10:19 AM Phil  > > wrote:
> >
> >> I am currently collaborating on a project with one other person,
> >> using Leo and Git. In addition to committing derived files to Git,
> >> we have also been committing the Leo file itself. We have had some
> >> occasional problems (a corrupted Leo file, mainly), making me
> >> think that we should *not* put the Leo file in Git - but maybe
> >> it's something *we're* doing wrong, and not Leo.
> >>
> >> What is the recommended way to use Leo in this scenario?
> >
> > There are several FAQ entries .
> > Let me know if you have questions or comments.
> >
> > 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: First Month of Using Leo

[Terry Brown]

On Mon, 20 Aug 2018 06:16:28 -0500
"Edward K. Ream"  wrote:

> > So far I've only really had success with simple abbreviations to
> > quickly add TODO and various :tag: to Org Mode tasks. For instance,
> > this one makes adding tasks a little easier to enter into a node
> > header: th;;={|{x="TODO"+" :Home:"}|}
> > 
> > I would really like to improve this abbreviation by moving the
> > cursor to between TODO and the tag, but I've not worked out how to
> > do that yet.
> > 
> Apparently, it's not possible to reset the insert point or selection
> range from abbreviations.  I've just spent over an hour try to do
> that.
> 
> The idea was to define a set_cursor function in @data
> abbreviations-subst-env, but that didn't work.  w.setInsertPoint
> didn't "take" in time.  And there were problems in the actual
> abbreviation code.
> 
> My apologies for this.  The abbreviation code is horrendous, and has
> lots of difficult interactions with the Qt widgets.

I think the abbreviation definition would be:

th;;=TODO<||> :Home:

This works when editing the headline of an existing node, but not when
editing the headline of a node just created with Insert.  So Leo is in
some subtly different state in this case which I don't really think the
abbreviation code can be blamed for.

Cheers -Terry

-- 
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: Terry, please explain how provided widgets get a parent

[Terry Brown]

On Mon, 20 Aug 2018 15:39:12 -0500
"Edward K. Ream"  wrote:

> On Sat, Aug 11, 2018 at 2:17 PM Terry Brown 
> wrote:
> 
> > Without a parent I don't understand how the Turtle widget will ever
> > > become visible.
> >
> > Who told you parents are essential?  Probably your parents... :-)
> 
> Hehe.
> 
> But I do think specifying a parent, directly or indirectly, is
> essential. Without it, the window becomes a stand-alone window, or so
> I think.
> 
> I see the same behavior on Ubuntu or Windows.  The code you gave shows
> nothing in the allocated window area.  Modifications of the code show
> the staircase in an external window.

Hmm, well the code worked for me when executed in two steps, as I
thought I'd described, but maybe I didn't.

First you execute the top part, i.e. import, class def, and
c.free_layout.get_top_splitter().register_provider(TurtleProvider(c))

then (easter egg menu) right click a divider, select Insert, which
creates an action button, then click that to open the 'Graphics scene
turtle' pane.

Then run the second half of the code.

The above worked for me in vanilla (HOME=/tmp) Leo.

Cheers -Terry

-- 
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: Back to fixing bugs

[Terry Brown]

On Fri, 17 Aug 2018 06:13:51 -0700 (PDT)
"Edward K. Ream"  wrote:

> Rebecca and I will be traveling most of September.  Before then, I'll
> fix as many bugs as I can.

Have a good trip.  I'm offline pretty much for the remainder of August,
FYI.

Cheers -Terry

-- 
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: Steps to install leo using pip in python 3.5

[Terry Brown]

On Thu, 16 Aug 2018 21:45:58 -0400
Brian Theado  wrote:

> • Disable python_terminal plugin

Interesting, I'd noticed this too, playing with Docker images as test
install environments.  It seems to be the line

from rlcompleter import Completer

but not that it necessarily fails to import, just that it causes
segfaults.

Cheers -Terry

-- 
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: Trying to install on Ubuntu 16.04

[Terry Brown]

On Thu, 16 Aug 2018 00:37:09 -0700 (PDT)
"Isaiah St. John"  wrote:

> Hi all,
> 
> I learned of Leo from the recent HackerNews post. I'm a novice Linux
> user, and I have tried just about every suggested installation method
> on the Leo website without success. I first installed pip3, then did
> "pip3 install leo", but it failed. I then tried following the
> instructions for installing from a debian package 
> . 
> That also failed. Here is the error I get for "pip3 install leo":

Hi Isaiah,

You could try downloading and unzipping this file:
https://github.com/leo-editor/leo-editor/archive/devel.zip
(the current git devel branch)
then in that folder

  python3 launchLeo.py

hopefully that works, if not, try

  python3
  from PyQt5 import QtCore

to confirm your PyQt installation.

Hope that helps,

Cheers -Terry


> istjohn@istjohn-VirtualBox:~/leo$ pip3 install leo
> Collecting leo
>   Using cached 
> https://files.pythonhosted.org/packages/94/5e/59accdea675f9b610c4fc08ea4b4db379cfe812e20c476012e134fdacd19/leo-5.7.3-py2.py3-none-any.whl
> Collecting docutils (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/36/fa/08e9e6e0e3cbd1d362c3bbee8d01d0aedb2155c4ac112b19ef3cae8eed8d/docutils-0.14-py3-none-any.whl
> Collecting sphinx (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/6d/62/e95cbd4966acaecb8805c321609ba986e47d806e5735967acfe2db3f7c26/Sphinx-1.7.6-py2.py3-none-any.whl
> Collecting semantic-version (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/28/be/3a7241d731ba89063780279a5433f5971c1cf41735b64a9f874b7c3ff995/semantic_version-2.6.0-py3-none-any.whl
> Collecting pyflakes (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/44/98/af7a72c9a543b1487d92813c648cb9b9adfbc96faef5455d60f4439aa99b/pyflakes-2.0.0-py2.py3-none-any.whl
> Collecting pypandoc (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/71/81/00184643e5a10a456b4118fc12c96780823adb8ed974eb2289f29703b29b/pypandoc-1.4.tar.gz
> Collecting keyring (from leo)
>   Using cached 
> https://files.pythonhosted.org/packages/88/a8/341fa4686e98bf10289eb4eaea89e8176b93c1e38de52e3c42d9112baae1/keyring-13.2.1-py2.py3-none-any.whl
> Collecting PyQt5; python_version >= "3.0" (from leo)
>   Could not find a version that satisfies the requirement PyQt5; 
> python_version >= "3.0" (from leo) (from versions: )
> No matching distribution found for PyQt5; python_version >=
> "3.0" (from leo) You are using pip version 8.1.1, however version
> 18.0 is available. You should consider upgrading via the 'pip install
> --upgrade pip' command.
> 
> I've installed pyqt5 with 
> sudo apt install python3-pyqt5
> 
> I'd appreciate any help figuring this out. I am eager to play with
> this program.
> 

-- 
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: Terry, please explain how provided widgets get a parent

[Terry Brown]

On Sat, 11 Aug 2018 11:37:18 -0700 (PDT)
"Edward K. Ream"  wrote:

> I can get a Turtle window working outside the
> free_layout/nested_splitter framework. The graphics window is a
> separate window, as expected.
> 
> But I'm stumped at how the widget returned from ns_provide eventually
> gets a parent.  I don't see that happening in the NestedSplitter
> class.  For instance, in either ns.replace_widget or ns.
> replace_widget_at_index.  Well actually, there are calls to
> setParent(None), but why would that help?
> 
> Without a parent I don't understand how the Turtle widget will ever
> become visible.

Who told you parents are essential?  Probably your parents... :-)

I guess setting parents is good practice, but it's not essential.

Perhaps
https://github.com/leo-editor/leo-editor/blob/master/leo/plugins/nested_splitter.py#L865
does it implicitly.

Attached is what I get when I select / Ctrl-B run the first part of the
example, then add a Turtle pane, then select / Ctrl-B run the second
half of the example.

So it's visible and works.  But if your goal's drawing trees in a
QGraphicsScene I don't think you need to create a QGraphicsView of the
scene using free_layout in the first instance, that can always be done
later.

Cheers -Terry

-- 
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 prototype of fast Qt tree drawing

[Terry Brown]

On Fri, 10 Aug 2018 11:06:11 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Thursday, August 9, 2018 at 12:50:20 PM UTC-5, Terry Brown wrote:
> 
> > But for the sake of completeness, here's a turtle:
> 
> I can set up the new pane, and run the script.  Traces show:

Hmm, it worked for me, drew a stair step line, in black on a dark
background, so hard to see.

You could just attach the QGraphicsView to self.c in ns_provide, ok for
prototyping.  The example function writes into the QGraphicsScene,
doesn't need to access the view, can't remember how much interactivity
the view widget has out of the box, in terms of panning and zooming,
but the line the demo drew was in the middle.

Or you can just open the QGraphicsView in a new window, and not bother
with free_layout / NestedSplitter integration at this point.

Cheers -Terry

> turtle_run 0 0 160 0
> turtle_run 160 0 160.0 80.0
> turtle_run 160.0 80.0 200.0 80.0
> turtle_run 200.0 80.0 200.0 100.0
> 
> But nothing shows. How do I access the QGraphicsView returned by 
> TurtleProvider.ns_provide?
> 
> def ns_provide(self, id_): 
> > if id_ == "__turtle_scene": 
> > self.scene = QtWidgets.QGraphicsScene() 
> > w = QtWidgets.QGraphicsView() 
> > w.setScene(self.scene) 
> > return w 
> > return None 
> >
> 
> Without it, I don't see how to do view.show().
> 
> 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: Oddball formats

[Terry Brown]

On Fri, 10 Aug 2018 08:49:25 -0700 (PDT)
Rob  wrote:

> Perhaps this has been covered before, but I haven't been able to find 
> relevant information in the docs or here on the forum (maybe not
> asking the right questions). Anyway, I sometimes will create and edit
> plain text data files using a defined syntax for data and delimiters.
> These formats are pretty obscure and likely of not enough interest
> for the Leo developers to create custom importers or syntax coloring
> files. Is there a relatively simple way to define the structures in
> @settings or a by-file directive? A few notable examples (there are
> others):
> 
> GIFT  (a plain text format
> to create quiz questions to import into Moodle, an LMS)
> ChordPro 
>  
> (a plain text music/lyric/tabs format)
> M3U  (music playlist)
> Currently, I just use the @language plain directive, which sort of
> works, but isn't ideal. Ideas?
> 
> Rob...

There's a mechanism for defining @auto-oddball @ readers and
writers.  It *should* be in the docs.  Can't find it there, but see

leo/plugins/importers/howto.txt

I assume that code's still working.  I use a script for importing
reveal.js flavored markdown, where blank lines indicate outline level,
but it just runs on an @edit node and builds a @clean node from its
content.

Cheers -Terry

-- 
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: Top level clones, uni-clone creation, and why not?

[Terry Brown]

On Thu, 9 Aug 2018 21:59:47 -0500
"Edward K. Ream"  wrote:

> On Thu, Aug 9, 2018 at 6:46 PM, Terry Brown 
> wrote:
> 
>File
> "/mnt/usr1/tnb_data/Package/leo/git/leo-editor/leo/core/leoFileCommands.py",
> > line 416, in getLeoOutlineFromClipboardRetainingClones
> > assert c.hiddenRootNode not in v.parents,
> > g.objToString(v.parents)
> 
> Rev 68e95a7cb in devel removes this assert and another just like it.
> 
> I don't remember why I thought these asserts were necessary or valid.
> 
> paste-retaining-clones now works as expected.
> 
> Edward

Sounds good - I'd point out that, before it was fixed :-), this was a
good test case for creating uni-clones, which I think we both agree
shouldn't exist?  Not sure if you want to leverage this to see how they
do, in fact, exist.

Cheers -Terry

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

Top level clones, uni-clone creation, and why not?

[Terry Brown]

I wanted to create an outline that looks like this:

O
A
  B
  C
D
  E
  A
B
C

where A is a clone.  So when I Shift-Control-C copied A and then tried
Outline -> Paste as Clone with E selected, I got:

   File 
"/mnt/usr1/tnb_data/Package/leo/git/leo-editor/leo/core/leoFileCommands.py", 
line 416, in getLeoOutlineFromClipboardRetainingClones
assert c.hiddenRootNode not in v.parents, g.objToString(v.parents)

Ended up with an outline like this:

O
A
  B
  C
D
  E

(i.e. as it was before failed attempt to paste as clone) *but*
expanding / contracting A revealed it to be a uni-clone.

So that's a bug report - the why not bit is if I instead create this
outline:

O
  A
B
C
D
  E
  A
B
C

where A is a clone, all works as expected, *and* I can promote the
first reference to A back to the top level, getting they layout I was
originally aiming for, even thought that seemed to be illegal.

(current devel, using HOME=/tmp for default settings)

Cheers -Terry

-- 
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 prototype of fast Qt tree drawing

[Terry Brown]

On Thu, 9 Aug 2018 12:19:45 -0500
"Edward K. Ream"  wrote:

> > Not quite sure what you mean.  The free_layout / NestedSplitter
> > machinery (which I'd like to replace with the QDock layout scheme)
> > should be able to host any Qt Widget.  But it doesn't *provide*
> > *any*, graphics pane or anything else.
> > 
> I meant that no graphics pane is shown in the "open window" list, nor
> in the list shown by the "Action" button when adding a pane.

Right, that's what it sounded like you meant, but nothing on that list
comes from the free_layout / NestedSplitter machinery, which is just a
pane manager.  So "graphics pane" isn't really a thing that could be
there.  But for the sake of completeness, here's a turtle:

from leo.core.leoQt import QtWidgets

class TurtleProvider:
def __init__(self, c):
self.c = c
c._turtle = self
def ns_provides(self):
return [("Graphics scene turtle", "__turtle_scene")]
def ns_provide(self, id_):
if id_ == "__turtle_scene":
self.scene = QtWidgets.QGraphicsScene()
w = QtWidgets.QGraphicsView()
w.setScene(self.scene)
return w
return None
def ns_provider_id(self):
return "__turtle_provider"

c.free_layout.get_top_splitter().register_provider(TurtleProvider(c))

(open a Turtle pane, then run this)

def turtle_run(scene, x, y, w, h):
scene.addLine(x, y, x+w, y+h)
if w > 20 or h > 20:
turtle_run(scene, x+w, y+h, h/2, w/2)

turtle_run(c._turtle.scene, 0, 0, 160, 0)

Cheers -Terry

-- 
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 prototype of fast Qt tree drawing

[Terry Brown]

On Thu, 9 Aug 2018 11:01:17 -0500
"Edward K. Ream"  wrote:

> Another quick experiment shows that Terry's Easter Egg interface does
> not, at present, support any graphics pane.

Not quite sure what you mean.  The free_layout / NestedSplitter
machinery (which I'd like to replace with the QDock layout scheme)
should be able to host any Qt Widget.  But it doesn't *provide* *any*,
graphics pane or anything else.

The graphcanvas.py plugin uses a QGraphicsScene, and co-exists fine
with the free_layout / NestedSplitter machinery.

Cheers -Terry

-- 
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: About unit testing Leo

[Terry Brown]

On Wed, 8 Aug 2018 01:15:04 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote:
> 
> There may be existing personal plugins that would break if plugins
> were 
> > loaded after the outline was fully loaded, but then again it's
> > possible to devise code that breaks in response to any change in
> > Leo, it's impossible to avoid (particularly with no bright line
> > between API and internals) - it's certainly happened to me often
> > enough.
> 
> True enough. 
> 
> I don't think we should say plugin loading time shouldn't be changed
> to 
> > reduce complexity, although that doesn't mean making such a change
> > is any kind or priority or that it even needs to happen. 
> 
> Why should we devs want to change to code that has worked for
> decades. Where is the payoff?  
> 
> leoPlugins.py is relatively simple. It implicitly defines how Leo
> loads plugins.  Has anyone complained?  Imo, this discussion is just
> a distraction.  We devs have (or should have) much better things to
> do.
> 
> If however there's a major complexity reduction gain to be had, I
> don't 
> > really see a downside, *because* I can't think of a single outline 
> > manipulation that a plugin couldn't perform *after* the initial
> > outline load.  Given that plugins acting after initial load can
> > change the outline in anyway they want, I can't see how there can
> > be a manipulation that requires plugins to load early in the
> > process. 
> 
> There is a huge downside...

I see plugin load time and settings processing as separate issues, so
not really sure how these two relate...

> QQQ
> EKR: How do you propose to pre-compile these settings?
> 
> Vitalije: There are quite a lot different possibilities. Last year I
> showed in a script how it is possible to take all settings from
> c.config and put them in sqlite data base in memory and retrieve any
> setting from this data base.
> QQQ
> 
> In the What's Important 
> <https://groups.google.com/forum/#!topic/leo-editor/XhhpF1K5tG4>
> thread I said that eliminating caching was the highlight of this
> year's work.
> 
> Alas, saving settings (no matter where), is a form of caching!  This
> is a fatal flaw, because there is no guarantee that the *present*
> settings files are in the cache. For example, the cache won't contain
> leoSettings.leo when git pull changes it, and in other situations.
> 
> Leo will *always* need the complex code needed to merge settings
> from .leo files *outside *any cache.  Unlike marked/expanded bits,
> settings can't just be "blown away".
> 
> In short, pre-computing settings is just wrong. Code simplicity *must
> not *wag the dog.
> 
> Edward

Cheers -Terry

-- 
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: edit-pane-csv separator

[Terry Brown]

On Tue, 7 Aug 2018 04:27:10 -0700 (PDT)
Josef  wrote:

> Perhaps it is best/easiest not to touch the cell content at all, and
> leave such alignment things to a separate command? Otherwise you may
> end up having to remember the alignment strategy for each file.

Right, the alignment stuff I'm not going to deal with.  But I'm pleased
with the enhancements I've just pushed to devel.  Whereas before you
could just edit comma separated data, now you can use any separator,
*and* you can add a line start / line end string.  So for a LaTeX table
you can use ' & ' () as the separator, and
' \\' () as the line ending.

Use \t to represent tabs.

A behind the scenes complication is that I want to keep using Python's
csv lib. to parse the data, and that only allows single character
separators.  I get around that by replacing the user visible separator,
which may be multi-character, with a single character that doesn't
occur in the text - have to search for that.

I want to keep using the lib. to support CSV like

count, description
7, otters
12, "rats, mice"

although I'm not sure that part's working at the moment.

Anyway, Leo is even better at editing tables now, thanks Josef :)

Cheers -Terry

-- 
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: About unit testing Leo

[Terry Brown]

On Tue, 7 Aug 2018 04:58:43 -0500
"Edward K. Ream"  wrote:

> On Mon, Aug 6, 2018 at 9:34 PM, Terry Brown 
> wrote:
> 
> I don't think we should say plugin loading time shouldn't be changed
> to
> > reduce complexity, although that doesn't mean making such a change
> > is any kind or priority or that it even needs to happen.
> >
> 
> A good summary.  Let's see the proposal/code in more detail.
> 
> Perhaps we can all agree on another principle.  Proposals for big
> changes can only be fully evaluated in the context of working code.
> This places the risk on the shoulders of whoever is advocating for
> the proposal, as it should be, imo.
> 
> Edward

I'm not sure if proposal is the right word for a completed solution.
I think the purpose of proposal and discussion is to gauge the
possibility of acceptance and also to throw up pitfalls the proposer
may not have considered.  But after that, sure, a project's advocate
should be responsible for the work and demonstrating the solution.

Cheers -Terry

-- 
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: edit-pane-csv separator

[Terry Brown]

On Mon, 6 Aug 2018 05:46:55 -0700 (PDT)
Josef  wrote:

> Is there a way to set the CSV separator?

I've made a start on this in the csv_delim branch.

It's not finished, because I'm trying to cover the LaTeX table case:

1 & 2 & 3 \\
a & b & c \\

My initial thought was to let the delimiter be a regex, &| in the
above case, but then what do you use to put the delimiters back in, &
or \\?  We know it's & except at the end of the line, but that's LaTeX
specific.

Also allows delimiters like [,;], i.e. , or ; - but again, which do you
use to reconstruct the text?

I think perhaps regex is a bad idea, and I should just extend
edit-pane-csv to allow any set string as a delimiter, and right
edit-pane-latex-table as a special case.

But not tonight.

Cheers -Terry

-- 
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: Installation on MacOS (10.10)

[Terry Brown]

On Mon, 6 Aug 2018 19:16:58 -0700 (PDT)
matelot  wrote:

> nobody runs Leo on Mac, really ?

People do, I think Brian's one of them.

Brian's suggestion was the first step to answering the question.  You
appear to have PyQt installed, but it fails to import.  So entering

python

and then

from PyQt5 import QtCore

in the same command line environment you're running Leo in would be
very informative.

For example just now I got:

leo-editor:0> python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5 import QtCore
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named PyQt5

because I only have PyQt5 installed for python3

I notice you list:

pyqt  5.9.2py36h62a_0anaconda
PyQt5 5.11.2

which makes it seem like there might be two versions installed, not
necessarily an issues, but again, `from PyQt5 import QtCore` would be
really interesting.

An aside, when did GCC hit version 7?  Yikes :-}

Cheers -Terry

-- 
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: About unit testing Leo

[Terry Brown]

On Mon, 6 Aug 2018 07:11:49 -0500
"Edward K. Ream"  wrote:

> On Fri, Aug 3, 2018 at 10:56 AM, vitalije  wrote:
> 
> Plugins can affect the load process.
> >>
> >> Yes, I know they can. But do they do this?
> 
> How should I know?  People are free to create their own private
> plugins for special purposes. In particular, plugins might want to
> monkey-patch Leo.

There may be existing personal plugins that would break if plugins were
loaded after the outline was fully loaded, but then again it's possible
to devise code that breaks in response to any change in Leo, it's
impossible to avoid (particularly with no bright line between API and
internals) - it's certainly happened to me often enough.

I don't think we should say plugin loading time shouldn't be changed to
reduce complexity, although that doesn't mean making such a change is
any kind or priority or that it even needs to happen.

If however there's a major complexity reduction gain to be had, I don't
really see a downside, *because* I can't think of a single outline
manipulation that a plugin couldn't perform *after* the initial outline
load.  Given that plugins acting after initial load can change the
outline in anyway they want, I can't see how there can be a
manipulation that requires plugins to load early in the process.

grep -C4 -ri before-create-leo-frame *

Suggests that before-create-leo-frame is never used in the known
code base, doesn't tell us about plugins monkey patching Leo, but
doesn't throw up any examples of needing to act before outline load
either.

Cheers -Terry

-- 
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: Update re: new model

[Terry Brown]

On Mon, 6 Aug 2018 14:48:18 -0500
"Edward K. Ream"  wrote:

> > AttributeError.  Basically it comes down to requiring, or not
> > requiring, the user to do
> > if c.gui:
> >   c.gui.endEditing()
> > (or `c.gui and c.gui.endEditing()`)
> > 
> That's a lot of work, a lot of infrastructure, a lot of constraints
> and extra mental load.  Putting one or more guards in  c.endEditing()
> avoids all that bother.

Another way to avoid the surprise of finding GUI involvement in a write
string to file operation would be to make changes to p.h immediate,
like changes to p.b.  So p.h changes as you type in the headline
line-edit, then endEditing() wouldn't be needed.

Cheers -Terry

-- 
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: Update re: new model

[Terry Brown]

On Mon, Aug 6, 2018 at 9:09 AM Edward K. Ream  wrote:
>
> On Saturday, August 4, 2018 at 2:39:26 PM UTC-5, vitalije wrote:
>
> > initialization code should be kept free and clean of any gui calls.
> Leo's guiding architectural principle is: There shall be no global 
> architectural dependencies.

> Scripts, plugins and Leo itself should be able to call c.endEditing() 
> anytime, anywhere.  Period.  Even if the call does not actually make a lot of 
> sense, c.endEditing should recover gracefully from such "misguided" calls.

I think there are a couple of subtleties here.  (1) try and find
another app. that recognizes (app.) global key commands while editing
in a line edit widget.  I think Leo's behavior in this respect is very
unusual.  E.g. in any app. try editing the find string (Ctrl-F) and
see if Ctrl-S initiates a save when you're in the find line edit
widget.  Usual behavior is that only Ctrl-A/C/X/V/Z work in line edit
widgets.  But, it's really cool being able to type "tss;;" (my
abbreviation for time-stamp-short) in a headline widget and get
201808. It's only because Leo actually allows invoking Save while
editing a line edit widget that c.endEditing() is needed.

(2) I think is a design issue.  It's counter-intuitive that writing a
string to a file should be impacted by GUI state.  Leo doesn't have a
GUI free layer.  If it did things might be broken up differently:
  c.outline.
  c.gui.

Then the debate would be whether c.gui should just be None or absent
in the absence of a gui, so
c.gui.endEditing() would raise AttributeError None has no attribute
endEditing, or whether c.gui, when there is no gui, should
be some clever object that (a) evaluates to None, (b) is callable,
returning None, and (c) returns itself for any attribute access, so
that
c.gui.tree.scrollUp() would silently do nothing instead of raising the
AttributeError.  Basically it comes down to requiring, or not
requiring, the user to do
if c.gui:
  c.gui.endEditing()
(or `c.gui and c.gui.endEditing()`)

Finally I think the idea that Save (or whatever) should capture the
text of a line entry currently being edited is a bit of a toss up.  If
you're taking notes in an outliner kind of way, I guess it makes
sense.  There might be alternate key-handler patterns that avoid the
issue, although there's still the case of background save events etc.

Cheers -Terry

-- 
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: Update re: new model

[Terry Brown]

On Sat, 4 Aug 2018 10:39:03 -0500
"Edward K. Ream"  wrote:

> ModuleNotFoundError: No module named 'leo.core.leoDataModel'
> 
> What should I do?

Is it this, from an earlier post?

"Note, anyone who wants to try this branch, the code needs the latest
version of leoDataModel.py file in leo/core/ folder. This file can be
obtained from its repository."

(https://github.com/leo-editor/new-leo-model)

Cheers -Terry

> 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: Update re: new model

[Terry Brown]

Outline -> Insert/Delete Icons -> Insert Icon
just places persistent icons with no particularly meaning to any
plugin, even though I was using icons from the todo plugin.

I think you might see the coloring of the "top" node issue if you
experiment with an outline with a really small number of nodes (3-4),
it actually applies to the top N nodes that exist when the outline's
loaded.

Font's kind of too big now... I remember a thread from years ago where
it seems that Qt doesn't really have a consistent cross platform /
cross version way of controlling font size, seeing it interacts with
screen DPI etc.

Cheers -Terry


On Fri, Aug 3, 2018 at 2:31 PM vitalije  wrote:
>
> How do you add those icons? When I click in any icon in the Task pane, it 
> always replaces previous icon with the new one.
>
> I see that icons are smaller than in old tree.
>
> Rev 9d7adae1c now respects setting `@int icon-height` when drawing icons.
>
> Vitalije
>
> --
> 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.

-- 
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: Update re: new model

[Terry Brown]

Works better. Attached shows a couple of issues - top node background
is a different color, and adding icons shrinks icons vertically, at
least the first time you add one.

Must say I'm surprised by the "draw the tree yourself" approach, but
will see how it pans out.

Cheers -Terry
On Fri, Aug 3, 2018 at 1:00 PM vitalije  wrote:
>
> @Terry, please try 5ee7b406. When running without theme and without 
> myLeoSettings.leo it couldn't find icons for the NewTreeWidget. Now some 
> defaults are set.
>
> Vitalije
>
> --
> 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.

-- 
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: About unit testing Leo

[Terry Brown]

Re gui layers etc., I've mentioned it before, but I wonder how using
something like
https://pythonhosted.org/blinker/
would work, performance wise.

Imagine being able to say:

body_change = signal('body-change')
...
body_change.send('reformat', gnx=gnx, body=new_body)

and not needing to know / care about which body-editors /
body-renderers / storage backends / network listeners hear or don't
hear.

Cheers -Terry

-- 
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: Update re: new model

[Terry Brown]

Just FYI the tree did not render for me.
Leo 5.7.4 devel, build 20180607085129, Thu Jun  7 08:51:29 CDT 2018
Git repo info: branch = ltm-leo, commit = eb3b09169816
Python 3.6.6, PyQt version 5.6.2
Windows 10 AMD64 (build 10.0.14393) SP0
isPython3: True

probing with g.log(p.h) suggested node creation was working etc.  With HOME
set to /tmp to avoid modified settings, tree was a dark blue rectangle in
regular looking Leo UI

also loading an existing file, even with --no-plugins, crashed.

Cheers -Terry

On Fri, Aug 3, 2018 at 8:08 AM vitalije  wrote:

> Revision eb3b09169
> 
> added support for visual declutter in NewTreeWidget. It also supports
> styling via themes qt style sheet like Leo tree currently does.
>
> All unit tests pass.
>
> I am going to use this code in the next days to see if there are some
> remaining bugs. AFAIK there is only code cleaning and documenting that
> remains to be done. These last fixes introduced quite a lot of new code
> (parsing qt style sheet, de-cluttering nodes...).
>
> This branch is still experimental. Don't use it yet for real work.
>
> Note, anyone who wants to try this branch, the code needs the latest
> version of leoDataModel.py file in leo/core/ folder. This file can be
> obtained from its repository 
> .
>
> Vitalije
>
> --
> 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.
>

-- 
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: Update re: new model

[Terry Brown]

re style sheet, I think almost all styling has worked by applying the full
stylesheet once to the top level window widget, from where it's inherited
by all widgets that are descendants of that widget.  I know there's a
performance penalty for applying a large stylesheet frequently, not sure
what it's like for smaller stylesheets, but in general I guess I'm
surprised it doesn't "just work" applying the stylesheet to some high level
container object.

Unless perhaps you're talking about the way styles are mapped from the
stylesheet, e.g. they're currently targeting a QTreeThingy and your code
uses a QTreeWhatsit.  If that's the case it would seem simplest to edit the
stylesheets as needed, to me.

Cheers -Terry


On Wed, Aug 1, 2018 at 9:20 AM vitalije  wrote:

>
>
>> A small point; I suggest not calling the current code 'leo legacy...'.
>> There is a presumption there that is unwarranted, I think.
>>
>>
> Sorry about that and thanks for the hint. English is not my first
> language.  What would be correct way to label it "master branch Leo"?
>
> The latest update: today I started work on making NewTreeWidget aware of
> qt style sheet. So far I have made it respect the theme I am using
> currently (Breeze dark I think). Have to go now, but there are still some
> work to take colors from style sheet.
>
> Vitalije
>
> --
> 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.
>

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