Re: Hosted Leo ?

[Brian Theado]

There is a really cool service at https://repl.it that theoretically would
make it easy to spin up demo instances of leo with gui=browser. However, it
doesn't work because even with gui=browser, Leo requires loading the PyQt
module:

leoQt.py: can not fully import PyQt5.
Traceback (most recent call last):

  File "/home/runner/.local/lib/python3.6/site-packages/leo/core/leoQt.py",
line 55, in 
from PyQt5 import QtCore

ImportError: libgthread-2.0.so.0: cannot open shared object file: No such
file or directory

Traceback (most recent call last):
  File "main.py", line 5, in 
import leo.core.runLeo
  File
"/home/runner/.local/lib/python3.6/site-packages/leo/core/runLeo.py", line
27, in 
leoGlobals.app = leoApp.LeoApp()
  File
"/home/runner/.local/lib/python3.6/site-packages/leo/core/leoApp.py", line
336, in __init__
import leo.core.leoFrame as leoFrame
  File
"/home/runner/.local/lib/python3.6/site-packages/leo/core/leoFrame.py",
line 13, in 
import leo.core.leoColorizer as leoColorizer
  File
"/home/runner/.local/lib/python3.6/site-packages/leo/core/leoColorizer.py",
line 17, in 
from leo.core.leoQt import Qsci, QtGui, QtWidgets
  File "/home/runner/.local/lib/python3.6/site-packages/leo/core/leoQt.py",
line 88, in 
qt_version = QtCore.QT_VERSION_STR
NameError: name 'QtCore' is not defined


You can see my attempt at https://repl.it/@BrianTheado/leo-editor

I'm not sure what the install story is for LeoVue, but that one might also
be feasible as repl.it supports many languages (https://repl.it/languages)

One nice thing about repl.it is that it takes the effort of just one person
to get it to work and then everyone else can fork their own instance of the
results. I don't plan to be that person, I just wanted to share the info in
case someone else was inspired to see what it takes to reduce Leo's
dependencies.

For the gui=browser use case, repl.it has the nice feature of detecting
when the process listens on a TCP port and it automatically generates a
public url for that port.

Just last week repl.it gained the feature of being able to run GUI programs
(via VNC in the browser). Here it detects when the program tries to launch
a window and automatically creates the VNC connection for it. Alas, Leo
will run into the same libgthread error as in the above stack trace (I
think their underlying linux container doesn't have the libglib2.0-0
package). So for Leo it is not feasible.

But you can see how it works with my own outliner program (from years
ago...long since unmaintained) at https://repl.it/@BrianTheado/tkoutline. I
copied the self-contained executable version to my repl and it ran
successfully. No QT obstacles in the way for it :-).

Brian


On Sat, Mar 23, 2019 at 6:20 PM Edward K. Ream  wrote:

> On Sat, Mar 23, 2019 at 2:57 PM matelot  wrote:
>
> ok, so there's no hosted solution, where one can simply upload .leo and
>> share it just read-only
>>
>
> All contributions gratefully accepted ;-)
>
> 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: Challenges with clones and multiple files

[Edward K. Ream]

On Wednesday, March 27, 2019 at 9:02:20 AM UTC-5, Arjan wrote:
 

> My notes are organized in various sections -- but often I have items that 
> belong to multiple sections, so I'd place them in both using clones.
>
... 

> Now with over a dozen top-level sections and many more subsections and 
> subsubsections for each, switching between different sections becomes 
> unwieldy.
>

Imo, the best way to deal with this problem is to *create organizer nodes 
for your projects and sub-projects*.  I do this all the time.  *There is no 
limit to Leo's organizational abilities,* as I shall now attempt to explain.

*The solution to your clone problems is to use more clones*.  No 
kidding.

Here is an example taken from the recent pygments work. You should be able 
to adapt it to any organizational task whatever.  Here are the big ideas:

*Organizer nodes create views of your data*

For large projects, you definitely should create an organizer node any time 
you are going to be spending more than a few minutes on a task.  For the 
pygments project, the *outer organizer node* is:

Headline: = #0568: pygments (I use = so it stands out visually).

Body:  My to-do list and links to #568.

*Use inner organizer nodes to further organize your work*

The inner organizers for my pygments project have these headlines:

- Color settings
- Font settings
- Reload-settings
- trace-coloring
- @language directives

The body text of each inner organizer contains notes to myself, if needed.  
Its children are clones of all nodes relating to the task.

*Don't be afraid of "redundant" clones*

This is something I haven't ever explained before. It's a really important 
idea, and it's why clone problems can be solved by using more clones.

Let me try to explain.  Within a *programming* sub-project I often want to 
focus on a class.  But within that class, I further want to focus on 
organizer nodes of the class, or individual methods of that class.

*In theory*, just cloning the class gives access to all the methods (and 
organizer nodes) *within *that class.  Why?  Because clones contain all 
their children.

So creating clones (focusing on the clones) could be called redundant.  In 
practice, though, these "redundant" clones are extremely useful.  The allow 
all (and only!) the relevant data to appear at the top level of the 
organizer.

*Promote & demote save time*

While working on a sub-project, I'll often promote children so they become 
siblings of the organizer node.  So everything is available at the top 
level.

For example, when working on the - @language directives task, I 
promoted its children so the last top-level nodes of the outline were:

- @language directives
pyg_c.at_language_callback
pyg_c.get_lexer
pyg_c.patch_lexer

This allowed me to move between nodes *quickly and easily*, without 
expanding/contracting nodes!

When I finished this task, I demoted the children and then move the task so 
it was itself a child of the top-level organizer node.  Do you see?

Similarly, the clone-find-all-flattened command creates "redundant" 
top-level nodes.  You could just use the clone-find-all command instead, 
but I find cff almost always to be more useful.

*Two levels of organizer nodes should suffice*

I have never need more levels, even for large projects such as creating a 
new gui for Leo.  Three levels would likely suffice for truly stupendous 
projects.

*Organizer nodes are valuable, but not precious*

Ultimately, they are temporary.  I make copies of data that should be 
retained indefinitely.  For example, I'll move cool new scripts to 
scripts.leo, and documentation to LeoDocs.leo.

*Summary*

Creating lots of clones can create organizational problems. The solution to 
those problems is to create organizer node containing *more *clones.

Don't be afraid of creating "redundant" clones.  Promoting nodes reduces 
the need to expand organizer nodes.  Demote nodes once you are finished 
with a task.

Two levels of organizer nodes should suffice for even large, complex 
tasks.  Three levels should suffice for truly huge tasks.

Organizer nodes are valuable, but not redundant.  Don't use them to save 
permanent data.  Copy the data instead.

To make all this work, you must be adept and comfortable with clones and 
promoting and demoting nodes.  In particular, you must know when deleting a 
clone will actually delete data.  This will quickly become second nature, 
but *only if you give clones a chance.*

Edward, the clone guru.

-- 
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: Challenges with clones and multiple files

[Chris George]

A couple of things to try:

Backlinks.
Tags.

They could, of course, just add to the problem but they both provide
alternative methods of connecting nodes that are both easier to
navigate than search/nav.

HTH,

Chris

On Wed, Mar 27, 2019 at 7:02 AM Arjan  wrote:
>
> I've been using Leo for quite a while now, and there's several things I like 
> about it. But I've come to realize the main reason I initially wanted to use 
> Leo, clones, is not really working for my use case. I mainly use Leo as a 
> Personal Information Manager. My notes are organized in various sections -- 
> but often I have items that belong to multiple sections, so I'd place them in 
> both using clones. For example: a section with notes on Desktop software I 
> use might have a subsection with Linux examples, but many of those are also 
> relevant for under Webdevelopment - LAMP stack, so I'd put them there as well.
>
> Now with over a dozen top-level sections and many more subsections and 
> subsubsections for each, switching between different sections becomes 
> unwieldy. The nav or search functionality works fine when you initially need 
> to find the (sub)section you want to work in, but when you're switching 
> between different sections/contexts a lot, the overhead is way too large 
> (number of operations/keystrokes as well as mentally). Switching between open 
> tabs works much better in this regard.
>
> So perhaps I should just make each top-level section a separate Leo file and 
> switch between those? But as far as I can tell, there is no good way to share 
> nodes between files (and keep them in sync, including their subtrees if 
> applicable).
>
> Anyone organizing data like this, or have suggestions?
>
> --
> 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.

Challenges with clones and multiple files

[Arjan]

I've been using Leo for quite a while now, and there's several things I 
like about it. But I've come to realize the main reason I initially wanted 
to use Leo, clones, is not really working for my use case. I mainly use Leo 
as a Personal Information Manager. My notes are organized in various 
sections -- but often I have items that belong to multiple sections, so I'd 
place them in both using clones. For example: a section with notes on 
Desktop software I use might have a subsection with Linux examples, but 
many of those are also relevant for under Webdevelopment - LAMP stack, so 
I'd put them there as well.

Now with over a dozen top-level sections and many more subsections and 
subsubsections for each, switching between different sections becomes 
unwieldy. The nav or search functionality works fine when you initially 
need to find the (sub)section you want to work in, but when you're 
switching between different sections/contexts a lot, the overhead is way 
too large (number of operations/keystrokes as well as mentally). Switching 
between open tabs works much better in this regard.

So perhaps I should just make each top-level section a separate Leo file 
and switch between those? But as far as I can tell, there is no good way to 
share nodes between files (and keep them in sync, including their subtrees 
if applicable).

Anyone organizing data like this, or have suggestions?

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

Completing work on syntax coloring

[Edward K. Ream]

Completing any project can be a lengthy process.  Here is a list of recent 
improvements:

*Better tracing with --trace-coloring*

When the --trace-coloring command line option is set, Leo reports the 
values of the following on startup, and when doing reload-settings and 
reload-all-settings:

@bool use-pygments
@bool use-pygments-styles
@string pygments-style-name

--trace-coloring now uses the common bjc.setTag code to report details of 
styling in bjc.setTag.  This is indeed a superb trace, showing exactly what 
tags are being recognized.

Today's work improves the traces in several ways.

*reload-settings*

Today's work allows Leo's reload-settings commands changes syntax coloring 
when these two settings change:

@bool use-pygments-styles
@string pygments-style-name

However, it would be too much work to change @bool use-pygments, so 
reload-settings warns that this can not be changed.

At present, bjc.report_changes reports the new values of the pygments 
settings only if --trace-coloring is in effect.  I think that's about 
right, but it could easily be changed.

*Simplified config code*

Leo's config code will never be easy.  I do try to simplify methods as they 
appear on the radar.

Yesterday I simplified the parsing of @font nodes in leoConfig.py, and 
greatly simplified bjc.configure_font by adding a helper.

*Summary*

Changes to settings are especially prone to extended tweaks.

I'll continue fix whatever pygments-related nits as they arise. 

Just now it seems time to move on to fixing the remaining bugs scheduled 
for Leo 5.8.1 

.

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: All pygments work is in devel

[Edward K. Ream]

On Tue, Mar 26, 2019 at 11:06 AM Josef  wrote:

> Great work Edward!
>

Glad you like it.

Leo directives are not  always being colored any more (@others, @language
> makefile)
>

I'll need more details. Everything seems to work for me.

Rev 8555f9e0 colors only known languages in @language directives.

I did a major change  to a file under an @clean node (it was almost empty
> and I copied medium size file over it externally), Leo asked to reload, but
> the content did not change until I forced Leo to re-read from disk. I have
> never seen this behaviour before.
>

I have seen something similar when switching between git branches. @clean
has its limits, and major changes are best dealt with using
refresh-from-disk.

Feel free to file an issue for this, if one does not already exist.
However, it is unlikely that anything can be done--the issue will likely be
labeled "Won't Fix".

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.