Re: Minor problems with graphcanvas.py and possible fixes for them

['Terry Brown' via leo-editor]

On Sun, 12 Mar 2017 01:06:39 -0800 (PST)
Pavel Balashov  wrote:

> If you don't mind, I would like to try and commit my changes using
> git and GitHub - it will be a new experience for me! But I don't
> know, whether I should do 2 separate pull requests or a single one
> with both fixes. How should I proceed?

It's good to make separate *commits* for handling separate issues, but
whether you create two pull requests or not probably doesn't matter.

In fact by default I would think that a pull request would be
requesting inclusion of all new commits from the fork, so for commits A
and B and pull requests x and y, y would include both A and B.

--> A --> B -->
x y

So two or more commits and one pull request is probably simplest.

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: Minor problems with graphcanvas.py and possible fixes for them

[Terry Brown]

P.s. my email's terrynbr...@gmail.com, can't work out why this email last hides 
my address. 


On March 11, 2017 7:53:30 PM CST, 'Terry Brown' via leo-editor 
<leo-editor@googlegroups.com> wrote:
>On Sat, 11 Mar 2017 12:46:32 -0800 (PST)
>Pavel Balashov <degt...@gmail.com> wrote:
>
>> Hello,
>> 
>> recently I have started to use Leo editor for outlining my university
>
>> projects and I like it a lot. Also I was really excited about one of
>> its plugins, graphcanvas.py, and its ability to automatically layout
>> nodes in the graph. I had several problems with this plugin, but was
>> able to fix them by modifing the code a bit.
>
>Hi Pavel,
>
>Thanks for this work.  I know the graphcanvas.py tries to support two
>layout libraries, one of which has received more attention than the
>other... sounds like you've rounded off some rough edges.
>
>Contribution wise there are a couple of options.  If you know about git
>and / or GitHub, or you want to learn about them, you could fork Leo on
>GitHub and make a pull request for your changes.
>
>If you don't want to go that route, you can send your modified code to
>me and I can merge it in, I've done most of the work on the
>graphcanvas.py plugin.
>
>Probably the only thing that will need a bit of review is maintaining
>compatibility with both PyQt 4.x and 5.x (as well as Python 2 and 3,
>although that's less likely to be an issue).
>
>Thanks again for the interest and the contribution.
>
>Cheers -Terry
>
>> 1) Leo crashed after choosing any type of layout
>> 
>> I have installed a pydot package (this one: 
>> https://pypi.python.org/pypi/pydot, version 1.2.3) via pip and
>> confirmend that it worked with my Python 3.5.2 installation.
>> 
>> But when I tried to apply PyDot "neato" layout, Leo crashed with the 
>> following exception:
>> 
>> Traceback (most recent call last):
>>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
>> 725, in 
>> ('neato', lambda: self.layout('neato')),
>>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
>> 798, in layout
>> x,y,width,height = map(float, G.get_bb().strip('"').split(','))
>> AttributeError: 'list' object has no attribute 'get_bb'
>> 
>> It is line 798 in the graphcanvas.py file. I have some experience
>> with debugging Python projects, so after some time I found out why
>> G.get_bb() caused Leo to crash - during execution of that line,
>> variable G is a list of Dot objects (more specifically, it contains a
>> single Dot object), so it is impossible to invoke get_bb() from it.
>> So I have modified that line:
>> 
>> # G.get_bb() -> G[0].get_bb()
>> x,y,width,height = map(float, G[0].get_bb().strip('"').split(','))
>> 
>> Also another choice forced me to change line 790 because of the same
>> reason:
>> 
>> # G.get_node() -> G[0].get_node()
>> lst = G[0].get_node(''.join(['"', i.gnx, '"']))
>> 
>> This changes fixed both problems.
>> 
>> This problem may be caused by my choice of pydot package (there are
>> several other pydot packages in PyPi).
>> 
>> 2) Leo crashed after holding Ctrl and scrolling up (zooming) in the
>> Graph pane
>> 
>> Traceback (most recent call last):
>>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
>> 209, in wheelEvent
>> scale = 1.+0.1*(event.delta() / 120)
>> AttributeError: 'QWheelEvent' object has no attribute 'delta'
>> 
>> It is line 209 in the graphcanvas.py file. After some debugging and 
>> googling I have found out, that I am using PyQt 5.5.1 and in Qt 5
>> delta() method of QWheelEvent class is depracated and replaced by
>> angleDelta() method.
>> 
>> PyQt4.8: http://doc.qt.io/qt-4.8/qwheelevent.html#delta
>> PyQt5: http://doc.qt.io/qt-5/qwheelevent.html#angleDelta
>> 
>> So I have changed this line:
>> 
>> # event.delta() -> event.angleDelta().y()
>> scale = 1. + 0.1 * (event.angleDelta().y() / 120)
>> 
>> And that fixed the zooming problem.
>> 
>> If these changes are ok, then I would like to contribute them to the 
>> project. But I have never contributed to any open source projects, so
>> if someone could guide me through this process, I would really
>> appreciate it :)
>
>-- 
>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.c

Re: Minor problems with graphcanvas.py and possible fixes for them

['Terry Brown' via leo-editor]

On Sat, 11 Mar 2017 12:46:32 -0800 (PST)
Pavel Balashov  wrote:

> Hello,
> 
> recently I have started to use Leo editor for outlining my university 
> projects and I like it a lot. Also I was really excited about one of
> its plugins, graphcanvas.py, and its ability to automatically layout
> nodes in the graph. I had several problems with this plugin, but was
> able to fix them by modifing the code a bit.

Hi Pavel,

Thanks for this work.  I know the graphcanvas.py tries to support two
layout libraries, one of which has received more attention than the
other... sounds like you've rounded off some rough edges.

Contribution wise there are a couple of options.  If you know about git
and / or GitHub, or you want to learn about them, you could fork Leo on
GitHub and make a pull request for your changes.

If you don't want to go that route, you can send your modified code to
me and I can merge it in, I've done most of the work on the
graphcanvas.py plugin.

Probably the only thing that will need a bit of review is maintaining
compatibility with both PyQt 4.x and 5.x (as well as Python 2 and 3,
although that's less likely to be an issue).

Thanks again for the interest and the contribution.

Cheers -Terry

> 1) Leo crashed after choosing any type of layout
> 
> I have installed a pydot package (this one: 
> https://pypi.python.org/pypi/pydot, version 1.2.3) via pip and
> confirmend that it worked with my Python 3.5.2 installation.
> 
> But when I tried to apply PyDot "neato" layout, Leo crashed with the 
> following exception:
> 
> Traceback (most recent call last):
>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
> 725, in 
> ('neato', lambda: self.layout('neato')),
>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
> 798, in layout
> x,y,width,height = map(float, G.get_bb().strip('"').split(','))
> AttributeError: 'list' object has no attribute 'get_bb'
> 
> It is line 798 in the graphcanvas.py file. I have some experience
> with debugging Python projects, so after some time I found out why
> G.get_bb() caused Leo to crash - during execution of that line,
> variable G is a list of Dot objects (more specifically, it contains a
> single Dot object), so it is impossible to invoke get_bb() from it.
> So I have modified that line:
> 
> # G.get_bb() -> G[0].get_bb()
> x,y,width,height = map(float, G[0].get_bb().strip('"').split(','))
> 
> Also another choice forced me to change line 790 because of the same
> reason:
> 
> # G.get_node() -> G[0].get_node()
> lst = G[0].get_node(''.join(['"', i.gnx, '"']))
> 
> This changes fixed both problems.
> 
> This problem may be caused by my choice of pydot package (there are
> several other pydot packages in PyPi).
> 
> 2) Leo crashed after holding Ctrl and scrolling up (zooming) in the
> Graph pane
> 
> Traceback (most recent call last):
>   File "/home/nodex/Software/Leo/leo/plugins/graphcanvas.py", line
> 209, in wheelEvent
> scale = 1.+0.1*(event.delta() / 120)
> AttributeError: 'QWheelEvent' object has no attribute 'delta'
> 
> It is line 209 in the graphcanvas.py file. After some debugging and 
> googling I have found out, that I am using PyQt 5.5.1 and in Qt 5
> delta() method of QWheelEvent class is depracated and replaced by
> angleDelta() method.
> 
> PyQt4.8: http://doc.qt.io/qt-4.8/qwheelevent.html#delta
> PyQt5: http://doc.qt.io/qt-5/qwheelevent.html#angleDelta
> 
> So I have changed this line:
> 
> # event.delta() -> event.angleDelta().y()
> scale = 1. + 0.1 * (event.angleDelta().y() / 120)
> 
> And that fixed the zooming problem.
> 
> If these changes are ok, then I would like to contribute them to the 
> project. But I have never contributed to any open source projects, so
> if someone could guide me through this process, I would really
> appreciate it :)

-- 
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: Proposed refactoring of @theme nodes in leoSettings.leo

[Terry Brown]

On Fri, 10 Mar 2017 02:26:41 -0800 (PST)
"Edward K. Ream"  wrote:

> Note to Terry.  You need not be concerned about this. The proposal
> does not affect existing users of themes directly, except to clarify
> the differences between themes.
> 
> If there is a problem, we could revert just leoSettings.leo. Moving
> to a new branch doesn't help because changes to leoSettings.leo
> (within Leo) persist when switching branches. As always, if there is
> a problem I will be responsible for making things right again.

Sure you have to restart Leo if you swap out leoSettings.leo, but a
branch is still a convenient container for a set of related changes,
not sure I follow the above.

> I am about to refactor Leo's the @theme trees in leoSettings.leo into
> an unchanging *base *part, and a few *overrides *for each theme.
> Themes will be defined by their overrides.

As I said much earlier in this discussion, themes can't be limited to a
single style sheet and substitutions of font sizes, colors, etc. in
that style sheet.  They must be able to include arbitrary amounts of
their own "Qt-CSS".
 
> A *copy *of each base will be included in each @theme tree. Copies
> are required because Leo does not support including one stylesheet in
> another. The intention is that base part will *never* change. 

Of "each base", or "the base"?

> *Pros*
> 
> Separating overrides from the bases will make it much clearer what
> the differences between themes are.  This is a big deal, for both
> users and devs. Moreover, If the base ever does need to change, it
> will be easier to copy the base tree to all @theme nodes than to make
> changes piecemeal to all @theme trees.  I've made such piecemeal
> changes repeatedly in recent days. It gets old quickly.

This seems to imply that all themes need to be kept in sync. and Leo
devs. are responsible for maintaining them - I don't think this pattern
is seen in other theme collections.
 
> *Cons*
> 
> The refactoring might, by mistake, change the effect of one or more
> of the themes.  But this will effect only *new* users of themes. Old
> users won't be using any of these themes--they'll be using their
> previous themes. And even old users might prefer to use the new
> themes, since their customizations can be localized.
> 
> *Summary*
> 
> The new @theme nodes will exist only to leoSettings.leo. They will
> not take effect unless a user copies an @theme node to
> myLeoSettings.leo.
> 
> The refactoring will help both devs and users, including existing
> users. The refactoring might, by mistake, change what themes do, but
> that should not cause great problems.
> 
> The new scheme will help me *today* when I create @theme Linux EKR
> dark.

If the new scheme prevents *new* themes from having their own "Qt-CSS"
code, I don't think it's a good idea.  I'm not sure it does though, it
seems a new theme could just break the rule about including a copy of
some common base?  Given that, I'm not really sure what the new scheme
changes.

One thing to watch, there's a relationship I can't remember between
themes and dynamic font size changing (Ctrl-mousewheel zooming).

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: #350: Themes are ready for serious testing

[Terry Brown]

[New email: I'm transitioning from my yahoo email to my gmail email, so
this is the address I intend to use going forward.]

These are just tangential comments:

 - I think it's bad form for themes to use @data qt-gui-user-style-sheet,
that should be solely for the use of the user.  Sure the user can paste
their stuff on the end, but shouldn't need to, themes should be more
swappable than that.  If themes want to build of the default style sheet
they can either copy the whole thing, or we need a @data
qt-gui-theme-style-sheet which is added to the default style-sheet.  Or
maybe some setting for a theme to indicate that it's entries should be
appended to the default style sheet rather than replacing it.

- Particularly in Ubunutu getting consistent theme appearance is tough,
because it depends on the user's desktop settings.  Are the using Gnome or
KDE, what desktop theme are they using, etc. etc.

Cheers -Terry

On Thu, Mar 9, 2017 at 9:40 AM, Edward K. Ream  wrote:

> On Thu, Mar 9, 2017 at 7:25 AM, lewis  wrote:
>
>> Using leo_dark theme 0,  this is the console output from the
>> 'print-style-sheet' command:
>>
>
> ​Not sure this helps, because this is not the problem theme.
>
> Anyway, the ekr_dark theme is a special case because it only sets the user
> stylesheet, ​
>
> ​@data qt-gui-user-style-sheet, not the main stylesheet, @data
> qt-gui-plugin-style-sheet.
>
> I guess the thing to do is to use the main stylesheet, like all other
> themes.  I'll do this next.
>
> BTW, rev 16e8ab1 adds a comment to all theme style sheets so we can tell
> where they came from.
>
> 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: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1

['Terry Brown' via leo-editor]

On Tue, 7 Mar 2017 15:19:20 -0800 (PST)
"Edward K. Ream"  wrote:

> Maybe we can make the css comments do the heavy lifting, as you
> suggest.  In that case, maybe not much new really is required. But it
> must be a lot easier to discover and use than at present.

I'm not suggesting using the css comment mechanism, just saying I don't
see how it's different from the @constants approach, although I haven't
seen the latter, and perhaps the latter's a bit more robust.

However, my preference would be for deprecating the comments mechanism
and just using regular Leo settings.

> Here is what I know for sure:
> 
> 1. No matter what we do, the user will have to copy more than one
> setting into myLeoSettings.leo.

True, but that can be encapsulated by copying a *single* @theme node to
the end of myLeoSettings.leo.  Any number of @settings used by the
@theme can be carried along with that node in whatever substrees it
contains.  Theme installation can be as simple as copying one node.
 
> 2. There is a distinction, brought forth more clearly in this
> discussion, between settings that affect the stylesheet and settings
> that are used by Leo's core in other ways. These latter settings must
> be copied to myLeoSettings.leo.

Seems like a nit, given above comment.
 
> 3. I am going to leave the StyleSheetManager alone, for compatibility
> with existing settings.
> 
> 4. We have got to come up with something that is obvious and
> explicit. Like an @button node. No Easter Eggs.

I don't think there's an Easter Egg issue with using Leo's @settings.
Parsing CSS comments might be and Easter Egg, if not sufficiently
obvious, but I'm not really sure why that was implemented in the first
place - only reason I can think of is editing a single body text is
sometimes more convenient than a whole lot of headlines, but given the
comment nesting pitfalls you've pointed out, I still argue for
deprecating 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: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1

['Terry Brown' via leo-editor]

On Tue, 7 Mar 2017 16:13:49 -0600
"Edward K. Ream"  wrote:

> The present (accurate) comment is the following:
> 
> In order for theme settings to take effect, you may need to disable
> > existing `@color` and `@data qt-gui-plugin-style-sheet` nodes in
> > myLeoSettings.leo. Do this by deleting them or moving them out of
> > the @settings tree.
> 
> ​This is unacceptable.  It's terribly confusing for me, and I wrote
> the settings code. Which setting takes effect?  The first one, or the
> last?

I don't see how this is in anyway specific to themes. It's always
potentially confusing to know which of Leo's @settings takes effect,
should you have more than one value defined for a particular @setting.

> Worse, how do we save/restore settings when switching themes?  It's a
> nightmare.
> 
> I see no way to switch between settings, except by using completely
> distinct @settings trees (disabling the unwanted ones).  But in that
> case, there is no way, (except by using clones) of sharing common
> settings.
> 
> Instead, isolating settings to @constants nodes looks like the
> simplest thing that could possibly work.

The previous system worked until it was broken by refactoring.

> I'm not sure I have conveyed how completely unhappy I am with the
> present scheme.  It's pissing me off, and it will surely confuse and
> terrify newbies.
> ​
> 
> > But that also seems to require iterative substitution.  When the
> > system was working, it supported both.
> 
> ​The present code will remain unchanged. New style sheets will
> require no further @-substitutions, rendering the present code moot.
> ​
> 
> > Although I disagree with your desire to have static stylesheets(*),
> > I don't think it would take any changes to the existing code to do
> > that. Just store the output from expand_css_constants() in @data
> > qt-plugin-style-sheet, or whatever it's called.
> 
> ​Out of the question.  We aren't going to change things behind the
> scenes like that.

I think this indicates either a misunderstanding of the code or a
miscommunication.  If I'm remembering correctly, expand_css_constants()
processes all the substitutions.  Storing it's output in @data
qt-plugin-style-sheet would freeze the them with the definitions
present at the time, so the entire theme's represented by a single
node, which the user could copy in to their settings.

> (*) because static stylesheets force anyone who wants to tweak a
> color or
> > font size in a theme to recompile the whole stylesheet, vs. just
> > changing a single @setting.
> 
> ​In practice, the new way will be simpler than the old.  Just change
> the @constants node and press make-style-sheet.​

The old way already supports exactly that workflow.  Just put all your
constants in a CSS comment.  I think it's much more Leonine to put all
your settings in nodes in a subtress.

> My offer to take a look at this remains, but I can't do anything while
> > you're changing things around.  Also, based on the git log message
> > experience, I think it would be really useful to have all these
> > changes isolated in a branch, so if any rolling back is needed,
> > there are interspersed unrelated commits to avoid.
> 
> ​Yes.  I'll create a themes branch next.​
> 
> ​I plan no further changes to the StyleSheetManager class
> in ​qt_gui.py. It will work exactly as before, for compatibility with
> existing style sheets (@data nodes).

I don't really see how adding a third way to define style sheets
(@constants) simplifies things.

Cheers -Terry

> All further work will likely be confined to leoSettings.leo,
> including the new @button node. I'll probably retire themes.leo and
> move it to the long-term attic. I'll also eliminate the
> open-themes-leo command.
> 
> Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1

['Terry Brown' via leo-editor]

To be honest I don't remember the motivation for supporting parsing values from 
comments in CSS.  The use of regular @settings nodes seems more Leonine to me.  
But that also seems to require iterative substitution.  When the system was 
working, it supported both.
Although I disagree with your desire to have static stylesheets(*), I don't 
think it would take any changes to the existing code to do that.  Just store 
the output from expand_css_constants() in @data qt-plugin-style-sheet, or 
whatever it's called.
(*) because static stylesheets force anyone who wants to tweak a color or font 
size in a theme to recompile the whole stylesheet, vs. just changing a single 
@setting.
My offer to take a look at this remains, but I can't do anything while you're 
changing things around.  Also, based on the git log message experience, I think 
it would be really useful to have all these changes isolated in a branch, so if 
any rolling back is needed, there are interspersed unrelated commits to avoid.
Cheers -Terry
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, March 7, 2017 2:20 PM
 Subject: Re: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1
   
On Tuesday, March 7, 2017 at 2:02:37 PM UTC-6, Edward K. Ream wrote:


An easy rule eliminates iterative replacement: the substitution must either be 
a constant or an already-defined name. So the following lines are legal:

    solarized-base03 = #002b36
    tree-bg = colarized-base03
    text-font = Verdana
    body-font = text-font


I suppose this could be confusing. These lines can define arbitrarily many 
levels of indirection, but the code that implements that indirection is no 
longer iterative.  The code that scans the lines above maintains a dict of 
name/value pairs.  A non-constant must already be in the dict.  No more loops.

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: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1

['Terry Brown' via leo-editor]

p.s. if you like I can try taking a look at it and improving the flow / docs. / 
comments to make it easier to follow - I know the theme issue was originally 
assigned to me and I didn't get to it.  Just as long as we're not working in 
opposite directions on the same code - let me know.
Cheers -Terry
  From: 'Terry Brown' via leo-editor <leo-editor@googlegroups.com>
 To: "leo-editor@googlegroups.com" <leo-editor@googlegroups.com> 
 Sent: Tuesday, March 7, 2017 1:02 PM
 Subject: Re: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1
   
I would resist removing @setting expansion from stylesheets. It's a major pain 
maintaining CSS without such a mechanism. CSS3(?, maybe 2) has variables, but 
that doesn't help with Qt-CSS.If the @setting expansion is hard to understand, 
let's blame docs., comments, and code layout, not the underlying mechanism. 
Struggling to understand an morass is sort of the way it is for code you didn't 
personally write recently, I know I feel that way quite often - let's not throw 
the baby out with the bathwater.Cheers -Terry
  From: Edward K. Ream <edream...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Tuesday, March 7, 2017 12:54 PM
 Subject: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1
  
This is a revision of this comment to #350.

Today's escapades with themes convinces me that Leo's stylesheet machinery is 
on the verge of being impossible to understand. This is not entirely Leo's 
fault. Qt gives no hint about where syntax errors in stylesheets lie.

Imo, Leo needs to dispense with substitutions in style sheets. The only 
question is when.
Yes, this will make it harder to make systematic changes to, say, fonts. But 
the present situation is intolerable. If I'm thoroughly confused, even after 
using all of Leo's clone machinery to clarify things in leoSettings and 
myLeoSettings, then what on earth is a poor newbie to do?

The good news, perhaps, is that many style-related settings can just disappear. 
 Many other settings, including syntax-coloring settings, will remain. But I 
think that appearance related settings must go.  They are way too confusing.
This proposal will not affect the make-theme button in themes.leo.  However, 
the result of running that button, namely the actual @data 
qt-gui-user-style-sheet node, will be simpler, because there won't be any 
@setting redirections. It will be clear exactly what styles and colors will be 
used.  The user can make any desired changes, free from interference from other 
settings.

Before writing this post I was thinking that I could leave this for Leo 5.6.  
But I am now considering moving to "static" style sheets for 5.5b1. The fact 
that I can not be sure of the effect of my own settings on stylesheets seems 
like the last straw.

Your comments, please.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   -- 
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: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1

['Terry Brown' via leo-editor]

I would resist removing @setting expansion from stylesheets. It's a major pain 
maintaining CSS without such a mechanism. CSS3(?, maybe 2) has variables, but 
that doesn't help with Qt-CSS.If the @setting expansion is hard to understand, 
let's blame docs., comments, and code layout, not the underlying mechanism. 
Struggling to understand an morass is sort of the way it is for code you didn't 
personally write recently, I know I feel that way quite often - let's not throw 
the baby out with the bathwater.Cheers -Terry
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, March 7, 2017 12:54 PM
 Subject: Proposal: simplify style sheets for Leo 5.6, or maybe 5.5b1
   
This is a revision of this comment to #350.

Today's escapades with themes convinces me that Leo's stylesheet machinery is 
on the verge of being impossible to understand. This is not entirely Leo's 
fault. Qt gives no hint about where syntax errors in stylesheets lie.

Imo, Leo needs to dispense with substitutions in style sheets. The only 
question is when.
Yes, this will make it harder to make systematic changes to, say, fonts. But 
the present situation is intolerable. If I'm thoroughly confused, even after 
using all of Leo's clone machinery to clarify things in leoSettings and 
myLeoSettings, then what on earth is a poor newbie to do?

The good news, perhaps, is that many style-related settings can just disappear. 
 Many other settings, including syntax-coloring settings, will remain. But I 
think that appearance related settings must go.  They are way too confusing.
This proposal will not affect the make-theme button in themes.leo.  However, 
the result of running that button, namely the actual @data 
qt-gui-user-style-sheet node, will be simpler, because there won't be any 
@setting redirections. It will be clear exactly what styles and colors will be 
used.  The user can make any desired changes, free from interference from other 
settings.

Before writing this post I was thinking that I could leave this for Leo 5.6.  
But I am now considering moving to "static" style sheets for 5.5b1. The fact 
that I can not be sure of the effect of my own settings on stylesheets seems 
like the last straw.

Your comments, please.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
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: #350: Themes are ready for serious testing

['Terry Brown' via leo-editor]

When I tried themes last night the dark themes didn't seem to be working, 
background color wise, even with color definitions. 

Also, I'd just include all settings needed by a theme in the theme node and not 
make  users copy two things. I don't think the duplication is a problem. 

Cheers -Terry

On March 7, 2017 6:06:59 AM CST, "Edward K. Ream" <edream...@gmail.com> wrote:
>On Tue, Mar 7, 2017 at 5:39 AM, Edward K. Ream <edream...@gmail.com>
>wrote:
>
>>
>> On Mon, Mar 6, 2017 at 10:01 PM, 'Terry Brown' via leo-editor <
>> leo-editor@googlegroups.com> wrote:
>>
>>>
>>> Hi Jon.  I'm using the "@solarized-" names, and they're working ok,
>I
>>> don't think that part of the theme machinery is damaged.  But note
>that
>>> those names aren't built into Leo, they have to be defined in
>>> @settings
>>
>>
>> ​I'll make a note to that effect in leoSettings.leo and themes.leo.
>>
>
>​Done at d84a87d.
>
>Note: the changes do not affect any existing stylesheet. As explained
>in
>the top-level Themes node, if you want solarized colors, you must move
>
>Themes-->About solarized colors-->Solarized color definitions
>
>into the theme's @stylesheet tree.
>
>I'll be closing #350
><https://github.com/leo-editor/leo-editor/issues/350>
>as soon as tree indicators work properly on Windows.
>
>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: #350: Themes are ready for serious testing

['Terry Brown' via leo-editor]

On Sun, 5 Mar 2017 22:28:36 -0800 (PST)
jon h  wrote:

> Hi
> 
> It's only a couple of days since I started trying to use Leo.
> Can't use it after dark until there's a dark theme working. :)
> 
> On Sunday, 5 March 2017 21:55:43 UTC+10, lewis wrote:
> >
> > The ekr_dark theme ... reloads at restart.
> > The outline and log pane retain a white background.
> 
> Same result for me.
> 
> I also tried "leo_dark theme 0", 
> and both of them persisted between restarts of Leo.
> 
> Most changes took effect as soon as I did Reload Styles.
> Qt interface changes didn't happen until Leo was restarted.
> 
> With ekr_dark, only the text pane was dark, 
> so I went back to playing with "leo_dark theme 0".
> 
> Yesterday, with dark 0, I had replaced some 
> "@solarized-" names with a #hexvalue, and they took effect.

Hi Jon.  I'm using the "@solarized-" names, and they're working ok, I
don't think that part of the theme machinery is damaged.  But note that
those names aren't built into Leo, they have to be defined in
@settings, so if you copied the @data qt-gui-plugin-style-sheet node
without copying the section of settings that defines them, they won't
work.

In my old personal settings I have them defined in their own nodes in
@settings, e.g. a node with headline

  @color solarized-yellow = #b58900

and and empty (and irrelevant) body.

According to leoSettings.leo it's also possible to define them in a
comment in the stylesheet definition, but that's only done in dark 1
and dark 2, not dark 0.

Cheers -Terry

> Today I made a simple python script to replace all of them.
> You can see the result in this screenshot (png ~250kB) :
> https://mega.nz/#!WwEjxDSK!6qxd7FxGicq37aNdzDcEfHYdzS8ONrukS1UdAP0yeC4
> 
> The log pane was properly colored, but the other tabs were not.
> As you can see, the menus were too light to read.
> 
> Anyway, it seems that the problem I had earlier
> was that "@solarized-" names do not take effect,
> but I've no idea why they don't.
> 
> A zip of the py file and the before and after leo files is attached.
> (I'm *not* suggesting anyone should make their regular theme this
> way!)
> 
> /Jon
> 
> Leo 5.4, build 20170304105326 (not in a repo)
> Python 3.6.0 in a pyenv; PyQt version 5.8.0
> Ubuntu 14.04, XFCE with an Ambiance Dark theme.

-- 
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: Well Kent, your vision for Leo is becoming clearer

['Terry Brown' via leo-editor]

Sure, SQLite isn't as heavier hitter as pg et al.  But I've seen it handle 
millions of records (although perhaps not "more than a few Gb of data" without 
too much trouble.
I guess I was thinking it would be nice to have interchangeable backends for 
any new Leo db backend, and if you were going that route you could use SQLite 
for simplicity until such time as you needed to switch to something better.  I 
wouldn't expect Kent to hit gigabytes of data very quickly, at least not in 
dev. stages.
Cheers -Terry
  From: Mike Hodson <myst...@gmail.com>
 To: leo-editor@googlegroups.com 
 Sent: Monday, March 6, 2017 1:56 PM
 Subject: Re: Well Kent, your vision for Leo is becoming clearer
   
On Mon, Mar 6, 2017 at 12:26 PM, 'Terry Brown' via leo-editor 
<leo-editor@googlegroups.com> wrote:

Hi - I wouldn't discount SQLite either, DB wise, unless you need connect to a 
*remote* server capability, but for local work it's quite capable.  And a 
proper abstraction layer should make it possible to switch out the backend.
Cheers -Terry

Hi Terry, I've got another quick "Mike's $0.02" relating to SQLite..
I've found that a local SQL Server, (My/Maria/MS/pg) is nearly "required" when 
dealing with data larger than a few gigabytes, and further, the optimizations 
in Maria/pg allow for very quick querying and joining of the data as well, 
evidenced by my hundreds-of-thousands-of-emails in KMail working properly with 
Maria and working very sporadically with sqlite. (when working for a webhosting 
company where _everything_ (tickets/alerts/daily notifications/vendor 
mails/*.*) was emailed out to _everyone_.)
However I've yet to compare with a more capable and perhaps better programmed 
project that has utilized mysql/pgsql and also has proper sqlite integration; 
from my understanding, the coding model is very different and this may be a 
reason the KDE people haven't optimized for sqlite and/or bugs exist in the 
code as nobody uses sqlite fully knowing the mysql akonadi integration "just 
works"
R1Soft CDP, the backup solution, has since version 3.0 used a SQLite database 
file as its "block storage" and every successful merge of old recovery points 
causes a full-sqlite-file-rewrite-to-disk. I am strong in my belief that if 
they used Maria or Postgres instead of SQLite, they'd have a far more 
performant product and less filesystem fragmentation with 'file per table' 
XtraDB layout in Maria, or whatever Postgres does internally to be so bloody 
efficient.
Mike
-- 
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: Well Kent, your vision for Leo is becoming clearer

['Terry Brown' via leo-editor]

Hi - I wouldn't discount SQLite either, DB wise, unless you need connect to a 
*remote* server capability, but for local work it's quite capable.  And a 
proper abstraction layer should make it possible to switch out the backend.
Cheers -Terry

  From: Kent Tenney 
 To: leo-editor  
 Sent: Monday, March 6, 2017 10:41 AM
 Subject: Re: Well Kent, your vision for Leo is becoming clearer
   
I'm not sure if my periodic outbursts qualify as 'vision' but in terms
of where my characterization of Leo might differ from the norm, it
would be my seeing Leo as a hierarchal data store rather than an
editor, the D3 reference would imply generating data
relationships viewed in the browser, I'd love to see that.

I am slowly coding away at another implementation of my obsession
with the notion of 'spatial versioning', meaning multiple versions which
exist next to, above or below, etc. rather than temporal versioning:
only before or after.

It always seems to come down to storing data, so I've been studying
Postgresql more, if the issue is data, a database makes sense. The
next thing to fret is how much Python vs. how much Postgres, and
what about json?

Enter the code master, Jim Fulton, announcing newt.db http://www.newtdb.org
which joins ZODB (persisting Python), Postgresql, and json.

I once had node level spatial versioning working for Leo, I hope to return to 
it,
in a form I can stick with.

Thanks,
Kent

On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream  wrote:

I never really understood it until I saw the Atom editor and d3 demo.

Cool stuff enabled by standard web technologies.

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+unsubscribe@ 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.


   

-- 
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: Proposed actions re: #350: themes not working as documented

['Terry Brown' via leo-editor]

The theme script you're referring to compiles a tree into a single stylesheet, 
is that correct?
I might have referred to it as a button when in fact it was just a script that 
anyone editing a theme would probably convert to a button with the 
script-button button.
It seems that using the theme compiling script should only be necessary for 
anyone editing the theme, and for users just wanting to switch between themes, 
only the other script/button you mention, that just copies the them to personal 
settings, would be necessary.  I.e. that all @theme trees contain both the tree 
source of the theme, and a pre-compiled @data qt-gui-plugin-style-sheet.
Cheers -Terry
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Friday, March 3, 2017 8:50 AM
 Subject: Proposed actions re: #350: themes not working as documented
   
I am writing this here, rather than in #350: themes not working as documented, 
so that more people will see this discussion. Anyone who wants to use themes 
will want to read the following carefully.

Background

I have download all final versions of Leo from 4.11 onward to 5.4. The only 
difference between 4.11 and all later versions is that from 5.0 onward there is 
that there is a separate themes.leo file in the leo/config folder. All 
themes.leo files contain separate theme scripts (a script, not an @button 
node), for each separate theme. Afaik, there has never been a button that 
creates themes.

>From September 2014 onward, Leo has had a StyleSheetManager class, accessed 
>via c.styleSheetManager. All theme scripts reference g.expand_css_constants, 
>but that no longer exists.  Instead, scripts should call 
>c.styleSheetManager.expand_css_constants. When that is done, theme script 
>create @data qt-gui-plugin-style-sheet node as advertised.

However, making that stylesheet active by calling:

    g.app.gui.frameFactory.masterFrame.setStyleSheet(
    c.styleSheetManager.expand_css_constants(nd.b))

does not (yet) produce the desired theme. It's probably no big deal, but the 
effect is unsettling. The appearance of themes.leo changes drastically, at 
least with my defaults.

Proposed changes

1. Replace all theme scripts in themes.leo by a single @button node at the top 
level. The user should select the desired theme tree before running the @button 
script (clicking the button). The @button script will ensure that the user has, 
in fact, selected a theme tree. It may be convenient to mark "the good parts" 
with @theme.

2. Aside: I had to change @language css to @language python in order to run the 
theme script.  No big deal, but it will be best to create an organizer node for 
the rest of the data nodes that contains nothing but @language css.  This 
reorganization may affect the theme script, but any required changes will be 
worth the cos--it's intolerable not to color text correctly.

2. A separate top-level @button script will copy theme data to 
myLeoSettings.leo.

Summary

The themes data and scripts moved from leoSettings.leo to themes.leo for Leo 
5.0 and have remained largely (completely?) unchanged ever since.

A refactoring of Leo's code broke the scripts in themes.leo ca. September, 2014.

An @button node in themes.leo will generate theme data. A separate @button node 
will copy theme data to myLeoSettings.leo.

Much of the confusion re #350 stems from out-of-date docs. I'll update the docs 
in leoSettings.leo, themes.leo and on Leo's web site once all the details 
become clear.

Comments, corrections and questions, please.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
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: Leo and abstraction

['Terry Brown' via leo-editor]

Well said.  When you think about it there are a number of features in Leo that 
allow personalized abstraction.  Organizer nodes are the simplest, but all the 
various methods for linking between distant parts of the tree are also helpful 
(backlinks, unls, bookmarks, tags, even clones ;-)
Cheers -Terry
  From: john lunzer 
 To: leo-editor  
 Sent: Friday, March 3, 2017 9:11 AM
 Subject: Leo and abstraction
   
Warning: This is a testimonial, sorry.
Lately I've been thinking about programming in general. My thoughts have 
centered on the limits of the human brain to understand computer programs. This 
was triggered by watching Inventing on Principle. It's a daunting multifaceted 
concept which I'm sure people spend their entire lives pondering.
Most recently I've been focusing on one facet, abstraction and program "units". 
I define a "unit" as a part of the program that is considered a piece onto 
itself which can be labeled and referred to as a whole. Perhaps, as a daily Leo 
user, this is easy to think about because Leo does its best to coerce 
programmers and programs into looking at programming through this lens.
Most tools do not ignore this concept all together. Most programming 
environments have some sort of "outline" window which allows you to view the 
structure of a program at a higher level. As I have experienced it this 
"outline" view is always dictated by the features of a language (ex. outline 
divided up at module, class, function levels). In addition most tools 
incorporate "code folding" to help a programmer focus on language specific 
programming units (again, ex. folding at class and function definitions). 
Leo takes this concept to its limit. Leo offers language agnostic abstraction 
at arbitrary levels. It allows a programmer to structure their program outside 
of the confines of the programming paradigms of the language they're 
programming in. Of course it still helps to use the language specific "units" 
as a guide, in fact this is what Leo does upon import to create an initial 
outline structure from programs originating outside of Leo. 
I can't ignore the freedom of arbitrary abstraction, and I've come to rely upon 
it so much that I struggle to use non-Leo environments. It is well known that 
the human brain has a limited working memory. The act of programming stretches 
working memory to it's limit. Leo provides an environment in which a program 
can seamlessly be restructured to fit within the bounds of a programmers 
individual working memory. 
I realize this is a "why" and not a "how" and that this doesn't help anyone get 
better acquainted with Leo. But, as a programmer if you've ever felt frustrated 
with the organizational constructs of the language you're working in you might 
be surprised to realize that after using Leo it wasn't the language that was 
the problem, but a lack of tools to organize your programs in a way that makes 
sense to 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 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: Abbreviation default text

['Terry Brown' via leo-editor]

You could file an enhancement request, not sure how high the priority would be. 
Currently you can use  to enter a blank value for the field, and 
 to keep the default value for the field (because 
right-arrow clears the selection range).  With your change you'd have to 
explicitly blank (backspace, I suppose) default text you didn't want to remain.
Cheers -Terry
  From: Largo84 
 To: leo-editor  
 Sent: Tuesday, February 28, 2017 1:24 PM
 Subject: Abbreviation default text
   
Here's another abbreviation question. Is there a way to populate the variable 
field with default text that remains after moving to the next field? For 
example:
foobar;;=Use <|foo|> and <|bar|> in a sentence.
When the abbreviation is expanded (executed) the text `foo` is highlighted and 
I can add new text to replace it, then hit `,,` and go the the next field and 
`bar` is selected. Is it possible to leave `foo` and `bar` in place as defaults 
without having to retype them?
If not, would this be an appropriate enhancement request?
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.
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: How to escape \n in abbreviations?

['Terry Brown' via leo-editor]

Ok, \\n should work in 9e9539d, there was special handling of \n in the code 
already that made \newcommand etc. impossible.  I think it unavoidably breaks 
theoretically possible abbreviations in people's local settings, but (a) they 
probably don't exist, and (b) better that than have the code unable to 
represent text needed for a demonstrated use case (\newcommand etc. in LaTeX).
Cheers -Terry

  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Tuesday, February 28, 2017 10:10 AM
 Subject: Re: How to escape \n in abbreviations?
   
Yes, and I also tried '\n' and "\n" to no avail.
Rob.

On Tuesday, February 28, 2017 at 10:52:58 AM UTC-5, Terry Brown wrote:
Sorry, didn't read carefully enough.  Have you tried \\n ?
Cheers -Terry
  From: Largo84 <lar...@gmail.com>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Tuesday, February 28, 2017 9:47 AM
 Subject: Re: How to escape \n in abbreviations?
  
That doesn't really answer the question. I use the `\:` syntax often to create 
new lines in abbreviations as you demonstrate. What I need is the text output 
to be `\n`. I need to somehow escape the `\n` such that when executed it 
doesn't generate a new line and strip out the `\n' string literal.
Rob

On Tuesday, February 28, 2017 at 9:05:59 AM UTC-5, Terry Brown wrote:


leo-editor/leo/config/ leoSettings.leo#@settings--> Abbreviations-->@data 
global-abbreviations

illustrates this:

# type html;; to insert template and ,, to select next <|placeholder|>
html;;=
\:
\:<|title|>
\:
\:
\:
\:
\:<|content|>
\:
\:


-- 
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+...@ 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.
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: How to escape \n in abbreviations?

['Terry Brown' via leo-editor]

Sorry, didn't read carefully enough.  Have you tried \\n ?
Cheers -Terry
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Tuesday, February 28, 2017 9:47 AM
 Subject: Re: How to escape \n in abbreviations?
   
That doesn't really answer the question. I use the `\:` syntax often to create 
new lines in abbreviations as you demonstrate. What I need is the text output 
to be `\n`. I need to somehow escape the `\n` such that when executed it 
doesn't generate a new line and strip out the `\n' string literal.
Rob

On Tuesday, February 28, 2017 at 9:05:59 AM UTC-5, Terry Brown wrote:


leo-editor/leo/config/ leoSettings.leo#@settings--> Abbreviations-->@data 
global-abbreviations

illustrates this:

# type html;; to insert template and ,, to select next <|placeholder|>
html;;=
\:
\:<|title|>
\:
\:
\:
\:
\:<|content|>
\:
\:


-- 
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: How to escape \n in abbreviations?

['Terry Brown' via leo-editor]

On Mon, 27 Feb 2017 22:45:40 -0800 (PST)
Largo84  wrote:

> Suppose I create an abbreviation for a LaTex construct such as:
> 
> newcom;;=\newcommand{\SomethingNew}{<|INSERT-TEXT|>}
> 
> When executed, the `\n` is interpreted as a Python line feed and I
> end up with:

leo-editor/leo/config/leoSettings.leo#@settings-->Abbreviations-->@data 
global-abbreviations

illustrates this:

# type html;; to insert template and ,, to select next <|placeholder|>
html;;=
\:
\:<|title|>
\:
\:
\:
\:
\:<|content|>
\:
\:

i.e. lines starting with \: are appended to the abbreviation (with a \n
between each).

Cheers -Terry

> ewcommand{...
> 
> How can I escape the `\n` so that it doesn't create a line feed, but
> the string literal value of `\n`? I looked here 
> , but didn't see
> anything helpful.
> 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: Leo 5.5 will challenge org mode

['Terry Brown' via leo-editor]

> From: Edward K. Ream > To: leo-editor 
>  > Sent: Friday, February 17, 2017 1:21 PM> 
> Subject: Leo 5.5 will challenge org mode> > In another thread I wrote:> > > 
> Perhaps [ A Brief Summary of Leo] should be rewritten in the org-mode intro 
> style, but that's for some other time.> > Actually, now is the time.> > My 
> competitive juices are flowing. The new intro will directly challenge org 
> mode. It will do this by showing, with numerous examples, why Leo is already 
> superior to org mode for scientific computation. Scientists can design there 
> own Leonine sub-outlines that represent computations and operations.
I'm pleased to hear we're back to Leo being an alternative to, rather than a 
copy of, Emacs :-) > @button, Leo's API and Leo's DOM, combined with python 
scripting, are much more convenient and powerful than org-mode.  Simplicity and 
generality are more important than a org-mode features.  Leo most definitely 
has the chops to support reproducible research, or any other buzzword one wants 
to use.> > Leo 5.5 will have an execute-script-in-common-namespace command. 
This can be added with only a few lines of code. It's needed to simulate 
pyzo/jupyter/org mode calculations.
vs-eval / vs-last / vs-pretty do this.  I added them to the inscrutable 
valuespace plugin because it already creates a common namespace (c.vs), but 
really they should be separate, seeing they're straight forward and easy to 
understand, unlike the rest of valuespace ;-)
> Leo 5.5 will also have a show-drawer command. It will pop up a window showing 
> a special 'core-drawer' uA. Saving the popup will update the uA.  No need for 
> changes to Leo's body pane.
Sort of like the attrib_edit plugin ;-)
Cheers -Terry
> Furthermore, Leo is already vastly superior to org mode for software 
> development, with features like automatic untangle (updating @ nodes), 
> automatic tangle when saving .leo files, clone-find commands, clones, etc, 
> Heh. Whenever I make this kind of list, I inevitably forget things. Like 
> @test, @suite, @button, scripting API, etc. etc.!> > So Reinhard's criticisms 
> are bearing fruit. I'll be emphasizing the problems Leo is designed to solve. 
>  These big tasks are Leo's main purpose. Sure, you can use Leo for keeping 
> track of your record collection.  Leo let's you do simple things simply.  But 
> you can also do complex things simply and flexibly. Things like designing a 
> suite of long-running experiments, documenting them, and ensuring that all 
> code is transparent to reviewers.  Or developing software like Leo itself. 
> All using Python and its libraries, not elisp and emacs-only libraries.> > 
> I'll be using mostly prose, as I have just done, combined with code 
> snippets.> > Edward> > P. S. The easy way to simulate org-mode's window, and 
> improve upon it, will be to allow Leo's body pane to contain multiple, 
> vertically aligned panes.  Like this:> > Overall body pane:> > pane 1> - 
> (separator)> pane 2> - (separator)> pane 3> ...> > Users will be able to 
> see the various panes without intervening headlines, although separators may 
> show headlines.  Only one of the panes will be active.  It is the "real" body 
> pane.  This can be done in a plugin, I suspect. It will not happen for Leo 
> 5.5, however.> > 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.

-- 
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: commands to move to next file in 'file edit list'?

['Terry Brown' via leo-editor]

I think Ctrl-PgDn, Ctrl-PgUp also work, I think most web browsers use those?
Cheers -Terry
On Thursday, February 16, 2017 at 4:49:28 PM UTC, Edward K. Ream wrote:


On Thu, Feb 16, 2017 at 5:43 AM, jkn  wrote:


If I have multiple files open in Leo, so multiple 'file tabs' at the top of the 
window, are there commands that would allow me to switch from one file to 
another?

​As discussed, Ctrl-Tab (a standard binding) does this.

If you are interested, there are also programmatic ways of switching tabs.

Edward

Thanks Edward
    now that I have been pointed at the name of the underlying commands I will 
take a look at the key bindings.

Interestingly (to me), although Ctrl-T seems somewhat of a 'standard' for 
moving tabs, I have never used it. Other editors use Shift-Right, for 
instance

    Regards
    Jon

-- 
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: Leo vs org mode

['Terry Brown' via leo-editor]

I guess I wonder which tasks can currently only be accomplished with org mode, 
and not Leo.
I thought Leo had recently acquired support for multiple source languages?  Or 
are you talking about executing, not syntax highlighting?
A good table editor would be nice, it should read/write from 
markdown/rst/latex/html.  I suspect there's been at least one iteration of such 
a thing, in the distant past. If I had an urgent need to edit tables in Leo, 
I'd probably edit them in the richtext plugin (CKEditor) and script the results 
to whatever format I wanted. 
The rest of it would be easier to evaluate in terms tasks made easier / 
possible.
In terms of user base, I think we all agree Leo has multiple potential 
audiences. Emacs users will very techy people, generally.
Cheers -Terry

  From: Edward K. Ream 
 To: leo-editor  
 Sent: Thursday, February 16, 2017 3:47 PM
 Subject: Leo vs org mode
   
A brief comparison of Leo and org mode.

Org mode has these strengths:

- Drawers: visible, pure text, easily extensible uA's.
- Agendas and tables.
- In-pane rendering of Latex and special symbols.
- Support for multiple source languages, including shell scripts, C, etc.
- Code blocks, with arguments.
- Result blocks.

Leo will have all of the above this year. Leo has its own strengths:

- Automatic tangling when saving files.
- @others, missing from org mode's noweb markup.
- Untangling: automatic update of @file nodes. Completely missing from org mode.
  In essence, all org mode files are @nosent files.
- Importers. There are importers, but apparently none for programming languages.
- Clones and especially clone-find commands.
- API: org mode does have a hacking api. It's oriented towards parsing body 
text.
- DOM: org mode simulates a DOM with filters. Org mode data is fundamentally 
text.
- Python scripting, including a python plugin architecture.

There may be more ;-)

Conclusion: It may still be true, in some limited areas, that Leo can do things 
that can even be thought in org mode.  However, that statement is no longer 
generally true, and I'll remove it from all future documentation.

All additions and corrections welcome.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
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: Leo's HOME directory

['Terry Brown' via leo-editor]

I think as a general rule with os.chdir()/os.getcwd() in Python apps. you can't 
assume its value, it's a single piece of state shared across the entire app. 
and all libraries, so really the best thing to do is not use it or rely on it.
Your result is not surprising, Leo is setting it between script calls.  
Possibly Leo is doing this intentionally in a constructive way, setting the cwd 
to the path implied by the node you're in (taking into account the location of 
the .leo file and all parent @path directives.  If you think about it a truly 
Leonine shell representation might use the tree to represent directories.
For your application I'm not sure what the best approach might be.  You could 
sandwich your shell work between calls to some get_last_cwd() / save_last_cwd() 
that stores a cwd in a uA per node or something.
Or perhaps a custom cd() function that does both get_last_cwd() and 
save_last_cwd() at once, saves having to remember to use the other functions.
Cheers -Terry

  From: john lunzer 
 To: leo-editor  
Cc: larg...@gmail.com
 Sent: Wednesday, February 15, 2017 7:58 AM
 Subject: Re: Leo's HOME directory
   
I'll use this thread because it seems relevant. I'm trying to do some 
experiments using Leo as a shell. Amongst other things I'm trying to change 
this current working directory. I have a small node script:
@language python

import os
os.chdir("..")
g.es(os.getcwd(), color="green")
Perhaps naively I expected the log to show that I keeping dropping down a 
level, as it would in a interactive python session. Unfortunately the output is 
the same each time.
Any suggestions on changing the working directory? Or suggestions on 
alternatives to keeping track of working directory in scripts.
On Thursday, April 21, 2016 at 7:20:52 PM UTC-4, Edward K. Ream wrote:
On Thu, Apr 21, 2016 at 1:44 PM, Largo84  wrote:

Sorry I don't know the whole back story on this, but why was this plugin 
disabled?

​I have no recollection of 2008 :-)
​ 
What's the alternative way to explicitly specify a different HOME directory 
than the OS default?

​According to lm.computeHomeDir, ​ ​the home directory is

    os.path.expanduser("~")

​There is a comment in Leo's code that Windows searches the HOME, HOMEPATH and 
HOMEDRIVE environment vars. Full details here. (Search for expanduser on this 
page).

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: Next-gen edit pane enabling org-mode and jupyter like experiences, and much more

['Terry Brown' via leo-editor]

Thanks for these thoughts.  It might be possible to wrap 3-5 of the new
editor panes in a vertical scrolling view such that they appear to be
an endless series... interesting thought.

Not sure if you use Windows or Unix, but for the latter the leoscreen
plugin offers quite good integration with any command line driven
environment - shell, R, SQL, Python, although that's a bit redundant :-)

Cheers -Terry

On Fri, 10 Feb 2017 12:51:34 -0800 (PST)
john lunzer  wrote:

> Terry, since you are working on Leo's next generation edit pane
> anyway I thought I'd at least throw the idea out there to see if it
> resonated with where we'd like to take Leo's body pane. Edward, I'd
> like to get your take as well as it could impact many goals coming up.
> 
> I call it "continuous edit mode"
> 
> The idea is that the body/edit pane would show node content from
> multiple nodes delineated with a special non-editable stylized
> heading + vertical divider. The nodes it would take body content from
> would be N visible nodes plus or minus the currently selected node.
> If you move your cursor (up/down arrow) past the editable text for
> one node to the content of the next node it will automatically
> highlight that node in the tree without taking focus away from the
> body. Content from other nodes could be optionally dimmed (with
> shortcutted toggle command) to retain the aspect of focus that Leo
> currently enables by viewing node body content in isolation. 
> 
> The benefits/implications of this type of body editor mode:
> 
>- Faster workflow. Switching back and forth between the body is
> not a big deal but a continuous edit pane would offer a natural
> method of moving to the next node without leaving the body editor or
> using shortcuts. Page down/up would always end at the content of the
> currently selected node without moving to the content of the next
> node then up/down arrow could be used to move to the content of the
> previous/next node. 
>- This could provide a flat view of the tree similar to what you
> see in emacs' org-mode. In essence a type of org-mode emulation,
> which could help realize a lot features Edward wants to bring from
> emacs' org-mode. The flat view in general can help give a more global
> understanding of the code.
>- A mechanism to create a Jupyter like experience where you can
> create a new "input" node which might be automatically given a node
> heading "[1] in", type the code you want in the node and and execute
> it which would create a node directly below the current node with the
> heading "[1] out" and the output of the previous command and also
> automatically create a new empty node with the heading "[2] in".
>- Building off the previous example, any type of continuous
> input/output workflow. I badly want to be able to simulate a shell
> inside Leo. This type of body editor could facilitate the writing of
> such "shell" plugins. 
>- A gentler less shocking transition to Leo for new users who are
> used to "flat" editors. Once they get used to how nodes work.
>- You could use abbreviations or custom commands in the body to
> create new nodes from the body. Say you type "My next node" by itself
> on a line in the body and then press the keys for your shortcut to
> "new-node-from-line" which would create a new node below your current
> one. The stylized heading shows up in your body editor below the
> content of the current node. You could then arrow down to switch to
> the next node, never leaving the body editor but getting the full
> benefits of a tree structured document.
>- I envision clone-find-all and clone-find-flat becoming even more 
>powerful search tools as you quickly move through the content of
> the found nodes with just page up/down and arrow up/down.
> 
> The generic aspect of such a view mode enables emulating experiences
> from other editors/environments and I believe can be exploited to
> many other user friendly gains as well.
> 

-- 
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: Warning: imp.reload hurts super and TDD

['Terry Brown' via leo-editor]

Hmm, I think I'd give this idea a -0  :-)
Working in an environment where you aren't free to install whatever you want, 
because of security concerns, it was very convenient for me to be able to run 
Leo as a side effect of the installation of other software that included both 
Python 2.7 and PyQt.  Only recently has other software which happens to include 
Python 3.x and PyQt come on line.  
But there are a lot of systems when 2.7 is still the core Python, and adding 
"manage multiple Pythons" to the install requirements for Leo adds an 
impediment for new users.  Ubuntu still uses 2.7 at 16.04 (Long Term Support) 
at least, not sure about 16.10 / 17.04, but I wouldn't be surprised if it's 
still 2.7.
At the moment I think "packages I can't use in Leo because they're 2.7 only" 
would outweigh "packages I can't use in Leo because they're 3.x only", although 
I guess that will change.
So, like I said, -0.  I think you points about pointing Leo forwards and saving 
dev. time are really good, and I guess I'm saying I don't have a strong 
opinion... :-}
Cheers -Terry

  From: john lunzer <lun...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Friday, February 10, 2017 12:16 PM
 Subject: Re: Warning: imp.reload hurts super and TDD
   
Edward, doesn't that statement just scream "something is wrong with this" to 
you?
Your time is the most precious resource you have. My advice is to do a freeze 
of Leo (and it's documentation) at version 5.5 or 5.6 as the last Python 2 
compatible version. Make this version available indefinitely. This way people 
can get most of the idea of what Leo is about and if they want to "make the 
jump" they can go from there. This is no different than what Python itself did. 
People got over it eventually. I see people on the forums still using Leo 5.2 
for goodness sake. Leo's history is so rich that Leo 5.5/5.6 will be relevant 
for years. 
One of my favorite Python based tools is xonsh. They made a decision to go with 
Python 3 early and never looked back. Nobody rolls up on the forums/git-issues 
demanding Python 2 compatibility. Anyone who knows enough to want to demand 
Python 2 compatibility knows better than to actually troll a project demanding 
such. 
Additionally, you may be able to migrate to a Python 3 only codebase and still 
support Python 2. Almar Klein, was able to accomplish this with a custom 
translator he wrote a blog post about. 
http://www.almarklein.org/legacy_python.html 
Honestly, give some thought to how much time you will save and how much you can 
simplify the code base by going to a Python 3 only implementation of Python. 
This could be as important a turning point for Leo as any, and would certainly 
align Leo in a completely forward facing direction, which I know is where you'd 
like to take Leo.

On Thursday, February 9, 2017 at 2:29:35 PM UTC-5, Edward K. Ream wrote:
On Thu, Feb 9, 2017 at 9:39 AM, 'Terry Brown' via leo-editor 
<leo-e...@googlegroups.com> wrote:

Ha, snap - I just ran into the the same issue with VR-4. 

​This is one of the best adverts for Python 3 that I know.  Alas, we are stuck, 
for now, with Python 2.

Funny how nobody complains that pyzo is Python 3 only.

If people only knew how much time I spent futzing with 2/3 issues...

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: Warning: imp.reload hurts super and TDD

['Terry Brown' via leo-editor]

Ha, snap - I just ran into the the same issue with VR-4.  Initially using 
reload for faster development, then in the way the core module loads the view 
modules.  imp.load_module also acts as a reload.  Using reload for dev. aside, 
my problem was descending the markdown view module from the html view module.  
When the main module used imp.load_module to load the html module, super broke. 
 And it's not really super, it's any attempt to call the base class, even 
directly.
I wonder if it could be avoided by
from amodule import AClass
class MyClass(AClass):...
instead of
import amodule
class MyClass(amodule.AClass):...
?  maybe not, depends how AClass refers to its module.
Anyway, I gave up on reload for dev., and used exec "import amodule" where 
needed for dynamic imports.
Cheers -Terry

  From: Edward K. Ream 
 To: leo-editor  
 Sent: Thursday, February 9, 2017 8:37 AM
 Subject: Re: Warning: imp.reload hurts super and TDD
   
On Thursday, February 9, 2017 at 8:29:56 AM UTC-6, Edward K. Ream wrote:

> Leo's TDD design involves imp.reload.  Alas, imp.reload affects super 
> calls!...
> This kind of pattern verges on the intolerable. The python 2 part is a 
> revolting mess.

In fairness to python 2, the problems only arise when using imp.reload. When 
imp.reload isn't involved, this works for Python 2 or 3:

    super(ChildClass, self).__init__(args to ctor)

And if using only Python 3:

    super().__init__(args to ctor)

However, this is scant comfort. imp.reload is so useful during development.

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: using @first and not getting expected results

['Terry Brown' via leo-editor]

> is the #@@first supposed to be blank? Thanks for the workaround but yes it is 
> counterintuitive. It seems to me that having @first is the out of sequence 
> way of putting in first lines. Should I file a bug report?
I think it's working as intended - not sure what the docs. say but my 
interpretation is it's a way of saying to Leo, "*my* first lines *must* be 
first, don't go sticking any of your lines in front of them".  So you still 
have to put your first lines first, it just makes sure Leo doesn't put sentinel 
lines in front of them.
Also, I think the need for it goes away with @clean, whatever's first is first, 
you'd only need it with @file.
Finally, as another subtlety, remember things like @language don't get written 
to the external file with @clean, so they're not going to be before 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.

Re: ENB: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sun, 5 Feb 2017 02:16:15 -0800 (PST)
"Edward K. Ream"  wrote:

> 1. I am thinking that what we really want is your (Terry's) new VR4
> widget, or whatever you call it.
> 
> Do I remember correctly that this pane would allow both rendered and
> "raw" views of text.  If so, there would be little or no need for a
> separate VR pane.
> 
> In that case, users could put pictures into the body pane using rST
> syntax.  There is, in reality, little or no need to put pictures into
> code, but perhaps the VR4 widget could even handle intermixed
> @languages.

LEP (Leo Edit Pane, I'm calling it) splits each pane where its running
into an edit view and a rendered view.  So pictures could be shown in
the rendered half because it's markdown, or because it's HTML, or
because it's an ipython / jupyter in/out pair like:
https://danieltakeshi.github.io/assets/jupyter_2.png
The split's optional, you can have just the edit or just the view mode.

For editing text and pictures together, CKEditor is already embedded in
Leo, with image sizing and alignment / wrapping and captioning etc. etc.
http://sdk.ckeditor.com/samples/captionedimage.html
(aka richtext plugin).

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: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 08:42:08 -0800 (PST)
"Edward K. Ream"  wrote:

> Imo, images in the body pane are an essential ingredient for
> emulating pyzo, org-mode or Jupyter cells. They are too important,
> and way too cool, to forego.

Not sure about pyzo and org-mode, but does Jupyter show images in text
that's being edited?  I think it just renders markdown when it's not
being edited, and shows image outputs in a split view.

-- 
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: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 04:46:00 -0800 (PST)
"Edward K. Ream"  wrote:

> On Saturday, February 4, 2017 at 6:37:11 AM UTC-6, Edward K. Ream
> wrote: 

> I should emphasize that Leo reads and writes picture characters
> without problem, because *picture characters are normal unicode
> characters*:
> 
> - Picture characters will not harm scripts provided they are in
> comments.

Nonetheless, I don't think we should insert weird unicode chars into
peoples files, and I'm not sure it serves any purpose, seeing the char.
by itself carries no info.  The file should only every contain the
markup ( or ![alt text](url) or whatever).

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: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 01:21:26 -0800 (PST)
"Edward K. Ream"  wrote:

> The colorizer will replace the wikiview plugin. Issue #388 is moot,
> and will be closed today. The wikiview plugin is deprecated,
> effective immediately.

In general I think this analysis is good, although personally I don't
feel the need for images in a text editor, viewrendered is fine for me
(or at least will be, when viewrendered 4 is released ;-)

Don't forget the wikiview plugin unhides text when the cursor moves
through it.  I guess a command on a separate key binding would do
instead, although I find the current behavior quite smooth.
wikiview only hides things on node selection, the colorizer does it
more often, which might make "unhide on cursor contact" tricky, if it
immediately gets hidden again by the colorizer.  wikiview doesn't
re-hide until node deselection and reselection.

-- 
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: weaving in colorized html, group review, and working remote systems

['Terry Brown' via leo-editor]

For collaborative code review, GitHub has line by line commenting capability 
per commit, I think.
Cheers -Terry
  From: Eric S. Johansson 
 To: leo-editor  
 Sent: Friday, February 3, 2017 2:34 PM
 Subject: weaving in colorized html, group review, and working remote systems
   
Three questions:
Again, based on my earlier literate programming experience, I'm wondering how I 
can print out/present my code as a document? Is that still a thing or should I 
look at communicating with other reviewers a different way?
What's the best way for other developers to review code? What I'm thinking of 
is exporting all of the code is a document into Google docs and then using the 
Google docs comment feature and shared presentation for reviewing code with 
other developers.
And last, I almost never execute the code I'm working on on my Windows box. I 
almost always synchronize my code over to a Linux box before executing. What is 
an easy way I can trigger synchronization from Leo? Part of what complicates 
this is that I tend to use rsync in a bash script under cygwin because it's a 
UNIX like tool and it's easy for me. What can I do from Windows directly?
--- eric-- 
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: Is there a way to avoid conflicts with commit_timestamp.json?

['Terry Brown' via leo-editor]

The best way, although I think it requires action per clone of the repo., is to 
add
commit_timestamp.json merge=ours 
in the .gitattributes file in the to level folder of the repo. (where .git 
lives, but not in .git).
This just makes git use "ours" whenever there's a conflict.  It doesn't really 
matter which one it chooses.
[insert long pause for fresh clone of leo-editor]
So it doesn't require per clone action, because .gitattributes is part of the 
repo.  So if it's not currently working (i.e. commit_timestamp.json merge=ours 
is in your .gitattributes file but you're still getting conflicts, maybe the 
path's wrong, i.e. it should be leo/core/commit_timestamp.json merge=ours
perhaps.
Cheers -Terry

 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, January 31, 2017 7:25 AM
 Subject: Is there a way to avoid conflicts with commit_timestamp.json?
   
We've discussed this at length in other threads.  I seem to recall that Terry 
said that there was a clever fix for this.  Something better than `git checkout 
--ours leo/core/commit_timestamp.json`. But maybe I'm mis-remembering.

Now that I'm using branches, I suspect the way to merge the master into a 
branch is to use --theirs, not --ours:

git checkout my_branch
git merge
git checkout --theirs leo/core/commit_timestamp.json
git commit -m "resolved conflicts in .json file"
git checkout master
git merge my_branch # nothing should happen, by definition.

I've just merged both the color and and demo branches into master with this 
work flow. Only the merge from master into the demo branch caused a conflict in 
the .json file. 

Does all this make sense to everyone?

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: The color branch has been merged into master

['Terry Brown' via leo-editor]

You can use your regular git repo. dir as long as you don't modify 
...\leo\config\leoSettings.leo, which I don't imagine you do if you're using 
git.
How it's supposed to work:
set HOME=N:\scratch\delete\home

make Windows think you're home folder's N:\scratch\delete\home, so it doesn't 
see any changes you've made in your regular %HOME%\.leo\myLeoSettings.leo.  
N:\scratch\delete\home should be a folder which exists, but is completely empty 
(delete it and recreate it if unsure).
then for
python N:\local\leo-editor\launchLeo.py
you should just replace N:\local\leo-editor\ with where ever your launchLeo.py 
is, i.e. where ever your git repo. clone is.  So it will read the 
leoSetting.leo that comes with Leo, but not your local modifications.
Cheers -Terry




 
  From: lewis <lewisn...@operamail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Monday, January 30, 2017 3:22 PM
 Subject: Re: The color branch has been merged into master
   
N:\>set HOME=N:\scratch\delete\home

N:\>python N:\local\leo-editor\launchLeo.py
python: can't open file 'N:\local\leo-editor\launchLeo.py': [Errno 2] No such 
file or directory

This didn't work for me. Wouldn't I need to have a new copy of Leo different 
than my usual git repo? 

Lewis

On Tuesday, January 31, 2017 at 3:26:27 AM UTC+11, Terry Brown wrote:
Can you try running Leo like this:
mkdir d:\scratch\delete\home
set HOME=d:\scratch\delete\home
python d:\local\leo-editor\launchLeo. py

(with whatever path suits instead of d:\scratch\delete\home of course)
that's how I launch when I want to see default behavior.
-- 
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: The color branch has been merged into master

['Terry Brown' via leo-editor]

Can you try running Leo like this:
mkdir d:\scratch\delete\home
set HOME=d:\scratch\delete\home
python d:\local\leo-editor\launchLeo.py

(with whatever path suits instead of d:\scratch\delete\home of course)
that's how I launch when I want to see default behavior.
For me for @language python current trunk 
Leo 5.4, build 20170129073103, Sun Jan 29 07:31:03 CST 2017Git repo info: 
branch = master, commit = 1c28e916c371Python 2.7.5, PyQt version 4.8.5Windows 7 
AMD64 (build 6.1.7601) SP1
looks quite different - body pane background is white, the operators you 
mention are black.
Of course our Windows, Python, and Qt versions all differ.
Cheers -Terry
 
  From: lewis 
 To: leo-editor  
 Sent: Monday, January 30, 2017 7:52 AM
 Subject: Re: The color branch has been merged into master
   
The default colours present many characters as very low contrast and are 
virtually unreadable. 
See attached pic with an example using @language python. The = character is 
almost invisible. Math operators and % are also affected.

I don't think this has anything to to with the new colorizer, but worth 
reporting. I'm almost certain I'm using default and haven't changed any 
settings.

Leo 5.4, build 20170129073103, Sun Jan 29 07:31:03 CST 2017
Git repo info: branch = master, commit = 1c28e916c371
Python 3.6.0, PyQt version 5.7.1
Windows 10 AMD64 (build 10.0.14393) SP0

Lewis


On Sunday, January 29, 2017 at 11:42:36 PM UTC+11, Edward K. Ream wrote:
All appears to have gone smoothly. Please report any problems.

-- 
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: The trunk should be stable again

['Terry Brown' via leo-editor]

Strange, not sure what's happening.  You could try:
git checkout --theirs leo/test/unitTest.leo leo/core/leoColorizer.py 
leo/core/commit_timestamp.json
then 
git pull
again, but that's a bit of a guess
Cheers -Terry
 
  From: lewis 
 To: leo-editor  
 Sent: Wednesday, January 25, 2017 4:24 PM
 Subject: Re: The trunk should be stable again
   
When I ran 'git pull' I got this message:

$ git pull
remote: Counting objects: 85, done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 85 (delta 59), reused 57 (delta 31), pack-reused 0
Unpacking objects: 100% (85/85), done.
>From git://github.com/leo-editor/leo-editor
 + 4b5b74408...4efb5f58a master -> origin/master  (forced update)
 * [new branch]  color  -> origin/color

*** Please tell me who you are.

So I logged in and retried

$ git pull
Auto-merging leo/test/unitTest.leo
CONFLICT (content): Merge conflict in leo/test/unitTest.leo
Auto-merging leo/core/leoColorizer.py
CONFLICT (content): Merge conflict in leo/core/leoColorizer.py
Auto-merging leo/core/commit_timestamp.json
CONFLICT (content): Merge conflict in leo/core/commit_timestamp.json
Automatic merge failed; fix conflicts and then commit the result.

Any tips from here?

Thanks
Lewis

On Thursday, January 26, 2017 at 2:44:19 AM UTC+11, Edward K. Ream wrote:
The fixes were minor, and the new colorizer code now resides in a branch.

Still, even a few hours of badness isn't exactly the best advert for using the 
git repo.

Let me know if there are further problems.

-- 
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: New Leo edit control

['Terry Brown' via leo-editor]

 
  From: Edward K. Ream 
​Good marketing.  And great work, Terry. Not sure how this will fit in with the 
pyzo widgets. Eventually I would like to use pyzo widgets so that we can have a 
border for use by the debugger.  Hmm. Iirc, pyzo uses scintilla, so maybe this 
is part of the migration path.
If there's a pyzo editing widget, I'd hope that can be used as any other 
QScintilla / QTextEdit / LeoTextEdit etc. 
Hmm, I wonder if this new widget could be the wrapper, keybinding wise, for all 
the edit components.
Key-binding aside, it's current essentially working as an editor (albeit just a 
simple plain text one).  The fiddle bits are getting things like 
c.frame.body.wrapper.getSelectedText() etc. to work.  Not that it's hard in 
itself, just how it all ties together.
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: Python 3 -> 2 pickling problems with bigdash plugin

['Terry Brown' via leo-editor]

If rebuilding that DB was a major time consumption you wanted to avoid the Leo 
code could be modified to use two DB's, one for Py2 and one for Py3.  Beyond 
that, I don't think there's much alternative.  Don't imagine anyone wants to 
backport the new protocol to 2.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, January 24, 2017 9:03 AM
 Subject: Python 3 -> 2 pickling problems with bigdash plugin
   
I have just discovered another pickling problem when going backwards from 
Python 3 to 2.  This happens often enough in my testing.  I think there is an 
easy workaround, but I'd like your comments.

The bigdash.py plugin uses the whoosh package if it exists, and whoosh has 
fallen into the common trap of specifying the latest version for pickling 
rather than a fixed version, as discussed on this page.

Terry worked around a similar problem in PickleShareDB ctor. The error message 
there is:

    Unpickling error - Python 3 data accessed from Python 2?

For bigdash.py, the plan is to have LeoFts.__init__ delete the old database in 
~/.leo/fts_index and post a similar error message.  This will erase history, 
but I see no real alternative.

Your comments, please.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   
 

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

New Leo edit control

['Terry Brown' via leo-editor]

On Mon, 23 Jan 2017 13:40:48 -0600
"Edward K. Ream"  wrote:

> On Mon, Jan 23, 2017 at 11:42 AM, john lunzer 
> wrote:
> 
> > Of the code editor's I've used code comparison is encouraged within
> > a single running application, this allows for fancier things like
> > vim's diff mode which looks like github's HTML diffs. If you open
> > up two Leo applications you lose the possibility for this kind of
> > feature. 

Well timed :-)

> ​Interesting.  I wouldn't want to rule that out. Comparisons using two
> different instances of Leo is a workaround...

As I mentioned to Edward in what was probably a GitHub discussion (+1
if you subscribe to all activity on Leo's GitHub it's integrated with
your email and seems seamless, but -1 you lose track of which is GitHub
discussion vs. leo-editor discussion), I've been working on a new node
editing widget for Leo.  It's going well although early days - it's
kind of a container for a non-singleton body text editing widget plus a
rendered view widget.

Attached is a screen shot, which looks odd because the screen shot
software's omitting the window border.

Track - whether or not it follows the node node selection in the tree.

Update - whether or not it updates when the content of its node changes.

Recurse - whether or not the View part is rendered based just on the
current node, or recursively.

Split▾ - a three state button, Edit / Split / View, whether to show
only the Edit or View components, or both.  When showing both... kind
of reminds you of a Jupyter code + output display widget, doesn't it :-)

Render just causes an update of the View component when Update is
disabled

More▾ is where a bunch of other stuff will go, like selecting how to
render (HTML, markdown, execute code and render result as plain text or
some other format), only update once every N seconds for expensive
renders, etc. etc.

In the (very alpha) screen shot, you can see the effect of Recurse
being checked in the View component (lower half), @others is replaced
with descendant nodes.

The point of this widget is to provide a place for paired edit and view
widgets, or just one or the other.  It manages all the tracking / not
tracking, updating stuff etc.

Right now the only view widget is a plain text QTextBrowser with a tan
background :-), and the only edit widget is a plain text QTextEdit.

I think it will be quite easy to add QScintilla as another editor
widget, where supported, and all the expected rendering widgets (HTML,
markdown, rst, etc. etc.).  So in some respects this is
View-Rendered-4, with the advantage of hindsight of all the previous
View-Rendered work.  But also recognizing that the same track / don't
track etc. controls View-Rendered needs also apply to non-singleton body
editors.  As I write I realize I need to add "Follow", like track except
the tree jumps back to the editor's node when the editor's selected.

The goal is to be resolutely non-singleton, and provide a small and simple
API for edit and view widgets.  There will be a lot of view widgets, but I
assume very few edit widgets.  Maybe just QScintilla, Leo's body editor, and
maybe the CKEditor rich text editor.

The challenge, which I'm hoping Edward will help with ;-) will be
getting Leo's body editor to work - particularly the key binding part.  I
realize that supporting Leo's sophisticated key bindings (modes,
abbreviations, control of other parts of Leo, e.g. moving tree selection
while in body editor) add a lot of complexity to implementing Leo's
interface, but are also a major part of Leo's strength.

My plan is to make it work so well with QScintilla and all the
view rendering widgets the need to get the regular Leo body widget in
there will be overwhelming :-)

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: Cycling syntax highlighting

['Terry Brown' via leo-editor]

On Sat, 21 Jan 2017 15:42:48 -0600
"Edward K. Ream" <edream...@gmail.com> wrote:

> On Sat, Jan 21, 2017 at 9:24 AM, 'Terry Brown' via leo-editor <
> leo-editor@googlegroups.com> wrote:
> 
> > (from a GitHub discussion)
> >
> > If you use
> >
> > @language html css javascript
> >
> > the node will be highlighted as html
> >
> > the button code below cycles the @language line:
> >  
> 
> ​[snip]
> 
> Can you explain why this is useful?  Leo's colorizer can handle
> multiple @language directives.

In a single node?  html / css / javascript can occur in the same file,
which may be in the same node.  I used those because I though it was a
familiar example, I'm more typically mixing R and Markdown in one node.
In this example:
https://raw.githubusercontent.com/yihui/knitr-examples/master/001-minimal.Rmd
the code inside the ``` blocks is R, the rest is Markdown.

Quick test:

@language python
import eels # hah
@language latex
\newpage % hah

Doh, you're right, I didn't realize that, so yes, that's a better
option unless you just don't want to have to remember a new @language
directive every time you switch languages.

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.

Cycling syntax highlighting

['Terry Brown' via leo-editor]

(from a GitHub discussion)

If you use

@language html css javascript

the node will be highlighted as html

the button code below cycles the @language line:

@language html css javascript ->
@language javascript html css ->
@language css javascript html ->
@language html css javascript -> ...

so syntax highlighting cycles through those languages.

nd = p
while not p.isRoot():
if p.b.strip().startswith("@language "):
lines = p.b.strip().split('\n', 1)
words = lines[0].split()
current = words[1]
words[1:] = words[2:]
words.append(current)
p.b = '\n'.join([' '.join(words)]+lines[1:])
c.selectVisBack()
c.selectVisNext()
c.redraw()
break
p = p.parent()
else:
g.es("None found")


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: OT: What's a raspberry pi good for?

['Terry Brown' via leo-editor]

On Sat, 21 Jan 2017 04:57:24 -0600
"Edward K. Ream"  wrote:

> On Fri, Jan 20, 2017 at 9:02 AM, Edward K. Ream 
> wrote:
> 
> > I was given a raspberry pi 3 for Christmas.  It's still unopened.
> > Anyone know a real use for it?
> >  
> 
> ​Thanks for the replies.  My concern is that the internet of things
> has security holes.  For example, it's possible to use
> computer-controlled light bulbs to hack into the system that is
> controlling them.

A valid concern, but Pis aren't really "things" in that sense, they're
little computers running Linux, everything you know about securing such
systems, and the resources put in to keeping Linux secure, apply here
too.  For example I run fail2ban on mine.

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: OT: What's a raspberry pi good for?

['Terry Brown' via leo-editor]

On Fri, 20 Jan 2017 07:02:43 -0800 (PST)
"Edward K. Ream"  wrote:

> I was given a raspberry pi 3 for Christmas.  It's still unopened.
> Anyone know a real use for it?
> 
> Edward

I have two, I was using one as a media player on the TV, until the TV
died and got replaced with a smarter one.  The other I use as an
always on server for remote logins and other light weight web things.

The 3's are quite powerful.  You can deploy GitLab on them, for example.

I also used one in a piece of PVC pipe with a radio and GPS receiver
to make a floating current mapper for river and lake research,
although I think these https://www.adafruit.com/product/2390 are a
better fit for that as they use less power.

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: Leo and fossil

['Terry Brown' via leo-editor]

On Tue, 17 Jan 2017 10:32:18 -0500
Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

> Hi,
> 
> 
> On 17/01/17 09:19, 'Terry Brown' via leo-editor wrote:
> > On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
> > vitalije <vitali...@gmail.com> wrote:
> >  
> >> Database is just a part of fossil. It isn't question of where Leo
> >> can keep its data. It's about keeping a history of data. Fossil
> >> keeps (in efficient way) all versions of the data, it can show the
> >> diffs in several formats, ... pretty much all that git does. The
> >> advantage of using fossil instead of git, IMHO, is that:
> >>
> >> - it doesn't need to be installed (it is just one executable
> >> file, available for all platforms that  Leo supports)  
> > I assume you mean it's just one Python file, that could be
> > distributed with Leo?  That is an advantage.  
> 
> No. Is not a Python file. Fossil is distributed like a small binary 
> available in all Leo platforms [1] and "installing" it, is just
> copying.
> 
> [1] http://fossil-scm.org/index.html/uv/download.html
> 
> >  
> >> - it keeps all its data in just one file, while git
> >> creates .git subtree  
> > I'm not sure there's enough difference in convenience there to put
> > a lot of weight on that distinction.  
> 
> Richard Hipp, Fossil and SQLite author, makes that distinction and
> about the "pile of files" database (like the .git folder) instead of
> the single file approach[2]. There is a lot of querying capabilities
> of the last one, as you can see on [4]

Can't watch the youtubes right now.  I suspect google will tell you how
to do most of queries listed on [4] in git too.  And I'm not sure how
relevant they'd be to Leo node level versioning, given the need to
address nodes rather than files.  And the desire to have the node
history interaction interface in Leo itself.  Certainly Fossil's local
web server approach is neat in terms of providing a richer reporting
interface than git as standard.

I think there's a two birds with one stone opportunity here if the
development proceeds with a generic interface to multiple backends, of
which Fossil could be one.  I'm thinking not so much of git but a
server based DB like Mongo or Postgres or MySQL ... suddenly
collaborative Leo outline editing is a big step closer.

Cheers -Terry

> [2] https://www.youtube.com/watch?v=8y_ABXwYtuc
> [3] https://www.youtube.com/watch?v=ghtpJnrdgbo
> [4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md
> 
> >
> > If the emphasis is on node versioning, there's this:
> >
> > https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ
> >
> > which points to a couple of older posts.
> >
> > I still think this node versioning / node storage should be
> > approached generically with Fossil as an example backend rather
> > than hard coding directly for Fossil.  
> 
> I agree with Vitalije about using fossil at file level, instead of
> node level and my (Grafoscopio) experiments went in the same
> direction. I remember thinking, years ago, that all the complications
> about working with external files and external editions could be
> solved by an integrated simple DVCS (fossil) and a simpler file
> format (Yaml) that were coupled with Leo (as pointed in the 2011 "Leo
> new directions" thread). By making my own prototypes, I can now
> express better that intentions.
> 
> That doesn't mean that Leo can not talk with external DVCS, but
> having the power of one simpler format and DVCS to express how
> (internal or external) files in a project change, including .leo
> files should be part of a smooth experience about representing
> projects and their history. I would start for this smooth integrated
> experience and, after that, I would start to abstract and decouple to
> make it neutral to the DVCS backend.
> 
> Cheers,
> 
> Offray
> 

-- 
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: Leo and fossil

['Terry Brown' via leo-editor]

On Tue, 17 Jan 2017 01:09:47 -0800 (PST)
vitalije <vitali...@gmail.com> wrote:

> Database is just a part of fossil. It isn't question of where Leo can
> keep its data. It's about keeping a history of data. Fossil keeps (in
> efficient way) all versions of the data, it can show the diffs in
> several formats, ... pretty much all that git does. The advantage of
> using fossil instead of git, IMHO, is that:
> 
>- it doesn't need to be installed (it is just one executable file, 
>available for all platforms that  Leo supports)

I assume you mean it's just one Python file, that could be distributed
with Leo?  That is an advantage.

>- it keeps all its data in just one file, while git creates .git
> subtree

I'm not sure there's enough difference in convenience there to put a lot
of weight on that distinction.

If the emphasis is on node versioning, there's this:

https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ

which points to a couple of older posts.

I still think this node versioning / node storage should be approached
generically with Fossil as an example backend rather than hard coding
directly for Fossil.

Seems the API would boil down to something like

backend.snapshot_node(, )
backend.node_versions()  # list version_ids of available versions
backend.get_node(, )

with some details maybe re search by headline etc.

Cheers -Terry

> On Monday, January 16, 2017 at 5:25:22 PM UTC+1, Terry Brown wrote:
> >
> > Another question is whether the integration is just at the
> > load/save level or at the node traversal level, i.e. constantly
> > using a data backend.  I think if we started with the load/save
> > level, the sweet spot might be some subtree / node level live
> > refresh from a data backend. 
> >
> > For diffs, seems an xml to yaml conversion would achieve that?
> > Like I say, haven't been following the conversation too closely. 
> >
> > Cheers -Terry 
> >
> > I don't expect integration to be at node traversal level. At the
> > load/save   
> phase (or even on an explicit user request), fossil would record the
> new version of the outline. Later, a user might want to see how and
> when some node has changed, or what was it like in some earlier
> version. The simple script I made for the experiment already enables
> all that functionality. The next more challenging task is to create
> an elegant GUI that user can use to run all those functions.
> I haven't programed in PyQt for a long time. Many things I used to
> know I forgot  and there seem to be a lot of changes in PyQt since.
> Nevertheless, I can imagine how GUI might be like. For example,
> imagine a small slider widget along the bottom of body, or in status
> line, that represents time. User can slide it left or right and the
> selected body would change accordingly as it was at the selected
> moment. When focused slider would enable user to switch to the
> previous/next version using the arrow keys.
> 
> I am not sure that all this would be useful at all. I can't recall
> when was the last time that I needed something like this. But maybe I
> would use it more often if it was possible in the first place. The
> way I see it, this can be interpreted as "undo/redo" functionality
> but persistent between editing sessions and spread at node levels,
> i.e. every node has its own "undo/redo" timeline. It may be useful,
> who knows?
> 
> 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.

Re: Leo and fossil

['Terry Brown' via leo-editor]

On Mon, 16 Jan 2017 04:46:13 -0800 (PST)
vitalije  wrote:

> On Monday, January 16, 2017 at 11:45:56 AM UTC+1, Edward K. Ream
> wrote:
> >
> > So now I am more receptive to these ideas.  

I haven't followed the fossil discussion too closely, but I'd argue
for, rather than adding fossil as a single new data backend, revisiting
and refreshing (or replacing) Leo's capability of using a "DB" backend,
with a view to making it a pluggable layer where you might be plugging
in to fossil or git or sqlite3 or MongoDB etc. etc.

I think we had a working proof of concept use of Zope Object Database
(ZODB) at one point.  I'm not sure that's still an interesting target,
but certainly a good place to review.

Another question is whether the integration is just at the load/save
level or at the node traversal level, i.e. constantly using a data
backend.  I think if we started with the load/save level, the sweet
spot might be some subtree / node level live refresh from a data
backend.

For diffs, seems an xml to yaml conversion would achieve that?  Like I
say, haven't been following the conversation too closely.

Cheers -Terry


> > Edward
> >  
> Glad to hear that.  
> 

-- 
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: Syntax coloring mystery solved!!

['Terry Brown' via leo-editor]

On Sun, 15 Jan 2017 06:18:53 -0500
"Edward K. Ream"  wrote:

> Terry, please test this branch for a day or so and report any
> problems. I'll follow this with interest on my travels. If all seem
> well, feel free to merge the branch.

Initial look I'm not seeing anything but way faster colorizing :-)
Will report if anything else shows up.

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 fast-colorizing branch: a revolution in syntax coloring

['Terry Brown' via leo-editor]

On Sun, 15 Jan 2017 04:44:11 -0800 (PST)
"Edward K. Ream"  wrote:

> On Sunday, January 15, 2017 at 6:53:32 AM UTC-5, Edward K. Ream wrote:
> 
> *I have not tested this code with Python 2*. 
> >  
> 
> It turns out that colorizer.colorize *is* called, but only with
> python 2.
> 
> Once in a while I am seeing this, with both Python 3 and 2:
> 
> Internal Leo error in bodyString
> not unicode: (the actual string)
> Called from writeFile,makeCacheList,__get_b,bodyString

Not sure that that's new - e.g. I reported it here:
https://github.com/leo-editor/leo-editor/issues/342
which I think was before Pyzo came on the scene.

Cheers -Terry

> This may be a subtle result of the changes made in the LeoTree.select 
> logic.  Off hand, I don't see why bodyString can't just convert to 
> unicode...
> 
> I don't have time to investigate this now. Not sure how serious it
> is, but I don't think the branch can be merged in its present state.
> 
> 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: Syntax coloring mystery solved!!

['Terry Brown' via leo-editor]

On Sat, 14 Jan 2017 18:22:26 -0800 (PST)
"Edward K. Ream"  wrote:

> Done, and pushed, I think.  It's called fast-colorizing, rev
> 2beba78b5. Let me know if the branch doesn't show up.  This is my
> first branch...

Branch is there in the correct place.

Safe travels.

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: Syntax coloring mystery solved!!

['Terry Brown' via leo-editor]

Congrats on finding the culprit.
Couple of things I'd like to see in Leo syntax highlighting, highlighting of 
trailing whitespace, and highlighting of 
https://en.wikipedia.org/wiki/Non-breaking_space and also of tab (\t).  To be 
quite honest I've only made one foray into the syntax highlighting code, some 
time ago, and really can't remember the details.  So don't know if this is hard 
or trivial.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Friday, January 13, 2017 12:23 PM
 Subject: Syntax coloring mystery solved!!
   
tl;dr: Calling doc.markContentsDirty(0, len(p.b)) suffices to recolor a node! 
This should be done instead of calling highlighter.rehighlight explicitly.

I could never have found this bug if I hadn't seen how fast pyzo colorizing 
code was within pyzo itself compared to the same code within Leo. 

Having refresh-from-disk do the coloring correctly and quickly was the crucial 
lucky break.  Tracing showed that a big @edit node was being colorized 
correctly despite highlighter.rehighlight not being called.

After a bit of noodling (without beer) I saw that the body pane's QTextDocument 
must be repeatedly calling highlighter.highlightBlock. I verified this was so 
(without huge traces) by examining the before and after counts of 
highlighter.n_calls.  As hoped, these jumped, indicating that something 
(QTextDocument is the only candidate) was in control.

This is a lucky, lucky break on Friday the thirteenth ;-) It is likely that 
Leo's existing colorizers can be speeded up by 10x. If so, there will be no 
need for the big text hack. Crucially, Qt does not show the text until it has 
been fully colorized.

Furthermore, close study of the pyzo code shows that actual syntax coloring 
could now be deferred until idle time, thereby further improving performance.

Pyzo is full of superb code, and pyzo's colorer is no exception.  I'm not sure 
whether to adapt pyzo's code for all syntax coloring, but I'm tempted.  It 
would be a big project.

In the meantime, I can adapt two good ideas from the pyzo colorer:

1. Precomputing QTextFormat objects saves a lot of time. Leo's present 
colorizers do far too much work withing the main colorizing loop.

2. Using a special tag for unterminated strings is genius.  The three little 
dots are a great visual cue, and terminating the token at the end of the line 
means that adding a quote does not cascade to all following lines.  A great 
hack.

I'm glad this is behind us.  I was starting to doubt my sanity, and starting to 
imagine bugs that would never be found...

The way is now open for more pyzo integration.  I am seriously considering 
replacing Leo's custom text widget with pyzo's.  It a big project, but it will 
pay huge dividends.

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.

Text wrapping in Leo

['Terry Brown' via leo-editor]

Here's the commit message for 05df9ac

add @cmd justify-toggle-auto and @bool autojustify-on-at-start
The @int autojustify behavior is very useful for writing prose
(not code) when you want text wrapped at a particular column with
a real newline, not just visually wrapped at the window edge. To
be usable it needs a command to toggle activation, and a setting

to decide whether it's on by default, this commit adds those.

Leo build: 20170112092903

The setting @int autojustify itself has been around for a while,
I'd forgotten about it, I've been wanting this feature for years,
made a failed attempt to add it once, but just (re)discovered the
when I realized how it should be done, and found that it already
was :-)

More discussion here: 
https://github.com/leo-editor/leo-editor/issues/14

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: pyzo syntax coloring: progress and a big mystery

['Terry Brown' via leo-editor]

2. Are the proper QDocument and QTextEdit being used? The present prototyping 
code uses an instance of pyzo's CodeEditorBase as way of instantiating the 
pyzo's syntax colorer.  Maybe the highlighter must be attached to Leo's actual 
QTextEdit body widget. The pyzo colorizer uses QDocument to do crucial caching. 
Two different QTextEdit's or QDocument's might create the performance bug.

Can you check that the cache is being hit, by reporting / counting hits?  If 
it's never being used, or being asked to cache the same values repeatedly, then 
some communication issue must be effectively disabling the cache.  I don't know 
how much pyzo relies on it for speed, but a broken cache could certainly slow 
things down. 
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: Leo's real weaknesses

['Terry Brown' via leo-editor]

 
  From: Edward K. Ream <edream...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Wednesday, January 11, 2017 1:33 PM
 Subject: Re: Leo's real weaknesses
   
On Wed, Jan 11, 2017 at 12:31 PM, 'Terry Brown' via leo-editor 
<leo-editor@googlegroups.com> wrote:> I wouldn't be in a huge rush to eliminate 
wrappers.

No worries. They can't be eliminated now, because doing so could break existing 
code.
EKR

I'm not sure if that can be a blanket statement.  I guess Leo doesn't have a 
defined boundary between declared API and internals subject to change - perhaps 
by default we've assumed the stable API is *everything*, that *no* changes 
should break existing code. But I'm sure that doesn't reflect reality, every 
time a helper function is eliminated or something like that there's a chance to 
break someone's code, somewhere.
To me there's an implicit line between API that must not change 
(p.insertAfter()) and internals that would be used by so few, and those few 
generally "developers", that the concern about breaking things is outweighed by 
the need to be able to refactor the code base as Leo evolves.  Unfortunately it 
would be a very fuzzy line.
I'm not really sure which side of the line the wrappers fall on.  Things like 
c.frame.body.wrapper.getInsertPoint are probably used in a lot of scripts, so 
maybe that should be considered API.
But what about things like the free_layout framework.  I'd like to remove it 
and replace it with Qt Docking, I've been working on that, not ready to release 
yet, or even close, but do we really need to worry about scripts that might be 
broken by such a change?  How many people would have interacted with that code?
Tricky.
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.


   
 

-- 
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: Leo's real weaknesses

['Terry Brown' via leo-editor]

1. Using wrapper classes for text editing

The present Qt gui is, iirc, Leo's fourth gui.  Two preceded Leo in python.  
Previously, the python version of Leo used the much weaker Tk gui.

The pyzo code shows just how big a price Leo has paid for the wrapper text 
abstraction layer.  Otoh, having a standard text widget greatly simplifies the 
curses gui plugin. Still, the text wrappers do complicate matters significantly.

I wouldn't be in a huge rush to eliminate wrappers. I'm not sure if they're at 
the right level of abstraction, but a good wrapper level could be very valuable 
in moving towards three functional UIs, Qt, HTML/javascript, and curses.  Maybe 
there are idioms other than wrappers that would work equally well - more use of 
the leoServer model perhaps. 
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 design of Leo+Ipython+Jupyter+Lit-computing

['Terry Brown' via leo-editor]

Just for context, am I remembering correctly you wanted this for some sort of 
auto-save function, so an auto-save could happen without impacting the user's 
focus etc.?  Or if not that, at least some issue where you didn't want focus 
disrupted during a (timed?) save?
Is there a GitHub issue for this? 
https://github.com/leo-editor/leo-editor/issues
Cheers -Terry

 
  From: Mike Hodson 
 To: leo-editor@googlegroups.com 
 Sent: Tuesday, January 10, 2017 12:23 PM
 Subject: Re: The design of Leo+Ipython+Jupyter+Lit-computing
   
I must ask, with all this extending to great big new things, all I've wanted 
from Leo for over a year now is the ability for it to save a file without 
causing the entire user interface to redraw itself.
how hard is it to decouple the UI from the gears behind it, vs adding all this 
new cruft?

-- 
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: Hybrid @ type?

['Terry Brown' via leo-editor]

Here's one I was using with coffeescript / R code, can't find the one that was 
markdown focused.  Basically it updates all nodes to have their headline as the 
first line of the body like this:
  ###  
updating / inserting as needed, also puts exactly two newlines at the end of 
each body, I think that was so the external file looked better.
For markdown you'd have to track depth to control the number of # at the start, 
and put none at the end.  
Depth of a position is p.level(), so you probably need
nd.level() - p.level() + 1
hashes at the start of the line
Code: https://gist.github.com/tbnorth/eb913fcab82f6a4b37734b5156543308
Cheers -Terry


 
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Wednesday, January 4, 2017 10:58 AM
 Subject: Re: Hybrid @ type?
   
Sounds like that would be useful. Do you mind sharing the script?
Rob.

On Wednesday, January 4, 2017 at 11:48:25 AM UTC-5, Terry Brown wrote:
Something I've done as a workaround is a script button to push headlines into 
body text when using @clean. So for a node "Discussion", if the first line of 
the body starts with "# ", make it be "# Discussion", otherwise insert a line 
like that.
Cheers -Terry

 
  From: Largo84 <lar...@gmail.com>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Wednesday, January 4, 2017 9:18 AM
 Subject: Hybrid @ type?
  
Over the last year or so, I have used @auto-x more and more (in particular, 
@auto-md) because I like the 'clean' external files that replicate the 
organization of the nodes in Leo. However, more recently as I began relying on 
tagging, back links and clones, I am running into major limitations with 
@auto-x (and to a lesser extent with @clean). (See also the recent post on uA 
storage.)
What would be really beneficial would be a 'hybrid' @ type that writes 
and maintains org structure  (node headline text) in the external file based on 
@language (md, org-mode, rst, etc.) while also utilizing the tagging, linking 
and cloning features of Leo. As I see it (please correct me if this assumptions 
are wrong):   
   - @file maintains all of the Leo features described, but the external file 
includes sentinels.
   - @clean keeps uA information (tags, links, etc), but loses cloning 
information. Also, @clean *does not* write node headline text to external files.
   - @auto-x loses both uA and cloning information, but *does* write node 
headline text into external files (based on type).

Thoughts or ideas?
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+...@ 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.
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.


   
 

-- 
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: Hybrid @ type?

['Terry Brown' via leo-editor]

Something I've done as a workaround is a script button to push headlines into 
body text when using @clean. So for a node "Discussion", if the first line of 
the body starts with "# ", make it be "# Discussion", otherwise insert a line 
like that.
Cheers -Terry

 
  From: Largo84 
 To: leo-editor  
 Sent: Wednesday, January 4, 2017 9:18 AM
 Subject: Hybrid @ type?
   
Over the last year or so, I have used @auto-x more and more (in particular, 
@auto-md) because I like the 'clean' external files that replicate the 
organization of the nodes in Leo. However, more recently as I began relying on 
tagging, back links and clones, I am running into major limitations with 
@auto-x (and to a lesser extent with @clean). (See also the recent post on uA 
storage.)
What would be really beneficial would be a 'hybrid' @ type that writes 
and maintains org structure  (node headline text) in the external file based on 
@language (md, org-mode, rst, etc.) while also utilizing the tagging, linking 
and cloning features of Leo. As I see it (please correct me if this assumptions 
are wrong):   
   - @file maintains all of the Leo features described, but the external file 
includes sentinels.
   - @clean keeps uA information (tags, links, etc), but loses cloning 
information. Also, @clean *does not* write node headline text to external files.
   - @auto-x loses both uA and cloning information, but *does* write node 
headline text into external files (based on type).

Thoughts or ideas?
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.
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: Headline in body text?

['Terry Brown' via leo-editor]

On Tue, 3 Jan 2017 18:10:58 -0800 (PST)
Ross Burnett  wrote:

> I am poking around in the LeoDocs.leo file, and the *Leo 5.4 /* *Bugs
> fixed* children have some headlines that are longer than fit in the
> default-sized outline window.  For example: 
>   Fixed #289: Leo crashes with unusual combination of @clean and .leo
> file
> 
> To view the entire headline, I need to scroll right in the outline,
> or I can see the entire headline in the status area at the bottom in
> a smaller font, but is there a way to automatically mirror the
> headline at the top of the body text so it can be more easily read? 
> I think it might also add context to the body text.
> 
> Or would this need to be my first plugin?

Probably, if you want to learn about PyQt and messing with the Leo
interface, it wouldn't be a bad thing to try, although having used
a GUI library before would help with the concepts.

Commands -> Body Editors -> Add Editor creates a second body editor,
and gives each exactly the headline you're describing - might not be
the simplest piece of code to poke around in though.

There's also the `edit-headline-long` command, but that's for editing.

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: Bookmarks pane disappears

['Terry Brown' via leo-editor]

On Mon, 26 Dec 2016 19:30:11 -0600
"'Terry Brown' via leo-editor" <leo-editor@googlegroups.com> wrote:

> But there's nothing that can be done to fix it retrospectively, Python
> 2 can't depickle protocols higher than 2,

But... we could write Python 3 code to recursively convert all the
pickles in ~/.leo/db/ to protocol 2 - would that help you Lewis?  It
would undo the effects of this issue, but maybe you've covered all the
impacted cases, or can't run Python 3 on the machine in question?  It
would just vanilla Python 3, not Qt required.

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: Bookmarks pane disappears

['Terry Brown' via leo-editor]

On Mon, 26 Dec 2016 10:51:41 -0600
"'Terry Brown' via leo-editor" <leo-editor@googlegroups.com> wrote:

[snip]
> I think I need to poke around a bit more to confirm that it is changes
> in the association of c.db with the same outline between versions of
> Python that's driving this problem, and if so see if anything can be
> done about it.

I think we were both basically on track, although the exact problem is
a bit simpler than Py 2/3 having different file paths or hashes thereof
for a particular file.  It's this line:

https://github.com/leo-editor/leo-editor/blob/4d28c69/leo/core/leoCache.py#L405

c.db values are always written with the highest available pickle
protocol, which is 2 in Python 2 and 4 in Python 3.  Python 3's default
is 3.  So in Python 2 Leo fails to decode the *value* and reports it as
a *key* error.  Or silently fails in bookmarks.py's case.

So the solution would be a hard coded constant of 2 in place of
pickle.HIGHEST_PROTOCOL there.

Differences in protocols are explained here:
https://docs.python.org/3/library/pickle.html#data-stream-format

I've made this change to prevent the problem going forward:

https://github.com/leo-editor/leo-editor/commit/0cf4999

But there's nothing that can be done to fix it retrospectively, Python
2 can't depickle protocols higher than 2, which is what Python 3
wrote.  So the problem only affects people using 3, then going back to
2, but that's probably not uncommon for various reasons.

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: Bookmarks pane disappears

['Terry Brown' via leo-editor]

On Mon, 26 Dec 2016 05:40:47 -0800 (PST)
lewis  wrote:

> It isn't enough to Alt-X: bookmarks-show. The bookmarks reload in new
> pane but if you close the leo file, you are prompted to save, and the
> bookmarks settings are not saved.
> The file reloads as if no changes had been made to the bookmarks.
> 
> I found the best way is right-click 'Insert' (hover 'Insert an empty
> pane here') then select the bookmarks node you want to load, then
> select 'Action' > bookmarks. This reloads the bookmarks setup.
> Then you need to right-click over the pane splitter 'Save Layout'
> enter a name and OK to save it. If you don't save the layout all the
> previous bookmarks actions are lost.
> 
> This reminded me that I *had* saved layout names in my leo file, but
> Leo could not find the layout names.
> So these layout names (identity?) are saved to the per outline
> persistent DB.
>
> The fact that I can lose this setup data feels like a bug to me.

Ok, so I think it might still be the c.db issues, but perhaps not only
the tracking of the node holding bookmarks, but also the tracking of
the active layout for a particular outline, I think they're both stored
in c.db.

Hmm, so layouts themselves are saved in g.app.db.  They shouldn't
disappear with a change in Python version.  So if you'd done
right-click Load Layout, your previously saved layout should have been
on the list, and selecting it would have been sufficient to set it for
Python 2's version of c.db.

I think I need to poke around a bit more to confirm that it is changes
in the association of c.db with the same outline between versions of
Python that's driving this problem, and if so see if anything can be
done about it.

Cheers -Terry
 
> Regards
> Lewis
> 

-- 
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: Bookmarks pane disappears

['Terry Brown' via leo-editor]

On Sun, 25 Dec 2016 13:55:56 -0800 (PST)
lewis  wrote:

> Hi Terry,
> 
> I recently switched from python 3.5.2/PyQt5 v5.7.0 to python
> 2.7.13/PyQt4 and noticed that my bookmarks pane no longer displays.
> Do I have to somehow reactivate the bookmark pane?

Yes, if you just select the top node of bookmarks in your outline and
do Alt-X: bookmarks-show that should fix it, the layout might have an
extra pane the first time, but that should go away on reload.

I think what's happening is that the identity of the node holding the
bookmarks is held in the per outline persistent DB,
c.db['_leo_bookmarks_show'] and that's tied to the outline by the path
to the .leo file or a hash of the path, not sure.  If somehow the path
or its hash differs at all between Python versions (even though it
resolves to the same path), you don't get the same c.db, and have to
identify the node again.

Not 100% sure about that, but that's my best guess.

Cheers -Terry

> Regards
> Lewis
> 
> *Leo Log WindowLeo 5.4, build 20161225051646, Sun Dec 25 05:16:46 EST 
> 2016Git repo info: branch = master, commit = a14ca3603bc9Python
> 2.7.13, PyQt version 4.8.7Windows 10 AMD64 (build 10.0.14393) *

-- 
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, how do you alias @ nodes in headlines?

['Terry Brown' via leo-editor]

On Wed, 21 Dec 2016 03:17:44 -0800 (PST)
"Edward K. Ream"  wrote:

> Iirc, this is a plugin, but I can't seem to find it.  This relates to
> #351 , which I
> have just closed.
> 
> Edward

Here's what I just posted as a comment on that issue.  It's in core,
not a plugin.

Not sure the headline abbreviation thing really addresses the OP's
idea, although it could make @clean appear as @fileclean when not being
edited. But for newcomers, that might be more confusing than helpful -
if they started entering @fileclean. It's more typical use is to make
@clean appear as an icon, a document with a C on it, to reduce screen
space use by directives like @clean. Maybe that addresses the OP's idea
as it's a file icon.

Here's instructions for using it I wrote in response to a recent
question:

Search for tree-declutter in leoSettings.leo.

set

@bool tree-declutter = True
then craete a @settings node

@data tree-declutter-patterns

can contain patterns like:

# remove @clean and use an icon
RULE ^@clean (.*)
REPLACE \1
ICON file_icons/file_clean.png

# show the last part of long filenames
RULE ^.{1,1000}([/\\])(.{25})
REPLACE …\1\2

# if the node name starts with 'peacock node DEMO', make a mess of it
RULE ^(peacock node DEMO)
REPLACE LOOK: \1
ICON Tango/16x16/emotes/face-grin.png
ICON Tango/16x16/emotes/face-wink.png
FG @solarized-magenta
BG white
FONT Times
PX 40
ITALIC 1
WEIGHT Bold

-- 
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: Org Mode File - Node sorted by time stamp

['Terry Brown' via leo-editor]

Hi,
You could avoid renaming the nodes with something like this, untested, just 
copy/pasting your code:
def datesort(p):    datestamp='00'
    if '<' and '>' in p.b: # check to see if there is at least one likely 
datestamp        i = p.b.find("<") #get the index of the beginning of datestamp 
       j = p.b.find(">") # get the index of the end of the datestamp        
datestamp=p.b[(i+1):j]  # use indices to grab the date
    return datestamp
c.sortSiblings(key=datesort)
Cheers -Terry

 
  From: Israel Hands <alist...@mcgh.ee>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Tuesday, December 20, 2016 1:39 PM
 Subject: Re: Org Mode File - Node sorted by time stamp
   
I think I'll try option one - I'm a slow and clunky coder - I've written this 
which tests the next node for the telltale  and grabs the datestamp. 
It then renames the node with the datestamp at the beginning of the node name. 
The plan is to rename all the nodes with datestamps in the body of the text, 
then use Leo commands to sort the nodes then un-name them, if you see what I 
mean. I'll need to deal with the deadline datestamp - I'll think on that. If 
you see any obvious improvements do let me know.
p=p.moveToNext() # drop down to next nodeseparator='||' # make a separatorif 
'<' and '>' in p.b: # check to see if there is at least one likely datestamp    
i = p.b.find("<") #get the index of the beginning of datestamp    j = 
p.b.find(">") # get the index of the end of the datestamp    
datestamp=p.b[(i+1):j]  # use indices to grab the date    
newhead=datestamp+separator+p.h #make a new header including the datestam and 
separator    c.setHeadString(p,newhead) #write the new header.
Thanks for the encouragement - If I get a working solution I'll let you know!
IH
On Tuesday, 20 December 2016 16:21:48 UTC, Terry Brown wrote:
Ok, I haven't used org mode import.
Seems like you wouldn't want the timestamps in the header, all you'd see in the 
tree view would be the timestamps.
Two possible approaches:
 - write a small piece of code to sort the nodes based on the timestamps in the 
body content. - import the org file taking advantage of Leo's todo plugin, 
which has date due fields and ui options to sort by them
Cheers -Terry
 
  From: Israel Hands <alis...@mcgh.ee>
 To: leo-editor <leo-e...@googlegroups.com> 
Cc: terry_...@yahoo.com
 Sent: Tuesday, December 20, 2016 10:01 AM
 Subject: Re: Org Mode File - Node sorted by time stamp
  

Thanks Terry and Rob!
I realise I wasn't clear enough in my original post. Org mode allows todo items 
to be entered into a file in any order but they can include a timestamp of 
their 'scheduled' time (and indeed a separate deadline timestamp).  In the 
orgmode Agenda view the items are then inserted in to a linear calendar, 
turning the unordered org file into a powerful calendar/todo list.
So one of my org mode items is -  Breakfast with James - it has a scheduled 
time and I have chosen to set a deadline.  When I choose Agenda view in orgmode 
I see the item has a deadline in today's date and the item itself appears in 
the calendar for tomorrow.Imported into leo I get a nice node with the headline 
- Breakfast with James -  and the body text is the two time stamps - the 
deadline is Tuesday the 20th (to remind me it is tomorrow) and then the 
scheduled time of the event Wednesday the 21st at 10am.  The node body looks 
like this = 
   DEADLINE: <2016-12-20 Tue 09:00><2016-12-21 Wed 10:00>
However the nodes are listed according to their place in the orgmode file (in 
creation order) rather than schedule order. I guess it would require digging 
out these scheduled times and maybe writing them into the header which would 
then make it easy to sort the nodes.
Anyway thanks for your attention.IH

On Tuesday, 20 December 2016 15:07:39 UTC, Terry Brown wrote:
Depends what you mean by timestamps.  If you mean a piece of text in the 
header, one of the Outline -> Sort commands should work.
If you mean sort by the internal "gnx" ID attribute of the nodes, which 
contains timestamp information, I don't think there's a command to actually 
re-order nodes on that basis.  But there is a commandfind-quick-timeline which 
displays all the nodes in the outline in the Nav pane, ordered most recently 
created to oldest.  Maybe that helps?  find-quick-timeline uses the gnx info.
Cheers -Terry
 
  From: Israel Hands <alis...@mcgh.ee>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Tuesday, December 20, 2016 7:23 AM
 Subject: Org Mode File - Node sorted by time stamp
  
I use OrgMode's Agenda view as my basic calendar and it's great to be able to 
import the org files into leo, is there a way of sorting the imported nodes by 
time stamp, other than writing a bit of code to accomplish the task?
ta
Al-- 
You received this message because you ar

IGNORE: address test

['Terry Brown' via leo-editor]

Sorry about this test (which your supposed to be ignoring ;-) - trying to get 
my email address to show up on posts to this list so it my posts are like 
everyone else's and I don't get Cc'ed on replies all the time. I've looked for 
the setting causing this behavior before, and failed to find it.  My email 
address isn't supposed to be secret.
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: Backlink plugin questions

['Terry Brown' via leo-editor]

Try selecting a node in the graph you want open at startup, and run 
graph-toggle-autoload, I think that will load all the explicitly (i.e. 
backlinks, not just Leo tree relationship) linked nodes in that graph on 
startup.  You can have multiple unconnected graphs in an outline, this only 
loads one of them.
Regardless of being loaded at startup, node positions in the graph should 
always be saved and restored when the node's added back to the graph display.
Cheers -Terry

 
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Tuesday, December 20, 2016 10:39 AM
 Subject: Re: Backlink plugin questions
   
Yes, looks good, thanks!
On a related note, I see that graphs aren't saved at all, regardless of file 
saving. I know that's from a different plugin.
Rob.

On Tuesday, December 20, 2016 at 10:31:36 AM UTC-5, Terry Brown wrote:
I think all the things you pointed out are fixed in
https://github.com/leo-editor/ leo-editor/commit/bf397a6e
let me know if that seem to be the case, or not.
Cheers -Terry

 
  From: Largo84 <lar...@gmail.com>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Tuesday, December 20, 2016 8:29 AM
 Subject: Re: Backlink plugin questions
  
Thanks, Terry. While you're at it, can you see why the links don't show up 
right away until after refreshing, leaving the node and then coming back?

On Tuesday, December 20, 2016 at 8:08:58 AM UTC-5, Terry Brown wrote:

I'd call it a bug.  I'll try and fix it soon.

> 2) Is there a way to create links to nodes in other .leo files? If
> so, it's not obvious how to do it.



I don't think you can do that with backlinks, unless I'm forgetting
something.  The bookmarks plugin can definitely do that.


Yeah, forgot about the bookmarks plugin. I have used that one before also.  

Also you probably know this, but the graphcanvas plugin visualizes the
links defined by the backlinks plugin.



That's an odd one. there's almost no documentation about it that I can find. It 
looks like it has potential for a sort of mind-mapping visualization, but it's 
really not intuitive how to make it work. Still slogging through trying to 
figure it out. For example, there's a mention to load pygraphviz or pydot for 
'layouts', but I got lost trying to figure out how to do either one. Links in 
the docstring to a blog post are dead.
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+...@ 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.
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.


   
 

-- 
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: Org Mode File - Node sorted by time stamp

['Terry Brown' via leo-editor]

Ok, I haven't used org mode import.
Seems like you wouldn't want the timestamps in the header, all you'd see in the 
tree view would be the timestamps.
Two possible approaches:
 - write a small piece of code to sort the nodes based on the timestamps in the 
body content. - import the org file taking advantage of Leo's todo plugin, 
which has date due fields and ui options to sort by them
Cheers -Terry
 
  From: Israel Hands <alist...@mcgh.ee>
 To: leo-editor <leo-editor@googlegroups.com> 
Cc: terry_n_br...@yahoo.com
 Sent: Tuesday, December 20, 2016 10:01 AM
 Subject: Re: Org Mode File - Node sorted by time stamp
   

Thanks Terry and Rob!
I realise I wasn't clear enough in my original post. Org mode allows todo items 
to be entered into a file in any order but they can include a timestamp of 
their 'scheduled' time (and indeed a separate deadline timestamp).  In the 
orgmode Agenda view the items are then inserted in to a linear calendar, 
turning the unordered org file into a powerful calendar/todo list.
So one of my org mode items is -  Breakfast with James - it has a scheduled 
time and I have chosen to set a deadline.  When I choose Agenda view in orgmode 
I see the item has a deadline in today's date and the item itself appears in 
the calendar for tomorrow.Imported into leo I get a nice node with the headline 
- Breakfast with James -  and the body text is the two time stamps - the 
deadline is Tuesday the 20th (to remind me it is tomorrow) and then the 
scheduled time of the event Wednesday the 21st at 10am.  The node body looks 
like this = 
   DEADLINE: <2016-12-20 Tue 09:00><2016-12-21 Wed 10:00>
However the nodes are listed according to their place in the orgmode file (in 
creation order) rather than schedule order. I guess it would require digging 
out these scheduled times and maybe writing them into the header which would 
then make it easy to sort the nodes.
Anyway thanks for your attention.IH

On Tuesday, 20 December 2016 15:07:39 UTC, Terry Brown wrote:
Depends what you mean by timestamps.  If you mean a piece of text in the 
header, one of the Outline -> Sort commands should work.
If you mean sort by the internal "gnx" ID attribute of the nodes, which 
contains timestamp information, I don't think there's a command to actually 
re-order nodes on that basis.  But there is a commandfind-quick-timeline which 
displays all the nodes in the outline in the Nav pane, ordered most recently 
created to oldest.  Maybe that helps?  find-quick-timeline uses the gnx info.
Cheers -Terry
 
  From: Israel Hands <alis...@mcgh.ee>
 To: leo-editor <leo-e...@googlegroups.com> 
 Sent: Tuesday, December 20, 2016 7:23 AM
 Subject: Org Mode File - Node sorted by time stamp
  
I use OrgMode's Agenda view as my basic calendar and it's great to be able to 
import the org files into leo, is there a way of sorting the imported nodes by 
time stamp, other than writing a bit of code to accomplish the task?
ta
Al-- 
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+...@ 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.
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.


   
 

-- 
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: Backlink plugin questions

['Terry Brown' via leo-editor]

I think all the things you pointed out are fixed in
https://github.com/leo-editor/leo-editor/commit/bf397a6e
let me know if that seem to be the case, or not.
Cheers -Terry

 
  From: Largo84 <larg...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Tuesday, December 20, 2016 8:29 AM
 Subject: Re: Backlink plugin questions
   
Thanks, Terry. While you're at it, can you see why the links don't show up 
right away until after refreshing, leaving the node and then coming back?

On Tuesday, December 20, 2016 at 8:08:58 AM UTC-5, Terry Brown wrote:

I'd call it a bug.  I'll try and fix it soon.

> 2) Is there a way to create links to nodes in other .leo files? If
> so, it's not obvious how to do it.



I don't think you can do that with backlinks, unless I'm forgetting
something.  The bookmarks plugin can definitely do that.


Yeah, forgot about the bookmarks plugin. I have used that one before also.  

Also you probably know this, but the graphcanvas plugin visualizes the
links defined by the backlinks plugin.



That's an odd one. there's almost no documentation about it that I can find. It 
looks like it has potential for a sort of mind-mapping visualization, but it's 
really not intuitive how to make it work. Still slogging through trying to 
figure it out. For example, there's a mention to load pygraphviz or pydot for 
'layouts', but I got lost trying to figure out how to do either one. Links in 
the docstring to a blog post are dead.
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.
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: Org Mode File - Node sorted by time stamp

['Terry Brown' via leo-editor]

Depends what you mean by timestamps.  If you mean a piece of text in the 
header, one of the Outline -> Sort commands should work.
If you mean sort by the internal "gnx" ID attribute of the nodes, which 
contains timestamp information, I don't think there's a command to actually 
re-order nodes on that basis.  But there is a commandfind-quick-timeline which 
displays all the nodes in the outline in the Nav pane, ordered most recently 
created to oldest.  Maybe that helps?  find-quick-timeline uses the gnx info.
Cheers -Terry
 
  From: Israel Hands 
 To: leo-editor  
 Sent: Tuesday, December 20, 2016 7:23 AM
 Subject: Org Mode File - Node sorted by time stamp
   
I use OrgMode's Agenda view as my basic calendar and it's great to be able to 
import the org files into leo, is there a way of sorting the imported nodes by 
time stamp, other than writing a bit of code to accomplish the task?
ta
Al-- 
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: Backlink plugin questions

['Terry Brown' via leo-editor]

On Tue, 20 Dec 2016 02:04:53 -0800 (PST)
Largo84  wrote:

> 1) I am using the backlink plugin more now and find that if I create
> links between nodes, the .leo file is not marked 'dirty', so the
> links don't survive if I close the file and reopen (unless I
> explicitly save the file or make other changes that prompt a file
> save). Is this intentional or a bug?

I'd call it a bug.  I'll try and fix it soon.

> 2) Is there a way to create links to nodes in other .leo files? If
> so, it's not obvious how to do it.

I don't think you can do that with backlinks, unless I'm forgetting
something.  The bookmarks plugin can definitely do that.

Also you probably know this, but the graphcanvas plugin visualizes the
links defined by the backlinks plugin.

Cheers -Terry

> Thanks in advance for ideas.
> 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: leo stalling for long periods

['Terry Brown' via leo-editor]

Sounds like a challenge, cross platform wise etc.
A unix command like `df -l` (disk free local) seems to know. But there are so 
many ways non-local files can be mounted, sshfs, Windows shares, etc.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Friday, December 16, 2016 12:23 PM
 Subject: Re: leo stalling for long periods
   
On Fri, Dec 16, 2016 at 11:11 AM, john lunzer  wrote:


Here is the issue in question. 
​
Thanks.  I've reopened it, and labeled it a Bug to denote its new status re 
network drives.

I am dithering about whether to make file check the default or not.  It may 
depend on whether it's possible to check whether a drive is a network drive or 
not. Does anyone know whether a check is possible?

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.


   
 

-- 
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: leo stalling for long periods

['Terry Brown' via leo-editor]

Looking around a bit more, looks like you can disable those file checks with
@bool check_for_changed_external_files = False

in @settings, I see I have that set to False on the machine where the 
checkswere causing trouble for me, try that and see if it helps.
Cheers -Terry

 
  From: Curtis Carlsen 
 To: leo-editor  
 Sent: Wednesday, December 14, 2016 1:32 PM
 Subject: Re: leo stalling for long periods
   
The file consists of hundreds of smaller nodes.  There may be a few large 
nodes, but I find the warning screen about the QT lost data bug annoying so I 
usually delete them.

The original file is my work diary, built up over many months.  It has lots of 
proprietary company data.  The boss would not be pleased with me sharing it.

I usually close out the diary files after about a year, because they get slow 
to work with.  But the symptoms this time are different.  Everything is running 
along fast and then just stops.  It kinda has the feel of a thread getting 
stalled by a locked resource.  I seem to recall some kind of issue with python 
getting locked up on multiprocessors because of a poorly designed global lock, 
I have no idea if that could actually be involved, but it's just something I 
remember.

-- 
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: leo stalling for long periods

['Terry Brown' via leo-editor]

If the nodes are small and it worked before, it's probably not size related - I 
was thinking of syntax highlighting, but that's probably not it.
Are any of the files you're working with non-local, i.e. on network file 
systems?  I've had trouble with that, and I think Leo started scanning loaded 
files for external changes recently.  Seems like that's a possibility.
You can set the threshold for seeing the QT lost data bug (bytes in a single 
node), if you don't think the bugs impacting you and you're seeing the warning 
too often.
If you're familiar with git, you could try running git bisect to find the exact 
commit that broke things.
Re Python and threads, Pyhton's GIL Global Interpreter Lock prevents more than 
one *thread* using CPU time at once.  But Leo's limited use of threading hasn't 
changed recently, that I know of... although on-idle handling did change not 
that long ago. 
 
  From: Curtis Carlsen 
 To: leo-editor  
 Sent: Wednesday, December 14, 2016 1:32 PM
 Subject: Re: leo stalling for long periods
   
The file consists of hundreds of smaller nodes.  There may be a few large 
nodes, but I find the warning screen about the QT lost data bug annoying so I 
usually delete them.

The original file is my work diary, built up over many months.  It has lots of 
proprietary company data.  The boss would not be pleased with me sharing it.

I usually close out the diary files after about a year, because they get slow 
to work with.  But the symptoms this time are different.  Everything is running 
along fast and then just stops.  It kinda has the feel of a thread getting 
stalled by a locked resource.  I seem to recall some kind of issue with python 
getting locked up on multiprocessors because of a poorly designed global lock, 
I have no idea if that could actually be involved, but it's just something I 
remember.

-- 
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: Theme Problems

['Terry Brown' via leo-editor]

You're right, themes seem to have been  completely nerfed.
ekr_dark_theme has a @data node, but it doesn't seem to work.

At one point there was infrastructure to build the @data node from a
Leonine tree outline of the theme.

I'll try and have a look at it.

Cheers -Terry

On Tue, 13 Dec 2016 11:48:32 -0800 (PST)
john lunzer  wrote:

> I'm testing on the current master as of today and themes are not
> working as advertised on Linux/Python3/PyQt4.
> 
> I can copy my old "theme" node headlined "leo_dark theme 0" from my
> daily driver version of Leo to my test master and it will load fine.
> 
> The important node to this "theme" is headlined @data 
> qt-gui-plugin-style-sheet, without that the theme does nothing.
> 
> In the current master the "reload-styles" command appears to do
> nothing, it doesn't generate the @data node.
> 
> It is interesting is that a great deal of the detail in the current
> master "leo_dark theme 0" seems to be missing compared to what I
> copied years ago. There used to be an "@button reload-styles" node
> contained in these themes which *does* successfully generate the
> needed @data node.
> 
> Themes used to work and it looks like there was possibly an attempt
> to simplify them and in the process now they don't work.
> 
> I would argue that themes are critical to overall Leo adoption and as
> long as this sits broken we risk losing new users.
> 
> On Tuesday, May 17, 2016 at 2:55:17 PM UTC-4, Edward K. Ream wrote:
> >
> > On Tue, May 17, 2016 at 1:33 PM, Mike Busch  > > wrote:
> >  
> >> I was able to get bg and fg colors to change with the Appearance 
> >> settings. As far as I can tell, Theme isn't read/used.
> >>  
> >
> > ​Good.  I do think your idea for a theme plugin would be useful.
> >
> > 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: leo stalling for long periods

['Terry Brown' via leo-editor]

On Mon, 12 Dec 2016 10:56:28 -0800 (PST)
Curtis Carlsen  wrote:

> I downloaded the new code base to try out the new importers.  (Leo
> 5.4, december 8th)
> 
> I am seeing extended stalling of different parts of the program,
> where everything freezes and the program does not respond to
> keypresses or mouse clicks.  The stall lasts for up to 30 seconds or
> a minute, then things start working again.  It seems to happen at
> random intervals.  I don't have to be doing anything, sometimes I am
> just looking at a node, or navigating the tree and it freezes.
> 
> I have seen it happen when editting nodes, and also when I am in the 
> file|import any menu item.  It doesn't really seem to matter what I
> am doing at the time.  And if I run leo from the terminal, I don't
> see any error messages there.  The file I am editting is fairly large
> (1.15 MBytes)

Hi Curtis,

Are you editing the whole 1.15 MBytes in a single node?  I think Leo
would struggle with that.  If not, then I'm not sure what might be
causing your problem.

If you do have everything in one node, you can probably break it up
with a layout like:

   @clean myfile.dat
"@others"
 node1
"text for node 1"
 node2
"text for node 2"
 node3
"text for node 3"

where the top node would literally just be "@others", but the other
nodes would be much larger chunks of text.

> I am running on Windows 7, python 2.7
> 
> If I revert to using leo 5.1 final from October 20th, the problem
> goes away.

Hmm, so it works in an earlier Leo... I guess we need a more detailed
description of what you're editing - if you could share the file that
would help.

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: Is it possible to suppress a section reference?

['Terry Brown' via leo-editor]

echo >> out.txt <> out.txt
both untested guesses.
Cheers -Terry

 
  From: Phil 
 To: leo-editor  
 Sent: Friday, December 9, 2016 11:35 AM
 Subject: Is it possible to suppress a section reference?
   
I have a shell script that contains the following line:

echo <> out.txt

Leo wants to treat <> as a section reference, which I obviously don't 
want. My workaround is to make the node an @asis node, but I'd prefer to 
suppress the section reference behavior for just that line so that I can make 
the file from an @clean node.

Any ideas?

Thanks,
Phil
-- 
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: Traveling to Florida

['Terry Brown' via leo-editor]

Have a great trip, heading for daytime highs in the 20s C / 70s F, leaving 
behind highs of -10 C / 10 F, can't imagine why you do it :-)

Cheers -Terry

 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Thursday, December 8, 2016 5:37 PM
 Subject: Traveling to Florida
   
Rebecca and I will be on the road to Florida starting tomorrow morning.  I'll 
have my laptop with me, and will be able to respond to emails.

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: Exception running Markdown_Importer

['Terry Brown' via leo-editor]

Just an observation, I'm using markdown quite a bit at the moment and not 
seeing that problem with
Leo 5.4, build 20161208140632, Thu, Dec 08, 2016  2:06:32 PM
Git repo info: branch = master, commit = 91bb3a5c8ef7Python 2.7.5, PyQt version 
4.8.5Windows 7 AMD64 (build 6.1.7601) SP1
so you must be using a construct that I'm not using.
Cheers -Terry
 
  From: Largo84 
 To: leo-editor  
 Sent: Friday, December 9, 2016 8:11 AM
 Subject: Exception running Markdown_Importer
   
Just got this one this morning on one file:
Exception running Markdown_ImporterTraceback (most recent call last):  File 
"D:\Synced\github repos\leo\leo\core\leoImport.py", line 915, in 
scanner_for_at_auto_cb    return scanner.run(s, parent, prepass=prepass)  File 
"D:\Synced\github repos\leo\leo\plugins\importers\linescanner.py", line 449, in 
run    self.generate_nodes(s, parent)  File "D:\Synced\github 
repos\leo\leo\plugins\importers\linescanner.py", line 513, in generate_nodes    
self.gen_lines(s, parent)  File "D:\Synced\github 
repos\leo\leo\plugins\importers\markdown.py", line 50, in gen_lines    
self.make_node(level, name)  File "D:\Synced\github 
repos\leo\leo\plugins\importers\markdown.py", line 146, in make_node    
self.find_parent(level=level, h=name)  File "D:\Synced\github 
repos\leo\leo\plugins\importers\markdown.py", line 89, in find_parent    return 
self.stack[level]IndexError: list index out of range
Anything else you need?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.
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: is there a command to turn off visual display of changes and then turn them back on?

['Terry Brown' via leo-editor]

My guess is using position methods is the way to go(*).  I think there's 
something about the way people come to Leo scripting that leads them down the 
c.k.simulateCommand path, but I'm not really sure that's intentionally.  My 
feeling is that c.k.simulateCommand is best for occasional limited use, not for 
the kind of thing you're doing. Complexity wise, the position methods are no 
harder to use than c.k.simulateCommand, when your script gets to the level 
yours has.
With the position methods there's typically no issue about unwanted display 
updates, you just need to remember to call c.redraw() when you're done.
(*) one caveat for programmatically generated trees - for large trees it's 
significantly faster to use vnodes instead of positions.  There's very little 
difference code wise, instead of
myNode = p.insertAfter()<< build big tree under myNode >>
it's basically
myNode = p.insertAfter().v<< build big tree under myNode >>
because most of the tree building methods positions have are available on 
vnodes too (.h, .b, .insertAfter(), etc.)
Cheers -Terry


 
  From: djc 
 To: leo-editor  
 Sent: Thursday, December 8, 2016 11:28 AM
 Subject: Re: is there a command to turn off visual display of changes and then 
turn them back on?
   
Sorrynot very well formatted question.
When I use the c.k.simulateCommand() method, it does an immediate redraw of the 
outline.  I would like to suppress the redraw until after I am done making 
changes.  I am looking at using position methods to do the same thing so that I 
control the redraw, but haven't had time to suss it out yet.  
Also, I have been doing some stress testing on large, programatically created 
outlines to see if there are scale limits in Leo.  I have found that Leo will 
crash if I use c.k.simulateCommand() on a large number of nodes in one function.
I don't want to report this formally until I have a chance to dig into it more, 
so this is just a heads up.
The specific code that I am working on is intended to build a journal with 
weekly text files.  This might be better served using a database, but I have 
some specific requirements that make Leo and interesting potential 
solution.and it provides a great opportunity to learn the ins and outs of 
the tool.
A code snip follows that illustrates what I am doing.  This code does cause Leo 
to hang, but not at consistent places in the operation, so I assuming that it 
is a memory problem; perhaps stack space, or garbage collector overflow, or 
some such.

monthNames = {"01-January","02-February","03-March","04-April","05-May",        
    
"06-June","07-July","08-August","09-September","10-October","11-November","12-December"}
    yr = 1960for np in c.all_positions():
    if (c.p.h[:5] == 'Year:'):        yr = int(c.p.h[-4:])        g.es(str(yr)) 
              c.k.simulateCommand('goto-next-visible') 
    if (c.p.h[:5] == 'Year:'):        c.k.simulateCommand('move-outline-right') 
                    if (c.p.h in monthNames):        
c.k.simulateCommand('move-outline-right')        
c.k.simulateCommand('move-outline-right')            elif (c.p.h[:1] == 'w'):   
     c.k.simulateCommand('move-outline-right')        
c.k.simulateCommand('move-outline-right')        
c.k.simulateCommand('move-outline-right')


On Wednesday, 7 December 2016 08:54:45 UTC-7, Edward K. Ream wrote:
On Wed, Dec 7, 2016 at 9:40 AM, djc  wrote:


Is there something like and echo_on and echo_off when using 
c.k.simulateCommand()?

​Not sure what you mean by "changes".

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: --diff: Leo as an external git diff

['Terry Brown' via leo-editor]

Check out Meld (http://meldmerge.org/) as well, it's pretty good.  Side by side 
text view.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Wednesday, December 7, 2016 10:33 AM
 Subject: Re: --diff: Leo as an external git diff
   
On Wednesday, December 7, 2016 at 10:12:39 AM UTC-6, Edward K. Ream wrote:

> Merge...The ideal would be the ability to cherry pick from within Leo.

A way must be found.  This is way too good to miss!

SourceTree has superb cherry-picking abilities.  I switched from SourceTree to 
gitk because SourceTree had severe performance bugs.  Maybe they have been 
fixed...

SourceTree presents diffs as a series of separate snippets.  For each snippet, 
you could choose whether to use the old or new version of the code.  You just 
press a button. SourceTree may do something similar for merges.

Clearly, Leo can do at least as well, without performance problems!  Indeed, 
Leo can diff huge files instantly because each node has a unique gnx.  Thus 
moves can be detected without effort, and O(N**2) diff algorithms work on 
smallish text, namely p.b. Outlines are the ultimate platform for diffs and 
merges!

Eventually, we may want a SourceTree-like interface for cherry-picking.  But 
that might not be necessary.  We can imagine a command like git-pick (applied 
to the desired code) or git-pick-mine, applied to an organizer node containing 
two or three variants of code.  Or maybe something even simpler :-)

It's hard to overstate how important this could be.  Heh.  Imagine 
non-Leonistas using Leo as the ultimate git diff/merge tool!

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.


   
 

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

Clones - what are they good for?

['Terry Brown' via leo-editor]

(How I feel about clones, YMMV)
Clones are really really good for creating task specific views of code, by 
gathering together all the nodes relevant to a particular development task, so 
you don't have to constantly scroll up and down the outline to get to the 
relevant pieces.  "Code" could be a manuscript or other non-computer related 
document that requires editing in multiple places.
Who uses them that way?  Well, Edward, certainly, and probably a lot of other 
people.  Clones are fairly safe to work with in this role, although I'm sure 
there are still ways they can have unexpected side effects. In this role, you 
typically only have one occurrence of each clone in a @file, the rest are in 
the Leo outline itself, but not in places written to external files.  This 
makes them less likely to bite.
What else do people use them for?  Template / snippet replacement for recurring 
elements like headers and footers in websites, blogs, and in code.  This seems 
to be the context that people most often (a) get lyrical about how unique Leo 
is for providing this great workflow, and (b) run into trouble because of the 
tricky nature of cross file clones.
I can see why people are attracted to clones for this second category of uses, 
but I'm really not sure they're the best choice. In code, wanting to repeat 
things may indicate bad design, you can usually define something somewhere and 
reference it by name in the manner appropriate to the language you're using. 
For things like website headers / footers, there are a lot of other ways 
without the extra load of avoiding cross file clone pit falls. Websites 
typically use some kind of templating system like 
http://jinja.pocoo.org/docs/dev/. And you can still leverage Leo to handle 
things like website headers / footers without clones. A *small* script could 
run through an outline generating web pages with common header / footer content 
pulled from Leo nodes.
Finally, for the task specific code view case, I prefer alternatives which may 
not be *quite* as fluid and seamless as clones (mainly for UI reasons), but 
have no sharp edges you need to be wary of. The bookmarks, tagging, and 
backlinks plugins are all options in this case, with the first two being 
particularly usable.
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: uA's as OrderedDict

['Terry Brown' via leo-editor]

On Fri, 2 Dec 2016 05:04:55 -0800 (PST)
Josef  wrote:

> On second thought, I realize, only the inner dict needs to be an 
> OrderedDict, and it is the plugin itself which is responsible for
> that - so no need to change the uA implementation.

Do you just want the plugin to display the attributes in alphabetical
order or in a user defined order

Weird I am testing Apache Guacamole and none of the punctuation keys
are working at all

-- 
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: where re-define default color? [was] how to setup Leo cursor size and highlight currently line?

['Terry Brown' via leo-editor]

Try these settings:
@color undefined_section_name_color = orange
@color section_name_brackets_color = orange
@bool underline_undefined_section_names = False

Cheers -Terry
 
  From: Zoom.Quiet 
 To: leo-editor@googlegroups.com 
 Sent: Monday, November 28, 2016 1:56 PM
 Subject: Re: where re-define default color? [was] how to setup Leo cursor size 
and highlight currently line?
   
On Mon, Nov 28, 2016 at 1:49 PM, john lunzer  wrote:
> Cursor size is as follows:
>
> create a node with headline:
>
> @int qt-cursor-width = 3
>
> under an @settings parent node. Obviously change 3 to however big you want
> the cursor.
>

thanx for u suggest ;-)
but i need to change the default color for  < and > of <> case
because ,i custom the dark theme, the default color not clean enough.

>
> As for highlighting the current line I do not know how this is done.
>
> On Sunday, November 27, 2016 at 6:25:07 PM UTC-5, Zoom.Quiet wrote:
>>
>> as atta. snap.
>> base john lunzer  suggest config:
>> ~/.leo/myLeoSettings.leo#@settings-->Syntax
>> coloring-->Language-specific colors-->Python
>>
>> reply-to: leo-e...@googlegroups.com
>> to: leo-editor 
>> date: Sat, Apr 16, 2016 at 4:19 AM
>> subject: Re: [theme] how to setup Leo cursor size and highlight currently
>> line?
>>
>> @color blank_color = grey
>> @color tab_color = red
>> @color label_color = red
>> ...
>>
>> i got pretty dark-theme in macOS, but like <>
>> the <<>> usage default color, not good enough,
>> but i can not found, where can re-define it...
>>
>> thanks for any suggest.
>>
>>
>> On Sat, Apr 16, 2016 at 11:33 AM, Edward K. Ream 
>> wrote:
>> >
>> >
>> > On Sat, Apr 16, 2016 at 11:20 AM, Zoom.Quiet  wrote:
>> >>
>> >> thanks again , and i sharing the custom story as:
>> >> Leo 5.2 theme custom — Medium
>> >>
>> >>
>> >> https://medium.com/@zoom.quiet/leo-5-2-theme-custom-d6f77573b7d6#.wvihrt11x
>> >
>> >
>> > Looks good :-)
>> >
>> > Edward
>>
>>
>> --
>> life is pathetic, go Pythonic! 人生苦短, Python当歌!
>> 俺: http://zoomquiet.io
>> 授: http://creativecommons.org/licenses/by-sa/2.5/cn/
>> 怒: 冗余不做,日子甭过!备份不做,十恶不赦!
>> KM keep growing environment culture which promoting organization be
>> learnning!
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.



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

-- 
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: The new markdown importer is ready for real testing

['Terry Brown' via leo-editor]

On Sat, 26 Nov 2016 09:36:34 -0800 (PST)
"Edward K. Ream"  wrote:

> Rev cc5b28b3 completes all planned work on the markdown importer,
> including some subtle cases.  Please report any problems immediately.

Not sure if this work was related to my md bug report, but I'll try and
test the new importer with that file soon.

Cheers -Terry

> The new test-driven development work flow is working very well in
> typical cases.  A few rough edges remain, but they did not affect me
> today.  I estimate that the new work flow is about twice as efficient
> and pleasant as the old, especially during heavy-duty debugging.
> 
> I'll write up my experiences in detail in another thread, but now
> it's time for a break...
> 
> 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: Distribution Environment

['Terry Brown' via leo-editor]

On Tue, 22 Nov 2016 07:25:22 -0800 (PST)
Chris George  wrote:

> Now running Python 3.5.2 and PyQt 5.6.0 and this is what I get. 

Poking at leoQt - guessing immediately before this traceback it said
'leoQt.py: can not fully import PyQt5.' ?

It seems leoQt doesn't necessarily handle /partial/ failures when
trying to import - although really there is probably no way to handle
these other than reporting exactly what failed, and then crashing.

Cheers -Terry

> Traceback (most recent call last):
> >   File "./launchLeo.py", line 8, in 
> > leo.core.runLeo.run()
> >   File "/home/chris/leo-editor/leo/core/runLeo.py", line 63, in run
> > g.app.loadManager.load(fileName, pymacs)
> >   File "/home/chris/leo-editor/leo/core/leoApp.py", line 1951, in
> > load lm.doPrePluginsInit(fileName, pymacs)
> >   File "/home/chris/leo-editor/leo/core/leoApp.py", line 2014, in 
> > doPrePluginsInit
> > lm.createGui(pymacs)
> >   File "/home/chris/leo-editor/leo/core/leoApp.py", line 2039, in
> > createGui lm.createSpecialGui(gui_option, pymacs, script,
> > windowFlag) File "/home/chris/leo-editor/leo/core/leoApp.py", line
> > 2054, in createSpecialGui
> > g.app.createDefaultGui()
> >   File "/home/chris/leo-editor/leo/core/leoApp.py", line 989, in 
> > createDefaultGui
> > app.createQtGui(fileName, verbose=verbose)
> >   File "/home/chris/leo-editor/leo/core/leoApp.py", line 1009, in 
> > createQtGui
> > import leo.plugins.qt_gui as qt_gui
> >   File "/home/chris/leo-editor/leo/plugins/qt_gui.py", line 12, in
> >  import leo.plugins.qt_big_text as qt_big_text
> >   File "/home/chris/leo-editor/leo/plugins/qt_big_text.py", line 6,
> > in 
> > import leo.plugins.qt_text as qt_text
> >   File "/home/chris/leo-editor/leo/plugins/qt_text.py", line 413,
> > in 
> > class LeoLineTextWidget(QtWidgets.QFrame):
> > AttributeError: 'NoneType' object has no attribute 'QFrame'

-- 
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: Why I don't use Leo more often

['Terry Brown' via leo-editor]

I'd find a console interface really useful as well. I know about sshfs and that 
can help in some cases, but there are cases where Shell-in-a-box (web based 
shell client) is about a much access as you can usefully get, and then console 
Leo would be great (console apps. like nano and mc work, so it has good console 
support).
Leo has an interface abstraction layer like you refer to John, but I think 
you're right that you don't really test something like that without the 
existence of multiple active interfaces. Then of course there are plugins, a 
lot of them go straight to native Qt, inevitably.  But even console leo with no 
plugins would be pretty cool.
Some of Leo's strengths make things more challenging, key handling that works 
not just in the body text but in some widgets (esp. headlines) too, that kind 
of thing.
Where's the sweet spot between a de novo interface that just uses leoserver to 
push things into and out of Leo, or Leo's internal abstraction so that there's 
at least the potential for something to work across interfaces.
Cheers -Terry
 
  From: john lunzer 
 To: leo-editor  
 Sent: Friday, November 18, 2016 11:13 AM
 Subject: Why I don't use Leo more often
   
I use Leo as my primary editor when I can.
When I can't is when I'm SSHing into machines remotely where it is often not 
practical (or desirable) to run GUI applications. I believe there was some work 
done on a curses front-end plugin in the past but I'm not sure how far that got.
I would eventually like to see a full fledged console front-end for Leo. I have 
no illusions about it popping up by magic.
I would only say, if, by chance, work begins on a new web-based front-end, that 
might be an opportunity to rework/simplify the back-end interface/API which 
would work towards the "leo as a plug-in" long term goal. This might make it 
easier to implement a console front-end with something like urwid.
Emacs can be run in a daemon mode where multiple front-end clients can connect 
to a single instance of an emacs "server". I envision a future Leo with a 
similar capability, where a back-end/front-end protocol is devised and you 
could connect any number and type of front-end clients to the back end.-- 
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: 97587a8: The new python importer is now active

['Terry Brown' via leo-editor]

On Thu, 17 Nov 2016 11:10:20 -0800 (PST)
"Edward K. Ream"  wrote:

> Rev 97587a8 leaves the python.v2 switch ON, which enables the new 
> line-oriented python importer.
> 
> The code passes 30+ python-related unit tests, but bugs could still
> lurk. Please report any problems immediately.

Quick look it seems good.

I tried changing all the @file headline text to @auto in LeoPy.leo to
see if it could import the Leo codebase, but the experiment's not that
straight forward.  Maybe you'd have a better idea of what would be
needed to make that test work.

Some files that already were @auto seemed good though.

> Giving my hands a rest is now urgent, so I'll take a break from
> programming for several days.

That's not what `git log` says :-}

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: Python Anywhere

['Terry Brown' via leo-editor]

As far as I know there's no "Qt in a browser window" stack. So if Flexx is a 
Python event callback style interface that renders in a browser, it could be a 
useful start.  Because it would allow the Python interpreter to be in one place 
(your home / office / cloud) and the browser to be wherever you are (phone, 
shared computer, etc.).
I didn't see the two most important widgets, tree and text editor, in the Flexx 
demos, but not sure if they're in Phosphor?  If that's even relevant?  The 
JupyterLab demo looked pretty good.
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Monday, November 14, 2016 1:30 PM
 Subject: Re: Python Anywhere
   


On Sun, Nov 13, 2016 at 12:39 PM, john lunzer  wrote:


In this way you could host your Leo from your home/work computer or a cloud 
instance. The thought of this is pretty exciting to me.


​I'm trying to understand what the benefits are.  If only the gui changes, Leo 
will still be tied to a traditional platform.  Why would we prefer the Flexx 
rendering to the Qt rendering?

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: A new pattern for me: `s.isspace()` instead of `not s.strip()`

['Terry Brown' via leo-editor]

That tripped me up too, empty strings are OK if you're using 'not s.isspace()'.
Cheers -Terry

On November 12, 2016 11:10:50 AM CST, rengel  
wrote:
> 
>
>> Instead of testing:
>>>
>>
>>if not ''.join(lines).strip():
>>
>> the new code now tests:
>>
>> if all([z.isspace() for z in lines]):
>>  
>>
>What do you want to accomplish?
>The code 'z.isspace()' fails if a line is completely empty. Test:
>
>print(''.isspace()) # Fails
>>> print(' '.isspace())
>>> print('   '.isspace())
>>>
>>>
>#!/usr/bin/python
># -*- coding: UTF-8 -*-
>
>import re
>
># A test string, several blank lines
>s1 = """
>
>   abc   
>   
>   """
>
>s2 = """
>
> 
>
>   """
>
># Show the strings s1, s2
>print(s1, len(s1), s1.count('\n'))
>print(s2, len(s2), s2.count('\n'))
>
># Create lines from s1, s2
>lines1 = s1.split('\n')
>lines2 = s2.split('\n')
>
># Show the lines
>print(lines1)
>print(lines2)
>
># EKR test, fails if a line is empty (= contains only '\n')
>print(all([z.isspace() for z in lines1]))
>print(all([z.isspace() for z in lines2]))
>
># Using regular expression
>print(re.match('^\s*$(?s)', s1))
>print(re.match('^\s*$(?s)', s2))
>
>
>
>-- 
>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: A new pattern for me: `s.isspace()` instead of `not s.strip()`

['Terry Brown' via leo-editor]

On Fri, 11 Nov 2016 08:12:57 -0800 (PST)
"Edward K. Ream"  wrote:

> On Thursday, November 10, 2016 at 12:48:28 PM UTC-6, Edward K. Ream
> wrote:
> >
> > Up until today, I have always tested for an empty string using not 
> > s.strip().  But Doh, this is an unnecessary stress on the GC.  
> > `s.isspace()` much faster and more pythonic.
> >  
> 
> As another aspect of this pattern, instead of testing,
> 
>if ''.join(lines):
> 
> the new code now tests:
> 
> if all([z.isspace() for z in lines]):

Those don't seem equivalent - the first is true if any of lines is
anything other than "", the second only if all lines are whitespace,
and none are "".  But I suspect these were typed into email, rather
than copy pasted from code?

Cheers -Terry

> This is much faster (it should run close to C speed) and generates
> *no* additional strings for the GC to recycle.
> 
> 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: The coffeescript importer was broken recently

['Terry Brown' via leo-editor]

> I'll be writing more about the new importers in an "info" github issue.
> This issue probably should remain open indefinitely.​
If any of the concerns re GitHub being a private company that could start 
charging or whatever whenever eventuate, it's useful to think about git vs. 
GitHub add ons.
A permanently open issue on GitHub would be ok, but a better fit might be a 
wiki page on GitHub - each project has its own wiki space.  However, I'd argue 
for a third option, a hierarchy of .md files in the Leo repo. in an appropriate 
subdir. Two reasons - it's part of the repo. then, zero issues should Leo ever 
leave GitHub, and also, perhaps more importantly, last time I checked, searches 
on GitHub don't search the wiki pages, while they do search repo. files.
Remember that GitHub will render .md files in the repo., and you can edit them 
through GitHub there, so editing / viewing experience is similar.
You can download both wiki (as a separate git repo.) and issues (in some JSON 
API format I think) from GitHub, should you be leaving GitHub, but the format 
of the issues in particular has work involved in making it into searchable 
docs. again.
Cheers -Terry

 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Wednesday, November 9, 2016 11:31 AM
 Subject: Re: The coffeescript importer was broken recently
   
​​On Wed, Nov 9, 2016 at 9:00 AM, Edward K. Ream  wrote:

Actually, it might have been broken for a long time.

I've just noticed that the coffeescript importer had disabled the perfect 
import checks, so running its unit tests was essentially useless.  I've hooked 
up the tests now and they are failing.  I'll fix them today.


​Done at 8fd9109.

The work on the new importers is going spectacularly well. The code has 
completely collapsed. There is no longer any confusion about method names or 
location.  It's all amazingly simple.  But it hasn't been easy to create this 
simplicity.  I could not have done it without Leo.

For the first time I see that importers are all about leading whitespace. 
Splitting the input lines into separate nodes is secondary.

I'll be writing more about the new importers in an "info" github issue.  This 
issue probably should remain open indefinitely.​

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.


   
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Use the GitHub issue tracker instead of this forum

['Terry Brown' via leo-editor]

Although I'd probably recommend Gmail on line in general for email management, 
I use Clawsmail, http://www.claws-mail.org/, which is fast and extensible.
I added a button to let you write email in restructuredText, along with colored 
syntax highlighting via. Pygments.  A long time ago, I'd have used MarkDown if 
I'd done it more recently.  It has preview as well.
But a lot of the time I'm using Yahoo mail on line, which is horrible, hence 
the top posting and HTML :-/
Cheers -Terry
 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, November 8, 2016 10:44 AM
 Subject: Re: Proposal: Use the GitHub issue tracker instead of this forum
   
On Sunday, November 6, 2016 at 8:01:53 AM UTC-6, Edward K. Ream wrote:
Several high-profile projects now use GitHub their issue tracker for all 
discussions.

There are substantial benefits to doing so, as I have just discovered:


The advantages of composing in GitHub are huge. I'll be posting all long posts 
there, including my Engineering Notebook posts

I particularly like the preview, edit, strikethrough and code listing 
capabilities. Being able to separate a long post into separate comments is also 
important.  I can even more text from one comment to another.

Finally, the GitHub editor feels much easier to use and looks way better.

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.


   
 

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

['Terry Brown' via leo-editor]

On Sun, 6 Nov 2016 20:19:54 -0800 (PST)
Chris George  wrote:

> Just noticed this: I use python 3.5.2 constantly. I already knew that
> PyQt 5.7 breaks viewrendered. Working on it a bit, so does PyQt 5.5.1.
> 
> But 5.6 works just fine.
> 
> Chris

There's definitely some finicky stuff with the Py 3 / Qt 5 setups.  I'd
observed a failure to start from Leo for a while under some
circumstances, not including the script I usually run it from.

Finally pinned it down, With Python 3 and Qt 5

Python 3.5.2, PyQt version 5.5.1

python3 launchLeo.py ~/.leo/del.leo  -> segfault
python3 launchLeo.py --no-splash ~/.leo/del.leo  -> runs normally

Python 2.7.12, PyQt version 5.5.1

works with and without --no-splash

I messed around with the splash window code, keeping references to
things that had no explicit reference, etc. etc., nothing helped.

If others can confirm the segfault with Python 3.5.2, PyQt version 5.5.1
(Ubuntu 16.04) splash should probably be disabled for that combo.

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: Proposal: Use the GitHub issue tracker instead of this forum

['Terry Brown' via leo-editor]

On Sun, 6 Nov 2016 06:03:51 -0800 (PST)
"Edward K. Ream"  wrote:

> On Sunday, November 6, 2016 at 8:01:53 AM UTC-6, Edward K. Ream wrote:
> 
> Several high-profile projects now use GitHub their issue tracker for
> *all* 
> > discussions.
> >
> > There are substantial benefits to doing so:
> >  
> 
> 4. And it's possible to change the name of the issue, unlike here.
> 
> 5. It's easy to categorize and prioritize discussions.
> 
> I'm sure there are more benefits.  Anyone see any problems?
> 
> EKR

Personally I'd be fine with that, but I think it will be hard to get
more than 50% adoption, so things will still be split.  E-mail lets
people pick their own environment, rather than requiring use of the
GitHub web interface.  Well, maybe that's not a requirement seeing
you can subscribe to all issues and get them in your email, but I think
you'd at least have to start the thread with the GitHub web interface.

Looking at it just now, it doesn't seem to handle nested quoted replies
properly.  In fact quoting in replies isn't really obvious at all.  You
select the text you want to reply to (can't see how to skip this when
you want to quote the whole message) and hit `r`.  But any quoting
already present in the selecting text is lost.

Another drawback is that people who aren't subscribed to all issues as
you and I are won't see them on the mailing list - fine if GitHub
replaces the mailing list, but I don't think it will or should, for the
same reasons I don't think we should insist on using git to get Leo
(other than version releases).  Use of GitHub is by no means universal
even among programmers, and Leo has a lot of non-programmer users.

So... it would work for me, quoting issues aside, but not sure it's a
one stop solution.  OTOH in the past people asking questions / starting
discussions of possible bugs on GitHub have been told to not open
non-bug issues without discussing in the forum first, I think it's a
step forward if we just respond to those threads on GitHub - it's not
just for bugs... which is I guess your original point :-)

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: Leo as Personal Information Manager: multiple nodes in the body pane?

['Terry Brown' via leo-editor]

I think this makes sense, and has been addressed a couple of times.
First a terminology issue: the body pane edits the body of a node, what you're 
looking for is a pane which lets you edit the bodies (and maybe headlines) of 
multiple nodes at once, which would a pane with a different name, distinct from 
the body pane.  I'm sure you don't care what it's called :-)
The closest to exactly what you want would be the notebook.py plugin, here's 
its doc string:
QML NotebookEdit several nodes at once, in a pannable "notebook" view.Use 
nb- to see the list of commands.
But I don't know if it's still working.
For a view only version of what you want, some iterations of the 
viewrendered[23]? plugin have supported recursive rendering, which would 
basically display a bunch of separate nodes as one long text.
If you can try the notebook.py plug in and report back, that would be a good 
start. Ville wrote it, which isn't really relevant, I just want to see if he's 
still reading this forum ;-)
Cheers -Terry
 
  From: Arjan 
 To: leo-editor  
 Sent: Friday, November 4, 2016 12:43 PM
 Subject: Leo as Personal Information Manager: multiple nodes in the body pane?
   
Hi! I'm getting started with Leo as a personal information manager, and I like 
it a lot. The option to have clones of notes which stay in sync is very 
powerful.
I do have a usability problem with it: I very often have small sections, e.g. a 
paragraph, that I want to be able to reuse somewhere else. This means I have to 
create many small nodes, meaning I loose the overview of the whole section (say 
a chapter, or whatever larger container of information). Of course I have an 
overview of the structure (the chapter's child nodes) in the outline pane, but 
that doesn't give me an overview of the actual text in it. For something like a 
chapter I want to be able to see and edit all the text in it, and just scroll 
through all of it. For example, I might want to write something in one of the 
child nodes while looking at the contents of other adjacent nodes. Or 
copy-paste things between them, which now requires switching between the child 
nodes.
So I was wondering: would it be possible to have multiple nodes in the body 
pane? If so, there could perhaps be a setting per node saying whether all its 
child nodes should be rendered (and be editable) in the body pane.
Does that make any sense? Or are there other ways to someting like this? I'm 
curious to hear your thoughts!-- 
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: graph-toggle-autoload

['Terry Brown' via leo-editor]

On Fri, 28 Oct 2016 16:08:01 -0700 (PDT)
lewis <lewisn...@operamail.com> wrote:

> Your use pattern is working fine and makes sense. It would be helpful
> if some basic user guides were added to the Graphcanvas docstring.
> And also for 'graph-toggle-autoload'. 
> Help-For-Command F11 reports ''no docstring available.

I've documented 'graph-toggle-autoload' in the plugin and command doc
strings.

Cheers -Terry

> Lewis
> 
> On Thursday, 27 October 2016 09:30:35 UTC+11, Terry Brown wrote:
> >
> >
> > How well does it seem to perform using the above pattern?
> >  
> 

-- 
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: graph-toggle-autoload

['Terry Brown' via leo-editor]

Just for same pageness, the intended use pattern is:
You have a graph you want displayed when the outline's loaded. You select the 
"top" node, run 'graph-toggle-autoload', and you're done.  From now going 
forward, the graph anchored by the node you had selected will be loaded 
automatically.  It's basically a one time thing.  You'd only run it again to 
cancel autoloading, or select another "top" node.
That's the intended use pattern, whether it works or not is another issue, but 
just wanted to make sure that's the way you're trying to use it, the methods 
you list sound a bit different.
How well does it seem to perform using the above pattern?  When I was restoring 
it's functionality after it was briefly disabled by some other fixes the other 
day, it seemed to be working as above, but I didn't test it very hard.
Cheers -Terry
 
  From: lewis 
 To: leo-editor  
 Sent: Wednesday, October 26, 2016 6:31 AM
 Subject: graph-toggle-autoload
   
I've noticed the 'graph-toggle-autoload' command doesn't load graphs 
consistently.

Method 1:  Load leo file, Run the 'graph-toggle-autoload' command and select 
the Graph tab, the graph is not visible.
I need to use the node/sibs/recur/ commands to load the graph to a visible 
state. 

Method 2: If I run the 'graph-toggle-autoload' command, close the file, then 
reload, select the Graph tab; the graph is partially visible
i.e. Out of four nodes, only one node and it's siblings are visible.

The command toggle is working because if I run it again 'Cleared - no graph 
will be autoloaded' and reload the leo file, no part of the graph is visible.

Leo Log Window
Leo 5.4, Wed Oct 26 10:09:28 2016
Git commit: 3efc8157
Python 3.5.2, PyQt version 5.6.0
Windows Vista x86 (build 6.0.6002) SP2
reading: N:\leo\DServe_Eff_Filters.leo
read outline in 0.12 seconds
Graph for current node will be autoloaded

Regards
Lewis
-- 
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: Graphcanvas crashes Leo

['Terry Brown' via leo-editor]

On Mon, 24 Oct 2016 02:24:16 -0700 (PDT)
lewis <lewisn...@operamail.com> wrote:

> Hi Terry,
> 
> Good news, I successfully exported a PNG file, and more than once!
> Your work on this plugin is appreciated.
> For this test please note I have switched to a laptop running
> PyQt5.6.0
> 
> However later when I used the 'Clear formatting' button I managed to
> crash Leo. Here is the console:

Ok, thanks, fixed that in 68548f0.

There's definitely something change with exception handling.  Or
something related.

python launchLeo.py ~/.leo/del.leo

starts Leo, del.leo is my testing outline.  This is Python 2.7.12, PyQt
version 5.5.1.  Prior to my fix in 68548f0, I get Lewis's crash to console.

python3 launchLeo.py ~/.leo/del.leo

seg-faults without starting (splash is displayed)

But using the script I usually use to start Leo, it runs with
Python 3.5.2, PyQt version 5.5.1 and while I see Lewis's traceback in
the console, Leo doesn't crash.  That's what I'm talking about when I
say I think Leo's recently become more crashable by these kind of bugs.

But it's not something you can pin down with git bisect, I think it's
probably also related to Python and Qt versions, particularly the
recent(ish) jump from Qt 4 to 5 for Python 2.7 deployments.

Cheers -Terry

> *Leo 5.4, Mon Oct 24 09:25:33 2016*
> *Git commit: f78504fc*
> *Python 3.5.2, PyQt version 5.6.0*
> *Windows Vista x86 (build 6.0.6002) SP2*
> *reading settings in N:\leo\DServe_Eff_Filters.leo*
> *Traceback (most recent call last):*
> *  File "N:\git\leo-editor\leo\plugins\graphcanvas.py", line 167, in 
> *
> *u.btnClearFormatting.clicked.connect(lambda checked: 
> o.clearFormatting())*
> *  File "N:\git\leo-editor\leo\plugins\graphcanvas.py", line 1341, in 
> clearFormatting*
> *item.bg.setBrush(QtGui.QBrush(QtGui.QColor(200,240,200)))*
> *AttributeError: 'QGraphicsPixmapItem' object has no attribute
> 'setBrush'*
> 
> Later I will repeat the testing back on my win10 desktop and report
> the progress.
> 
> Regards
> Lewis
> 
> On Monday, 24 October 2016 09:26:17 UTC+11, Terry Brown wrote:
> >
> >
> > Gah, ok, try f78504f 
> >
> > 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: Graphcanvas crashes Leo

['Terry Brown' via leo-editor]

On Sun, 23 Oct 2016 14:27:19 -0700 (PDT)
lewis  wrote:

> Pressing the 'Export' button (Export the graph as a PNG) crashes Leo.

Gah, ok, try f78504f

Cheers -Terry

> Here is the traceback:
> 
> *Git commit: ec8c3088Python 3.5.2, PyQt version 5.7.0Windows 10 AMD64 
> (build 10.0.14393) SP0reading settings in 
> N:\leo\DServe_Eff_Filters.leoreading settings in 
> N:\leo\workbook.leoTraceback (most recent call last):  File 
> "N:\git\leo-editor\leo\plugins\graphcanvas.py", line 179, in
>  u.btnExport.clicked.connect(lambda checked:
> o.exportGraph())  File
> "N:\git\leo-editor\leo\plugins\graphcanvas.py", line 1286, in
> exportGraphselectedFilter="Images (*.png)",TypeError:
> getSaveFileName(parent: QWidget = None, caption: str = '', directory:
> str = '', filter: str = '', initialFilter: str = '', options:
> Union[QFileDialog.Options, QFileDialog.Option] = 0): 'selectedFilter'
> is not a valid keyword argument*The other buttons are now stable *.*
> Regards
> Lewis

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