Re: About zoom vs leo-editor

[john lunzer]

Sometimes it's just *nice* to talk to someone.

On Tuesday, March 31, 2020 at 12:06:05 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, Mar 31, 2020 at 10:19 AM Matt Wilkie  > wrote:
>
> To my mind face-to-face and text and audio and video each have their 
>> merit, and each with their own most appropriate applications. And all best 
>> used in augmentation with their bretheren rather than supplanting.
>>
>
> I agree. I think I was over-weighting the importance of proximity.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/196b6b30-5791-4660-8f24-6339f9b27e86%40googlegroups.com.

Re: Zettelkasten - Notes Jim but not as we know them.

[john lunzer]

The "clone find" family (clone find flat seems more popular) of commands 
achieves this without the need for new functionality. 

If you wanted "everything else to disappear" you could hoist the parent 
node created by "clone find". Personally I find hoisting to have somewhat 
limited utility, it is not very arduous to focus on a single subtree.

With very little scripting these two actions could be combined into a 
single command. With no scripting one can simply execute the commands one 
after the other.

I am sure there are at least 3 other ways to achieve similar results, but 
this has the least amount of fan-fare, scripting, and keystrokes. 

On Friday, January 10, 2020 at 9:00:23 AM UTC-5, Israel Hands wrote:
>
> Use a hash before a word - #ThisIsATag and the note becomes tagged with 
> the tag. Click on the tag and all other notes instantly disappear  from the 
> tree. It's not really a tree you see  but a search bar.
>
> I tentatively think this would be cool in Leo 
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/837d3584-fbae-4d4d-854a-7a6028454cf4%40googlegroups.com.

Re: Reusing design and code: the clash of cultures

[john lunzer]

This is going to be one of the most important areas of research and 
development moving forward in the coding world. As the amount of code 
multiplies and the number of languages balloon we will be increasingly 
crushed under the weight of our own creations. Advancements in version 
control have helped to keep us above water, but it's not enough. General 
purpose forensic coding tools are going to be needed. Leo has made great 
strides to fill this role and I'm excited to see how it evolves to further 
tackle these challenges. 

On Wednesday, February 12, 2020 at 7:50:17 AM UTC-5, Edward K. Ream wrote:
>
> On Wednesday, February 12, 2020 at 6:01:31 AM UTC-6, Edward K. Ream wrote:
>
> > Leo is close to perfect for me.
>
> My overarching goal has always been to create a tool that helps people 
> understand computer programs in all their unavoidable complexity. That's 
> still true.
>
> A lot has changed since 1980 :-) Our language tools are so much better 
> now. That helps, but not enough.
>
> I'm always looking for new tools to add to Leo. The clone-find commands 
> were a huge step forward. I'm looking for others.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/832e2c97-961b-415a-b4ef-a523707ba431%40googlegroups.com.

Re: Reusing design and code: the clash of cultures

[john lunzer]

Your plan of careful consideration here is warranted, lest these become 
distractions. As my area of expertise is emacs these days and I regularly 
use org mode I would argue heavily against Leo's interaction with emacs, 
though it doesnt' seem that you need much convincing. The emacs culture is 
steadfast and the org-mode sub-culture more so. It is not worth one's time 
to bring Leo to emacs/org as that culture is happy with what they have. It 
is *perhaps* worth one's time to bring some of org to Leo, but this can be 
done via "feature borrowing" as opposed bridging. 

With regards to Leo and emacs the focus, if any, should be on an org-mode 
importer and exporter. I believe these already exist but in what state I 
can't say, if there are improvements that can be done and it is interesting 
to you then go ahead, I believe any work towards these would be beneficial 
to Leo's universal utility. That said I don't think this work is a high 
priority.

You also make a good point about Flexx's short comings. I was hoping that 
Flexx would continue to be developed and it was looking like it would but 
Almar Klein has all but abandoned the project in favor of his own QT based 
editor. It's too bad, for a while it almost felt like Flexx was the future 
of Python UIs. 

You're doing great and Leo is doing great without the constant barrage of 
"I wish Leo did this" requests. Leo's legacy will be more affected by your 
day to day collapsing of complexity than anything else. New features are 
great but streamlining Leo's current capabilities offers more value. 

On Tuesday, February 11, 2020 at 10:02:05 AM UTC-5, Edward K. Ream wrote:
>
> This post summarizes recent thinking. It's not a new topic:
>
> - #1409 : About 
> comm bridges.
> - #1389:  Create a 
> comm bridge between org mode and Leo.
> - #906 : Dubious 
> major projects.
>
> This post revisits these topics, and attempts to come to simple, correct 
> conclusions.
>
> *Each program creates its own culture*
>
> This is a fundamental fact. It's easy to minimize it's importance:
>
> *- Pyzo *lacks a minibuffer and a plugin architecture. pyzo is unsuitable 
> as a host for Leonine operation.
>
> *- Emacs *is based on elisp. Using Leo's bridge would be a performance 
> bottleneck. Emacs already has half-baked alternatives to outline structure 
> throughout.
>
> *- Web browsers* are limited environments. The leoflexx.py plugin has 
> unavoidable problems with key strokes.
>
> *The way forward*
>
> Other programs do have desirable features. I must first consider how their 
> design interacts with Leo. 
>
> It may be possible to reuse parts of pyzo's *code*, but this should be 
> done by taking small steps. For example, #1283 
> .
>
> *Summary*
>
> I have been tempted, over and over again, to merge Leo's features into 
> other coding environments. This is generally a bad idea.
>
> Before succumbing to "feature envy" it's important to recognize Leo's 
> unique strengths, and to consider how the culture of other programs affects 
> what they can and can't do. Many "missing" features in Leo aren't necessary 
> because of Leo's strengths.
>
> Edward
>
> P.S. I would like to say a few words about what might have been.
>
> Leo's history, and my own personal history, would likely have been very 
> different had I understood emacs 30 years ago. I might have avoided much of 
> the tedious work creating a separate editor/ide.
>
> But would Leo have been better in the long run? Would it have been more 
> popular? It's impossible to know.
>
> The most important question is whether Leo's devs would have found Leo:
>
> - Without Bernhard Mulder, @clean would not exist.
> - Without e, there would be no @button.
> - Without Kent and Ville, the unified vnode world would not exist.
> - Without Ville, the ipython plugin would not exist.
> - Without Terry, the todo plugin, and several others, would not exist.
> - Without Vitalije, Leo would still be using file caching.
> - Without Joe Orr, leovue would not exist.
>
> And on and on...
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3e745c5e-6526-4b5d-a4be-7fcf55f86711%40googlegroups.com.

Re: Qt is changing their licensing policies

[john lunzer]

I think it's too early to tell. In addition they may post yet another 
policy change in reaction to user reactions, so speculation is probably not 
worth it at this point. 

On Tuesday, January 28, 2020 at 12:33:02 PM UTC-5, SegundoBob wrote:
>
> Qt Blog: Offering Changes 2020 
> 
>
> The above link was on Hacker News yesterday.  What does it mean for 
> Leo-Editor?
>
> SegundoBob
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a19711cf-73dd-4245-b6da-b30008433223%40googlegroups.com.

Re: Leo for organizing notes?

[john lunzer]

Chapters are indeed useful and are generally speaking a more organized type 
of hoisting. They're not often discussed so I would also encourage checking 
them out as a means of organization.

On Saturday, January 25, 2020 at 11:50:23 PM UTC-5, Thomas Passin wrote:
>
>
>
> On Saturday, January 18, 2020 at 8:45:08 PM UTC-5, Chris George wrote:
>>
>>
>> Using clones you can create whatever organizational scheme you like. Add 
>> in a couple of plugins, like bookmarks, tags, and backlinks, and that 
>> ability explodes.
>>
>> One Leo feature for organization that I use a lot is called "chapters".  
> A chapter is a kind of grouping where you can collect nodes that you think 
> belong together.  There is a select box titled "Chapters".  When you select 
> a chapter in it, the outline pane will only show the headline nodes for 
> that chapter.  Searches, though, can still search the entire Leo file if 
> you want them to.
>
> To create chapters, add a new top-level node near the top of the outline 
> nodes, and it give the title "@chapters" (but without the quotation 
> marks).  Your chapter nodes will be children of this node - that is, you 
> will move them then so they are indented one level under the @chapters 
> node.  Give each chapter node a name that begins with @chapter, like this:
>
> @chapter Book Reviews 2019
>
> You don't have to do anything more - Leo will take care of the details of 
> setting things up.  Now just move any nodes you want under (i.e.,below, and 
> indented more than) the @chapter node that you want them to be in.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/59e82026-ce4b-4c05-8979-4e6e49712dc3%40googlegroups.com.

Re: A proposal for the Python Dev's

[john lunzer]

I'm not sure I'd let that hold you up. You could almost certainly do it 
what a fairly complete set of unicode characters. Specifically: the unicode 
box drawing characters for all the lines; there are a couple of fancier 
ones for the top level glyphs; and there is a diamond called a "lozenge" 
for the if. You'll likely have to make a couple compromises (you're not 
going to be exactly able to match the while glyphs) but what I've listed 
should allow you to move past the "artwork" component.

On Friday, January 24, 2020 at 3:13:02 PM UTC-5, tfer wrote:
>
> Thanks for the wishes John, though it currently is far down  on the list 
> of projects.
>
> It would require permission to use the gylphs, or creation of an 
> equivalent set.
>
> Tom
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fbe0b96e-0841-4353-812b-638d1e0974d8%40googlegroups.com.

Re: A proposal for the Python Dev's

[john lunzer]

CSD is nice, it seems like a more structure aware indent highlighter. 

I can see how it could be done entirely with unicode characters. I think in 
visual function it would be not much different from a whitespace mode.

As you stated, the algorithms need to be code aware meaning they're doing 
parsing, which I would think is non-trivial.

That said, CSD is very awesome looking and would be a welcome addition, so 
I wish you good luck on any work towards that goal.

On Tuesday, January 21, 2020 at 1:38:49 AM UTC-5, tfer wrote:
>
> Here is a CSD:
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1ada9a1a-a6a6-4b7f-a227-739c89e8641b%40googlegroups.com.

Re: Programming now feels like playing a video game!

[john lunzer]

Not quite exact. The precise and important difference is that in almost all 
video games somebody else has written the unit and coverage tests for you. 
Writing the tests and coverage yourself would be akin to setting your own 
goals which is rare in video games. 

If the goal is to make programming more video game like you may have 
exposed a worthy programming pattern: write tests, but not for yourself; 
and write code, but not to pass tests you've written. This could be done in 
pairs or in a larger group. In fact I can see how this could also make 
writing tests for existing code more fun as there would be a challenge in 
finding holes in other people's code.

On Saturday, January 18, 2020 at 7:07:38 AM UTC-5, Edward K. Ream wrote:
>
> The recent Aha's re the connection between unit testing and coverage 
> testing have turned computer programming into an utterly absorbing 
> adventure. Computer programming now feels like playing a video game!
>
> The analogy is exact!
>
> In a video game, you have more or less clearly defined goals. (In some 
> games the goal is to figure out what the goal is.) To attain those goals, 
> there is a well defined set of actions you must take. In well-crafted 
> games, those actions are pleasurable in themselves, or at least not utterly 
> tedious. There are also a set of obstacles, which make attaining the goals 
> non-trivial. There is also usually a score that measures progress. All 
> these combine to make a computer game it's own little universe.
>
> Likewise with computer programming. You have more or less clearly defined 
> goals. There are also actions, obstacles, and now, with coverage testing, a 
> score. Programming is now it's own *structured* universe. The goal gets 
> translated to unit tests, which all must pass with 100% coverage.
>
> *Summary*
>
> Unit tests translate a possibly ill-defined goal into something concrete, 
> specific and well defined. The task is, by definition, complete when all 
> unit tests pass with complete coverage.
>
> Coverage testing allows uncovered code to be discarded when all relevant 
> tests pass. This was a completely unexpected, and most welcome, development.
>
> The entwined tasks of creating unit tests and ensuring complete coverage 
> almost completely structures the task of programming. As a result, 
> programming is *more* engaging and compelling than ever before.
>
> Folks, this is a big deal.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6c2df975-00b4-4ac9-859f-73a77393b8cb%40googlegroups.com.

Re: ENB: Time travel, space filling curves, I Love Lucy etc.

[john lunzer]

I have not used to most recent release of emacs from 1985, this was the 
year GNU Emacs was released. I can't say for sure if it was feature 
complete enough to support Leo. Also, keep in mind that org-mode was only 
created in 2003. As far as time-travel experiments go I think there would 
have been a reasonable chance you would not have been content with Richard 
Stallman's pace or direction of the project. It's very possible that had 
you had today's knowledge you would have forked away from GNU Emacs. XEmacs 
seems like anecdotal proof that such an eventuality could have occurred.

On Tuesday, October 22, 2019 at 10:53:30 AM UTC-4, Edward K. Ream wrote:
>
> This Engineering Notebook post aims to explain some inherent tensions in 
> my thinking about Leo's future. More so than most, it's a "thinking out 
> loud" post.
>
>
> *Time travel*
>
> f I were to time travel back to 1985, knowing what I know now, I would 
> almost certainly have written the prototype of Leo in elisp, within emacs. 
> This would have had *many* advantages, namely almost all of emacs's 
> editing features!  I could avoided a whole lot of work, and avoided detours 
> into assembly language, Borland C/C++, objective C, WxWindows, etc.
>
> In some ways, this is a useless fantasy.  How "prescient" can I assume I 
> would be? But for sure, if I had understood emacs's minibuffer and named 
> commands, I would have given it a far closer look.  Leo's history would 
> have been very different.
>
> *Leo vs Emacs*
>
> Yesterday I created #1418 
>  from some notes in 
> leoNotes.txt.  On rereading it, I realize that it is essentially a summary 
> of emacs's features.  That's fair enough, and some of those features are on 
> Leo's to-do list.  However, this issue fails to mention features that emacs 
> lacks:
>
> - Clones,
> - Leo's outline-oriented objects, DOM and API.
> - Leo's outline-oriented features, including @test, @button, etc.
>
> And imo, Qt docks are more flexible, and more intuitive, than emacs 
> buffers.
>
> *IDE's have strong language biases*
>
> As I was thinking about features, I saw that underlying the "feature wars" 
> is typically a strong bias toward a particular language:  elisp (emacs), 
> python (Leo, pyzo), java (eclipse) and JS (vs code).  Sure, emacs claims to 
> allow development in many languages, but elisp is privileged.  Imo, python 
> is *clearly* the best general-purpose language.
>
> *Inherent creative tensions*
>
> The previous sections provide some context for my present thinking.  There 
> is a tantalizing prospect of embedding Leo into Emacs.  I've said several 
> times previously that this is likely a bad idea. I still think that's true, 
> even leveraging pymacs and Leo's bridge.
>
> Indeed, neither emacs nor org mode provides any of the Leo's advantages 
> list earlier.  Adding those features would be a huge project.  Otoh, the 
> payoff *might* also be big: a way for the huge base of emacs users to use 
> Leo inside their favorite editor.
>
> But for now I'm likely to resist this temptation, at least where emacs is 
> concerned.  The VS code (leointeg) project allows me to revisit these 
> fantasies vicariously!
>
>
> *Space-filling curves & Lucille Ball*
>
> For about a month I have been dithering about whether to share this 
> analogy.  It's time to do so, if only to get it off an internal to-do list.
>
> A space-filling curve  
> fills an area like the unit square in R x R. Depending on your mathematical 
> background, this may or may not seem surprising ;-)  I am conflicted.  Both 
> sets have the same cardinality, but a straight line has no area!
>
> Mathematics aside, the two-dimensional trace of my footsteps seems to 
> approximate the wiggly nature of a space-filling curve.  For me, this is a 
> *very* important analogy.  It turns out to be much more efficient just to 
> visit and revisit an area (of my house) or various aspects of a project, 
> rather than trying to do everything all at once.  That's not going to 
> happen anyway, so one might as well get used to it.
>
> It reminds me of an I Love Lucy 
> 
>  
> episode.  Lucy tries to go through a revolving door carrying a handful of 
> items, including skis!  Hehe. Naturally, she tries to do it all at once, 
> with hilarious results.  I haven't yet found this clip.  Let me know if you 
> find it.
>
> *Summary*
>
> I am tempted to think that leveraging emacs's excellent editing features 
> would be a good idea.  Alas, that train left long ago.
>
> Instead, I'll be thinking about comm-bridges between editors, and I'll 
> continue to add emacs-like features as appropriate.
>
> 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 

Re: Question about running / driving leo 'headless' to integrate it in my own GUI

[john lunzer]

Impressive progress. This is a pretty exciting development. While many 
"viewers" have been demonstrated this is one of the first "Leo in an 
editor" type demonstrations I've seen. Nice work. I look forward to seeing 
where this goes.


On Thursday, August 29, 2019 at 12:09:35 AM UTC-4, Robert Cholette wrote:
>
> Got so far as to browse with appropritate node icons. 
>
> a part from editing as in leo, long term goals are to Go-to appropriate 
> line in generated files when debugging/breakpoints etc.. (Reproducing part 
> of xcc-nodes behaviour, see http://xccnode.sourceforge.net/) 
>
> and have file-generating 'at' nodes show their derived line number instead 
> of the body-pane's line number (Also reproducing xcc-nodes)
>
> Added screenshot to readme: 
>
>
> 
> ( yeah i've got to de-saturate the colors in the icons! )
>
> On Saturday, August 10, 2019 at 3:49:34 PM UTC-4, Robert Cholette wrote:
>>
>> First I'd like to apologize for just asking this on github, I didnt 
>> realise here was perhaps a better place to ask this kind of thing... 
>>
>> Hi! Long time leo user here. I use it mainly for the 'core' features: 
>> outline organisation of my code : @clean nodes, structure with @others. And 
>> I alt-tab leo alongside with another editor/IDE for 
>> running/debugging/compiling/linting/beautifying/etc...
>>
>> I dont care so much about vim/emacs integration nor dont even understand 
>> what those buffers/minibuffers are and all around feel like that qt-gui 
>> framework didnt age very well. (no offence meant here, as I would be 
>> devastated to think I offended edream, he's like my programming 'idol')
>> I also do not use @buttons and internal scripting in leo altough i can 
>> see its use for some people. 
>>
>> I mainly use Leo for its 'file-generation'/'file-reading' (mainly @clean) 
>> feature via the outline structure that it provides. Organising a program 
>> with an outline, clones and @others is the best! Which also, if I may say 
>> so, is Leo's 'killer feature'.
>>
>> So i'd like to try and integrate, or 'roll my own' leo in my other 
>> favorite editor so that I have the subset of leo's features that I just 
>> defined as its 'killer features' available without having Leo 'opened'. 
>> Is leoBridge the way to go? ...or is there a way to start leo with no GUI 
>> and have it listen for commands on a specific port for input/output of 
>> commands and answers? 
>>
>> Many thanks in advance!!  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/53df2f1b-e7ba-4da1-af74-632ead21261e%40googlegroups.com.

Re: Emacs features in Leo: general remarks

[john lunzer]

Thank you for circling back around, it's absolutely appreciated. I agree 
with you fully; I just sometimes have these grand visions of Leo and want 
to share them. The dynamic node styling seemed like a potentially simple 
solution to shoehorning various features into the DAG. I'm such a huge fan 
of Leo's DAG (I miss it every day when using other tools) and generally 
feel that is where the investment should be because it feels more "true" to 
Leo's essence. 

On Thursday, August 1, 2019 at 2:16:43 PM UTC-4, Edward K. Ream wrote:
>
> On Thursday, August 1, 2019 at 12:30:32 PM UTC-5, john lunzer wrote:
>
> The "magic" of emacs is not due to each of these features in isolation 
>> (though they are all useful by themselves) but due to their 
>> interconnectedness within the context of registers and buffers. 
>>
>
> Yes, I think I understand that.
>
> Rereading my reply to your comments, you might think I was blowing you 
> off.  Instead, I was attempting to say that each new emacs-like feature 
> must be integrated with Leo as it is.  Yes, big visions are important, but 
> the overall vision is Leo as it is, not emacs as it is.
>
> As we go forward, I will welcome specific suggestions to emacs-like 
> features.  But let's get each feature working first.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b4c3c422-8144-481f-96d3-be3b1409339c%40googlegroups.com.

Re: Jeff R: What emacs features do you want?

[john lunzer]

On Thursday, August 1, 2019 at 9:03:36 PM UTC-4, Jeff R. wrote:
>
> For this, I think Leo, through the use of clones, would be well suited. 
> But doing that is itself a huge project. Orgmode has been built 
> collectively for many years, and it would be very difficult to build a 
> version of it that would draw away an experienced emacs user. If done well, 
> it would also attract new users. If really well, that plus python might do 
> it. 
>

There is an important point here, org-mode is kind of an emacs within 
emacs. It's drowning in "organization" features, which is what many people 
reference when they talk about org. Leo does have some plug-ins that 
probably fill in some of the gaps. I think issue 1228  
has the potential to 
start creating some legitimate comparisons between the two tools.
 

> If I could do this with python, and write code that takes effect 
> immediately and channges functionality in real time, I would love
> that. I have no idea whether this is how Leo is, or whether this is 
> common, etc.
>

This is a long standing point of conversation in this community. It's a 
little harder to pull this off in the way emacs does it. Don't forget that 
emacs/elisp uses global scoping/namespace by default. Because everything in 
the program is visible and modifiable by any piece of code it makes it 
super easy to "customize". Scoping and namespaces are much more controlled 
and isolated in Python and so any kind of "live" customization has to be 
intentionally built into a program's structure.
 

> Emacs also does an excellent job of exposing its documentation. For 
> example, if you want to see the value of a variable and documentation for 
> it, you press C-h v, and then you'll be prompted for the varialbes name, 
> and the results can be searched through with fuzzy matching. The same can 
> be done with functions with C-h f. You can also navigate to the source 
> code, which shows the source, and all callers and callees. 
>

This is a great point and one I often forget about but use ~400 times a 
day.  Honestly, I don't think I could use emacs without this. A built-in 
documentation/help system would go a long way in Leo's accessibility. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9abe28de-54a7-4570-b189-9b1f5f3742b2%40googlegroups.com.

Re: Emacs features in Leo: general remarks

[john lunzer]

The "magic" of emacs is not due to each of these features in isolation 
(though they are all useful by themselves) but due to their 
interconnectedness within the context of registers and buffers. Everything 
in emacs exists within a "buffer" which is really just text windows. As 
such everything is capable of being copied/moved to another buffer. This is 
helpful for instance when running a command line utility on a file or group 
of files within dired using "dired-do-shell-command". It could be something 
as simple as running md5sum on some files and having instant access to the 
output in a buffer that can be easily moved to an org file for 
documentation. This kind of interaction extrapolates out to almost anything 
you can do in emacs.

I don't want to imply that the "buffer" system is almighty (which it is 
not) or that Leo should try to emulate it somehow. Buffers are simply the 
medium through which emacs executes cohesion. Leo's medium are trees and 
nodes.

While each of the proposed emacs feature is nice, they would become truly 
powerful if they are well integrated into Leo's tree/node paradigm. I would 
encourage, as much as is possible integrating these features directly into 
the dag. I envision a Leo universe where the DAG becomes a lot richer. 

For example I see a reasonable implementation of a Jupyter console as 
creating a node name "@jupyter my_console" which could then be "activated" 
or "run", generating a child node named "In [1]:" after the jupyter kernel 
booted up and was attached. You then type your input into that "In" node 
and when ready "activate"/"run" the node which would run your command in 
the jupyter kernel and create a sibling node named "Out [1]" with the 
output and another sibling named "In [2]" with another input. The idea of a 
generic "activate"/"run" command command comes from org-mode's 
"org-ctrl-c-ctrl-c" command. It's a pretty uninspired name but it is a 
context sensitive command which tries to do what you would expect, so in 
the case of the "@jupyter my_console" node activating it means starting a 
kernel. And in the case of "In" nodes activating it means running the code.

With Leo's current body node capabilities the above interaction might be a 
little cumbersome. However, if Leo had a vertically sequential multi-node 
body pane (which I mocked up about a month ago) this interaction would be 
seamless. Being able to save the "@jupyter my_console" sub-tree and move 
it's children around would have great utility.

The active_path.py plugin already kind of implements dired as a tree, but 
it's pretty rough around the edges, and would need to be reimagined to 
provide a true live filesystem view. In the case of integrating dired into 
the dag you could imagine an "@dired" node with each child representing a 
file or folder and each body of each child as containing the same 
information you would see in a "ls -l" listing (or "long listing"), such as 
file size, owner, modification date, and permissions. 

If different types of "@directive" nodes could dynamically alter the visual 
style of the child nodes displayed in a multi-node body editor you could 
for example make the body appear to the left of the headline and remove any 
upper and lower borders and spacing for children of an "@dired" sub-tree . 
In this way the sub-tree of "@dired" would look almost exactly like an "ls 
-l" listing. With the exception that it would *still be a dag/tree/nodes 
all the way down*. In the same way you could style the children of an 
"@jupyter" node to make the visual look and feel of a jupyter notebook.

All of a sudden you have powerful tools that look and behave exactly as 
people are familiar with but are also true Leo trees. Now try to imagine 
these features with Vitalije's time machine feature. Leo would undoubtedly 
be one of the most powerful computing tools in existence, surpassing the 
might and utility of many other tools/IDEs combined.

Though I haven't suggested anything outside of Leo's existing paradigm 
there would obviously be an immense amount of work involved in this. I'm 
not for a second suggesting anybody attempt this. It is merely my vision of 
what Leo could become.

On Thursday, August 1, 2019 at 7:29:48 AM UTC-4, Edward K. Ream wrote:
>
> It will be a lot easier to add emacs features to Leo than add Leonine 
> features to emacs!  I've said this before, but it's worth repeating.
>
> Pyzo already supports features such as dired, integrated outline/body pane 
> and the jupyter console.  Something like magit might exist in the python 
> world.  If not, I'll do it by hand.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/31c42f50-eff7-4761-9c40-337e89b66189%40googlegroups.com.

Re: Leo and fossil merged with Rust

[john lunzer]

I think many of us have had a similar vision for development and 
development environments. I have long dreamed of this kind of omnipresent 
"history" integrated into every aspect of computing, but it never seemed to 
show up. Now you've demonstrated the power it holds.

I envisioned this and in addition "saving" as simply tagging one of these 
revisions. 

Your demo is missing a powerful demonstration of this feature, the "over 
the shoulder" demonstration. What is required is a "play" button. If you 
slide the outline slider back in time and then provide a play button which 
moves the slider forward after a time increment as well as visually jumps 
to the largest changes you can "look over the shoulder" of a developer as 
they develop.

Even without a play button, a check "jump" box which if enabled would jump 
to the largest change when sliding the outline slider would be nice. 

Great work, there are countless possibilities here. 

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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/254ce0d7-571a-4631-988a-43a9f368e113%40googlegroups.com.

Re: I stopped using vim mode

[john lunzer]

What a great revelation, and a perfect example of how an editor can shift 
the paradigm of editing.

Make sure you look around for the different ways of searching through and 
managing larger outlines:

   - The "clone find" family of commands
   - I find Chapters to be a nice extension of the tree hierarchy
   - The Quicksearch plugin is great for quick searches... no really it is. 


On Thursday, June 27, 2019 at 11:15:57 AM UTC-4, gar wrote:
>
> After several days w/o vim mode I understood the dao of leo.
> There's actually no need in vim mode at all. 
>
> Vim editing style is good when you deal with thousands (ok, hundreds) 
> lines of text/code.
> Then is boosts your alot. 
> But when you edit small text/code snippets - there is no difference what 
> editing style you actually use. Any is ok.
> Your responsibility is to make suitable hierarchy and keep node texts 
> reasonable small - and then the problem of editing wont even arise.
> When you edit a couple of paragraphs - all those modes and switches become 
> obstacles!
>
> So there's no real problem that vim mode is dead in Leo. As I thought just 
> yesterday.
>
>
>
> понедельник, 24 июня 2019 г., 14:01:41 UTC+3 пользователь Edward K. Ream 
> написал:
>>
>>
>>
>> On Mon, Jun 24, 2019 at 4:11 AM gar  wrote:
>>
>>> It is totally unusable unfortunately 
>>>
>>
>> Thanks for this report.  Perhaps you can help improve the vim plugin.
>>
>> Edward
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d9b9aa8d-9223-4cf3-ae43-0e4eaba95b2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Org Brain

[john lunzer]

Hmm... I saw org-brain but it looked clunky so decided to not try it out, 
perhaps I judged it too soon.

I watched a video and it does look like it shows "clones", in that you can 
have the same node referenced in different parts of the tree. 

Without using org-brain but seeing it, and with having used Leo heavily, 
the main differences appear to be: 

   - org-brain does not appear to indicate when something is a clone 
   (things would start to get confusing in larger DAGs with nodes of the same 
   name)
   - no explicit babel integration (therefor no ability to generate full 
   code files from DAG)
   - no explicit tangle/untangle integration (same inability as above)

It appears as though the target audience for org-brain is specifically 
mind-mapping, where these features might not be missed. That is likely 
going to be the differentiator, if you're trying to do mind-mapping, 
note-organization type tasks it may offer you similar features to what you 
can find in Leo. It is likely not going to get you any kind of Tree/DAG 
programming ability. The closest thing you will find to Leo's features with 
regards to organizing code is outshine 
; be warned there are no clones, it 
just offers a tree structure (which is definitely better than nothing at 
all). 

It's been discussed here before but the way Leo handles "clones" is a cut 
above the rest: cleanly, transparently, and natively. The cleanliness of 
their implementation is evident in how broadly and generically they can be 
used. They remind me a bit of symlinks in the Linux filesystem. 

Emacs and any plugin I've seen thus far lacks a true cloning ability. 
Though I actually do not think it would be too difficult to implement one's 
self. Emacs has a feature called "indirect buffers" 

 which 
is a true cloning ability, but lacking all structure. It likely would not 
be difficult to do something clever with org, babel, and indirect buffers 
to create a tree/body view very similar to Leo's. You would be able to 
tangle, but never untangle (this is also a feature unique to Leo).

On Wednesday, June 26, 2019 at 1:47:35 AM UTC-4, Matthew Piziak wrote:
>
> I searched for org-brain  in 
> this group and I couldn't find any mention, so I thought I'd bring to the 
> group's attention.
>
> In particular, like Leo but unlike vanilla Org, Org Brain supports DAGs. 
> In the default visualization mode it shows all children and parents of a 
> given node, and in tree mode it shows them just like Leo does—as cloned 
> nodes.
>
> Has anyone had the pleasure of using both of them for a significant 
> workflow and having a point of comparison? If so I'd love to hear what you 
> think. If not then I'll try them out myself and report back.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b7584570-75aa-4f8f-98ea-276fd6ef1176%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jeff R: What emacs features do you want?

[john lunzer]

On Tuesday, June 25, 2019 at 6:14:28 AM UTC-4, Edward K. Ream wrote:
>
> On Mon, Jun 24, 2019 at 8:00 AM john lunzer  > wrote:
>
> > If Leo had a multi-node body pane which reflected the indented 
> structure/view shown in the tree pane then it would function more similarly 
> to Org-mode than it does now. 
>
> I don't have a clear picture for this. Can you explain further?
>
> Edward
>

Sure, I've made a mock up to aid understanding. In this example, typically 
the "header" nodes would not contain "body" text but it does not mean they 
can't. Any node could have the same header/body split as the "child" nodes 
in this example. Perhaps a better name for this type of body pane would be 
a "tree body pane". The important thing is that the view in the body pane 
reflects the view in the tree pane, really the only difference between them 
is that the body pane also shows the body text for each node. Interestingly 
the body pane as shown here is what you see when in Org mode, It doesn't 
have a "tree pane". 

To be clear I'm not advocating that Leo's body pane be converted to this. 
I'm suggesting this as a new and different type of body pane, where you 
could switch between this new type of body pane and a conventional single 
node body pane, depending on your preference.

My understanding from past conversation is that Terry has put quite some 
work into *something similar*. I believe he has shown us his own 
mock-ups/demos, though, I don't believe he incorporated the tree-like 
indentation in the body pane as I have shown here.

[image: tree_body.png]



-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bc452ea8-5625-4a30-8fe7-0aff58a5c6da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jeff R: What emacs features do you want?

[john lunzer]

Edward, I'm in a similar situation, I can give my own short experience.

The more one uses emacs the more it becomes obvious that it is not an 
editor or an IDE or a PIM, but simply contains all those things. emacs is 
not an integrated development environment (IDE) but rather an integrated 
computing environment (ICE, just coined). It is a collection of computing 
(editing, PIM, development, debugging, version control, system management) 
tools that work well together (seamlessly in many case, but certainly not 
perfect). 

Some may think this statement blasphemous but I think emacs and pharo are 
extremely similar in scope. That is to say in both cases you can (and are 
intended to) spend close to 100% of your time within the computing 
environment. In emacs the features that help facilitate this are dired, 
vc/magit, and term/shell-commands. 

I spend an enormous amount of my time in dired because it's just so well 
integrated into the rest of emacs. It is as if I have the entirety of my 
file system and network at my finger tips. I can run shell commands on any 
files/folders or subset of files/folders and any output goes directly into 
emacs; this helps keep me in emacs an out of the terminal. dired is further 
enabled by TRAMP which allows you to view the file system of remote 
computers via SSH. TRAMP also makes it seamless to edit files on those 
remote computers. 

vc/magit/diff-hl and other features make version control seamless and 
mostly painless. Being able to see which files have changed (in dired) and 
which lines of my code have changes (via icons in the gutter) at all times 
really helps keep my mind organized and focused. These features also help 
keep me out of the terminal. 

And then there is Org, which I'm sure you've gotten plenty of requests for 
features from. Leo is very much like Org. I use Org more like a Jupyter 
Notebook than anything else. What I utilize most is Org-babel. Org-babel 
allows you to run any kind of code from anywhere within an org file and 
save the results within the Org file. The nice thing is that the syntax 
highlighting is applied appropriately for every kind of block. For example, 
you can several different pieces of code in different languages with 
different syntax highlighting in the same file on the same screen at one 
time. I think Leo does quite a bit of what Org does already, they just do 
things differently.

I'm not there is anything I would recommend that Leo try to do that is 
currently does not that emacs does. You would, I believe, have to turn Leo 
into a full ICE; which I don't think has ever been the goal or aim of Leo. 
Perhaps this just sort of happens over time as features are accumulated.

If Leo had a multi-node body pane which reflected the indented 
structure/view shown in the tree pane then it would function more similarly 
to Org-mode than it does now. Whilst there is a benefit to the "focus" of 
seeing only one node at a time, in the cases where I use Org-mode I 
explicitly want/need to see multiple nodes at a time. Leo can't give this 
to me right now. I think this would really open Leo up opportunities for 
Leo, it would be a bit of a paradigm shift for Leo. I know that Terry has 
been working on this but I don't think there has been a release. If he 
doesn't have the time to finish it I'd recommend him passing it off to you 
(Edward) to at least experiment with.


On Saturday, June 22, 2019 at 2:58:08 PM UTC-4, Edward K. Ream wrote:
>
> Jeff R: I have moved off of Leo and now use Emacs, mostly for org-mode but 
> also for whatever else is useful. Emacs itself has features that I can't 
> give up, or at least am not willing to right now. 
>
> What are those features?  Adding them to Leo might make Leo substantially 
> better.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/136345d4-347c-476d-8084-2ff76986f190%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: My initial experience using ILeo ...

[john lunzer]

I used to use the IPython bridge regularly, back before they renamed 
IPython to Jupyter. I haven't touched recent versions.

The fact that this doesn't work for you *now *is potentially the result of 
*code 
rot;* with enough changing in the IPython/Jupyter API to finally(? 
surprised it didn't happen earlier) break the bridge. I doubt anyone has 
touched this bridge code in a while. Ville is for the most part long gone. 
I reached out to him a couple years back and while he responded and was 
cordial his memory of events wasn't good enough to move my issue forward.

I'm not saying that you need to abandon your efforts but unless somebody 
else chimes in you may not receive additional guidance. 

Firstly, however, try to determine if it's worth your time.

The IPython bridge doesn't buy you much. It gave me the ability to use 
IPython's interactive REPL on some of Leo's internals. Most importantly it 
let me view object structure using auto-completion to dig down into various 
objects. This was helpful when developing some plugins. You can most likely 
do similar investigations via Leo scripting, Edward is a wizard at this 
type of stuff and I'm sure has recipes for any type of Leo introspection 
you might want to do. 

If Leo is missing anything it's not necessarily IPython/Jupyter integration 
as is often requested but in general a terminal/console like REPL linked to 
its internals.

Perhaps you should let us know what you want to do with the bridge before 
spending a lot of time trying to get it to work. I would say there is only 
small chance it's going to aid your efforts. 


On Sunday, June 23, 2019 at 8:23:29 AM UTC-4, Viktor Ransmayr wrote:
>
> Hello Edward, 
>
> Am So., 23. Juni 2019 um 12:49 Uhr schrieb Edward K. Ream <
> edre...@gmail.com >: 
> > On Sun, Jun 23, 2019 at 4:32 AM Viktor Ransmayr  > wrote: 
> >> 
> >> I was able to create an environment, where the Jupyter QtConsole (JQC) 
> is started - however - the associated Leo outline, in my case 
> "quickstart.leo", becomes unusable as soon as the JQC starts :-( 
> >> 
> >> Is anybody else experiencing the same issue - or - can you tell me what 
> I'm doing wrong / what I should change? - TIA! 
> > 
> > Thanks for your researches.  I have no memory of any of this. So I am 
> unlikely to be of any help. 
>
> Thanks for your feedback. - In a while I might reach out to Ville, 
> since he seems to be the initiator of this sub-project. 
>
> With kind regards, 
>
> Viktor 
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/57caaaf9-3804-4d60-a39d-81b622a2b14d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rethinking Leo 6.1 and pyzo integration

[john lunzer]

I dislike having multiple editors/IDEs open because it is often messy and 
the "integrated" component of IDE gets lost.

I'm not implying that you do more work; it is your Leo, we just use it. I'm 
not optimistic that users would see this as a "good" or "clean" solution to 
having shell and file browser features available to them.

I am, however, implying that your Doh/Aha moment might be a personal one 
and that the desire for the stated features to be integrated *within* Leo 
will not go away because of it.

That said thank you for the recent work, very much appreciated.

On Tuesday, June 18, 2019 at 2:28:51 AM UTC-4, Edward K. Ream wrote:
>
> Leo 6.1 supposedly would integrate pyzo features into Leo. See this page. 
> 
>
> In fact, doing so would be foolish and unnecessary, as I shall now explain.
>
> *Doh: Read the documentation, Luke*
>
> A few days ago I had a sickening Doh! moment.  I have done extensive 
> code-level prototyping of pyzo integration without having a clear idea of 
> what pyzo does!  I'm talking about the *basics*, covered in the pyzo intro 
> , configuring shells 
>  and interactive vs script mode 
> .
>
> From the pyzo intro: "Shells run in a sub-process, such that when it is 
> busy, Pyzo itself stays responsive, allowing you to keep coding and even 
> run code in another shell."
>
> This explains why pyzo uses yoton, and the related complexity.  yoton 
> allows pyzo to show results in the "Workspace", "History Viewer" and 
> "Shell" areas, while the actual computation happens in an external process.
>
> So far, so good.  What are the implications?
>
> My first thought was that Leo could easily adapt the Ctrl-B logic to run 
> code in an external process.  But just a bit more thought shows that that 
> won't work.  *Scripts run in an external environment can't be Leonine*. 
> They could be given access to c, g and p, but they could not control Leo 
> without heroic measures.
>
>
> *Doh: Pyzo can run alongside Leo*
>
> Yesterday I saw this clearly for the first time. It was another 
> sickeningly obvious "revelation".  
>
> Pyzo does a great job of showing and updating external files.  So anyone 
> can get the benefits of both Leo and Pyzo *right now* as follows:
>
> 1. Use Leo to create and update external files, as usual.
> 2. Use pyzo to open files and run shells, as desired.
>
> In short, adding pyzo's features to Leo would be really really stupid.
>
> *Summary*
>
> Anyone can get the benefits of Leo and pyzo by running them side by side.  
> Doh!
>
> I shall not add pyzo's major features to Leo.  Not in 6.1.  Not ever.
>
> Suddenly, Leo looks finished as well as complete :-)  It's time to 
> investigate new directions for Leo with more playful prototypes.
>
> All comments welcome and encouraged.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3faacace-ddbf-4f91-8c17-86fec0d0e196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joe, is there any way to embed LeoVue's page in Leo's home page?

[john lunzer]

The design is very modern, reminds me a little of the JetBrains's sites 
(like PyCharm).

On Saturday, April 20, 2019 at 10:58:50 AM UTC-4, Joe Orr wrote:
>
> How's this look for a start:
>
> https://kaleguy.github.io/leosite-pilot/
>
> repo at:
> https://github.com/kaleguy/leosite-pilot
>
> Joe
>
>
> On Tuesday, April 16, 2019 at 6:10:27 AM UTC-4, Edward K. Ream wrote:
>>
>>
>>
>> On Mon, Apr 15, 2019 at 8:05 PM Joe Orr  wrote:
>>
>>> Here's another approach that might be interesting:
>>>
>>> A site like this one: https://phosphorjs.github.io/
>>>
>>
>> A good looking, informative home page. Imo, too many sites don't actually 
>> tell newcomers what the product does.
>>
>> So it's one simple home page with a couple of links up top
>>>
>>> The home page would say in sections: (I'm abbreviating)
>>>
>> [Snip] 
>>
>>> Would be cool to basically have the Leo Docs on web be a Leo file
>>>
>>> Just a thought. I can dummy something up if you want to see what it 
>>> might look like.
>>>
>>
>> Please do!
>>
>> 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: Pyzo questions

[john lunzer]

Obviously Edward can answer with great authority, but as an observer my 
understanding is that the "pyzo project" brings with it a complete overhaul 
of the windowing/framing/tabbing system, one that is more featureful and 
unified. So while it is true that it appears that most of the "tools" that 
will come with the project are geared toward programmers it should provide 
more flexibility and friendliness with regards to layouts and the general 
look and feel of Leo, which should benefit everyone. 

I'll let Edward correct me, but thought an "outside" perspective might be 
valuable. 

On Monday, April 22, 2019 at 3:29:13 PM UTC-4, Rob wrote:
>
> I have followed with some interest (though little understanding) Edward's 
> pyzo project and have some questions (perhaps stupid or ignorant):
>
>- After a cursory review of the pyzo.org site , I'm 
>left with the impression that this would only be of interest for Python 
>programming projects or code writing, am I wrong?
>- Which pyzo tools might be beneficial for non-programmers, if any?
>- In general, how does pyzo integration with Leo improve Leo as a 
>writing or PIM tool?
>
> Please know that I'm cheering for it to succeed, just not sure if it's 
> relevant to me and others with similar needs and use cases. Regards,
>
> 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: Rev 95d0be merges sessions into devel

[john lunzer]

Hmm... so you're saying to disable a restoration of a session you simply 
open a specific .leo file?

Will that also disable save-session on close? So that I can get back my 
previously saved session?

On Wednesday, April 10, 2019 at 6:08:54 PM UTC-4, Edward K. Ream wrote:
>
> As of this rev, Leo will ignore the --session-save and --session-restore 
> command-line args.
>
> Instead of these args, Leo will *always* save and restore session state 
> if no file names are given on the command line.
>
> Please report any problems immediately.  We aren't going back.
>
> Edward
>

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

Re: All pygments work is in devel

[john lunzer]

Thank you for this. Sorry that it was kind of a let down beyond 
colorization for more languages.

On Monday, March 25, 2019 at 7:13:29 AM UTC-4, Edward K. Ream wrote:
>
> I plan no further work on this project.  Please report any problems 
> immediately.
>
> *Summary of this project*
>
> This project is technically useful and interesting.  I'm glad I did it.
>
> Using pygments (*@bool use-pygments = True*) makes syntax coloring 
> available for many more languages.
>
> Bypassing pygments' styles machinery (*@bool use-pygments-styles = False*) 
> allows much more flexible configuration *of pygments *using Leo's @color 
> settings.
>
> At long last, @color settings may now use any symbolic name appearing in 
> Leo's color base in leoColor.py.  Leo normalizes setting names, so 
> Solarized-Red means solarizedred.
>
> It's been a busy week. According to the checkin logs, work began last 
> Tuesday, March 19.
>
> 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: Working on pygments

[john lunzer]

I'm guessing Leo will be getting a huge boost in the number of "supported 
languages". Is it safe to assume that all lexers on this page, 
http://pygments.org/docs/lexers/, will work? 

On Wednesday, March 20, 2019 at 7:11:31 PM UTC-4, Edward K. Ream wrote:
>
> On Tuesday, March 19, 2019 at 2:57:31 PM UTC-5, Edward K. Ream wrote:
>
> Using the pygments syntax colorer would be an 
>> important addition to Leo.  This is #568 
>> . Imo, it should be 
>> part of the last python 2 version of Leo.
>>
>
> Rev 5ae87f5c in the pygments branch demonstrates all essential aspects of 
> using pygments!  This is a huge milestone.
>
> *To do*
>
> At present, the code uses pygments.style.get_style_by_name('default') to 
> specify colors. Most of Leo's present syntax-coloring-related settings will 
> likely disappear, to be replaced by much simpler settings.
>
> The colorer must tell pygments how to color section references and @doc 
> parts.  This should be straightforward.
>
> The present code uses only the python lexer. Leo already has a framework 
> to change lexers in the middle of body text, so generalizing the code 
> should be straightforward.
>
> *Summary*
>
> The pygments branch now demonstrates the essentials of using pygments for 
> syntax coloring.  The entire leo/modes directory will disappear, along with 
> much of Leo's legacy syntax coloring code.
>
> Significant work remains, but I foresee no real difficulties.
>
> Edward
>

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

Re: ENB: Leo will use Jupyter's coloring code

[john lunzer]

Can you comment you on the impact in performance using this code will have?

On Wednesday, March 20, 2019 at 8:22:36 AM UTC-4, Edward K. Ream wrote:
>
> The Jupyter syntax coloring code 
> 
>  
> from Jupyter's qt_console package appears to be exactly what Leo needs to 
> use pygments for syntax coloring!  This is a much-needed breakthrough.  The 
> Jupyter code is an elegant solution to a difficult problem.
>
> *The problem*
>
> Here Leo's existing (new) PygmentsColorizer.mainLoop code, from Leo's 
> pygments branch:
>
> def mainLoop(self, n, s):
> '''Colorize a *single* line s, starting in state n.'''
> trace = True and not g.unitTesting
> from pygments.lexers import PythonLexer
> d = {
> 'Keyword': 'keyword1',
> 'Keyword.Namespace': 'keyword1',
> 'Literal.String.Doc': 'literal1',
> # A **full** docstring.
> 'Literal.String.Interpol': 'literal1',
> 'Literal.String.Single': 'literal1',
> 'Comment.Single': 'comment1',
> # 'xt': 'blank',
> 'Operator': 'operator',
> }
> i = 0
> for token in PythonLexer().get_tokens(s):
> kind, val = token
> j = i + len(val)
> kind = repr(kind).lstrip('Token.')
> tag = d.get(kind)
> if tag:
> self.setTag(tag, s, i, j)
> i = j
>
> This *almost* works, but alas, it does not (and *can not*) handle tokens 
> that span lines. The code is drowning in an inch of water.
>
> *The Solution*
>
> The PygmentsHighlighter (PH) class monkey-patches 
> RegexLexer.get_tokens_unprocessed to store the final lexer stack on the 
> tokens themselves.  This is clever, non-trivial code.  Leo will use copies 
> of the Jupyter code. The only changes will be to replace a few Jupyter 2/3 
> switches with g.isString and g.isPython3.  I'll add extra the Jupyter 
> copyright to all top-level nodes, so there can be no doubt where the code 
> comes from.
>
> Here is PH.highlightBlock:
>
> def highlightBlock(self, string):
> """ Highlight a block of text."""
> prev_data = self.currentBlock().previous().userData()
> if prev_data is not None:
> self._lexer._saved_state_stack = prev_data.syntax_stack
> elif hasattr(self._lexer, '_saved_state_stack'):
> del self._lexer._saved_state_stack
> # Lex the text using Pygments
> index = 0
> for token, text in self._lexer.get_tokens(string):
> length = len(text)
> self.setFormat(index, length, self._get_format(token))
> index += length
> if hasattr(self._lexer, '_saved_state_stack'):
> data = PygmentsBlockUserData(
> syntax_stack=self._lexer._saved_state_stack)
> self.currentBlock().setUserData(data)
> # Clean up for the next go-round.
> del self._lexer._saved_state_stack
>
> This great stuff.  It will form the basis of PygmentsColorizer.mainLoop in 
> Leo. It should be relatively straightforward to make this compatible with 
> Leo's settings.
>
> *Summary*
>
> Leo will use Jupyter's syntax coloring code from Jupyter's qt_console 
> package. This is a crucial step in making #568 
>  work.
>
> The code will be copied into Leo, virtually unchanged. I'll add extra 
> copyright messages to all copied top-level nodes.
>
> Leo's PygmentsColorizer.mainLoop method will adapt PH.highlightBlock to 
> handle Leo's existing syntax-coloring settings.  This should be relatively 
> straightforward.  It may even be possible to use pygments' (or Jupyter's) 
> styling mechanism to do this.
>
> Edward
>

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

Re: ENB: pyzo progress report

[john lunzer]

I don't want to make assumption, will the pyzo shell have access to the 
Leo's namespace where g, c, and p are? 

On Thursday, March 14, 2019 at 11:46:53 AM UTC-4, Edward K. Ream wrote:
>
> On Sunday, March 10, 2019 at 8:14:53 AM UTC-5, Edward K. Ream wrote:
>>
>> Moving pyzo features into Leo promises to be easier than expected. 
>>
>
> Still true.  I am working on the second version of the "Shell" prototype 
> script.  In the new prototype the MainWindow's central widget will be a 
> dummy outline widget, with some support for all other pyzo tool windows. 
> That will be a major milestone. 
>
> Much of the work involves imports.  There are subtle differences in what 
> imports do, depending on context.  Using a prototype script isolates the 
> import issues, so there are no real mysteries.
>
> pyzo defines its own wrappers for PyQt, which again are subtly different 
> from Leo's own wrappers in leo.core.leoQt.  The pyzo wrappers are arguably 
> better, but for now I'll adapt the prototype to use Leo's wrappers.
>
> 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 and pyzo

[john lunzer]

This will be wonderful quality of life improvements. If you can, without 
terrible effort or stress, "borrow" the best of Pyzo then I think Leo will 
benefit mightily. 

As another data point it may be worth studying xo's syntax highlighting code 
. xo is a minimal console based text editor 
written in Python that uses pygments for syntax highlighting. The author, 
Anthony Scopatz, is another skilled Python programmer who I put in same 
category as Almar Klein. 

On Tuesday, March 5, 2019 at 9:27:24 AM UTC-5, Edward K. Ream wrote:
>
> This post explores what Leo and pyzo have to offer 
> each other.
>
> *tl;dr*: It will be much easier to use pyzo features and code in Leo than 
> adding Leonine features to pyzo.
>
> *Studying pyzo*
>
> Yesterday I created a personal study repository of pyzo here 
> .  This allows me to track (back up) 
> localized changes to pyzo.  The git commits are a record of my work.
>
> Not surprisingly, it is far easier to study pyzo code with Leo than with 
> pyzo.  Also not surprisingly, it's far easier to understand what pyzo 
> offers by actually playing with it.
>
> *Embedding pyzo's features and code into Leo*
>
> Here is a partial list of pyzo features that should(!) be added to Leo.
>
> *Windowing*: pyzo allows any pane to be dragged to a new position.  Each 
> pane has a label area which can be dragged anywhere else.  pyzo remembers 
> the arrangement of panes on exit, and restores the arrangement when it 
> restarts.  This is, I'm pretty sure, a feature of Qt, and it will likely be 
> fairly easy to implement.  It's a more intuitive and general solution than 
> Leo's toggle-split-direction command, the new pane Easter Egg.  Leo must 
> have this.  It's the extensible window management that Leo has needed for a 
> long time.  In pyzo, users create new panes using the tools menu.  Again, 
> Leo should so something like this.
>
> *Qt Styles*: The pyzo View menu allows users to select a Qt Style.  The 
> default style is "cleanlooks", which imo is way better than the native 
> styles.  The style is indeed very clean and highlights the location of drag 
> areas.  Leo should have this.
>
> *File Browser*: The pyzo file browser is excellent.  It need not always 
> be visible (It will be a window option), but at the least it should be part 
> of a dialog when opening files.
>
> *IPython and kernels*: Pyzo has an interactive "Shells" window, and the 
> "Logger" window also supports IPython features.  Both these windows are 
> superior to Leo's buggy python_console plugin.  I intend to move the code 
> for both these into Leo.
>
> *Yoton*: Yoton is a separate 
> project for interprocess communication, bundled with pyzo, and used by the 
> pyzo "Shells" and "Logger" windows.  It should be part of Leo.
>
> *Syntax coloring*: Here is the heart of the pyzo syntax coloring code:
>
> tokens = list(parser.parseLine(line, previousState))
> for token in tokens :
> # Handle block state
> if isinstance(token, parsers.BlockState):
> self.setCurrentBlockState(token.state)
> else:
> # Get format
> try:
> styleFormat = nameToFormat(token.name)
> charFormat = styleFormat.textCharFormat
> except KeyError:
> continue
> # Set format
> self.setFormat(token.start,token.end-token.start,charFormat)
> # Is this a cell?
> if (fullLineFormat is None) and styleFormat._parts.get('underline'
> ,'') == 'full':
> fullLineFormat = styleFormat
>
> This is a spectacular simplification on Leo's own colorizing code, but it 
> requires a separate "tokenizing" of each line.  There are two possible ways 
> to use this code:
>
> 1. Add a line tokenizer based on Leo's existing files in leo/modes.
> 2. Use the code above as a template for pygments .  
> I'll explore this first. It might eliminate all of leo/modes!
>
>
> *Embedding Leonine features in pyzo*
>
> Pyzo uses lines of the form "## name" to define *chunks*. Chunks continue 
> until the next class or method definition.  Chunks are not replacements for 
> either @others or << sections >> both of which require an explicit end 
> point.  I considered adding lines like ##<, ##>, ##, 
> but such new sentinel lines would, naturally, clutter the external files.
>
> It is tantalizing to think that the pyzo way of breaking files into 
> classes and methods could somehow eliminate all forms of @ nodes in 
> Leo.  I considered that possibility yesterday, for several hours.  But the 
> result would not be Leo.  Specifically, the result would lack the following 
> crucial capabilities:
>
> - Organizer nodes.  @clean does this, without embedded sentinels.
> - gnx's (unique, invariant data).
> - uA's (arbitrary data).
> - Clones, living in a separate outline, not an external file.
>
> *Summary*
>
> Leonine 

Re: file manager functions

[john lunzer]

Easiest way would probably be an @move-file button/command where you 
specified a new location for the file in a popup. The command would: update 
the header with the new location, save the file (essentially copying it), 
and remove the file at the original location. This would not strictly be a 
"move"

Leo mostly follows a push/pull model for files. Where saving "pushes" the 
file(s) to the file system and updating an @clean file "pulls" from the 
file system (and if necessary merges). The "active_path.py" plugin can 
extend the functionality of "pull" operations. I'm not sure if this was 
intentional or not, but it creates a bit of a disconnect from directly 
manipulating the file system itself like people would be used to doing in 
file manager.

On Wednesday, February 27, 2019 at 4:53:14 AM UTC-5, Josef wrote:
>
> Several years ago there was some discussion about Leo as a file manager.
> I often find myself moving files around, which have an associated node in 
> leo.
> With associated node I mean not only @file (@clean) nodes, but also @url 
> nodes and recently often nodes with file://path-to-filename nodes in it.
>
> Currently, when I want to move these files to a new location I first need 
> to open a file manager, locate the file(s), move them with the file manager 
> to a new location, then adjust the node in Leo to point to the same file 
> again. In another post I was wishing leo could find the new location 
> automatically (for example by storing and then finding the SHA1 hash of the 
> file, however momentarily I would already be happy with something much 
> simpler.
>
> There are a multitude of ways how a node can be moved around in Leo, so it 
> is probably not easy to cover them all.
>
> I found the enddrag2 event handler, which I could use to hook a file move 
> (or copy) into, but I would need to know if the CTRL or ALT keys were 
> pressed or not, since this modifies the move.
>
> Perhaps there is a more general way to hook into the system when a node 
> gets moved? I need to treat cases differently when the node gets copied (or 
> cloned).
>
> - Josef
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Interesting article about WebAssembly

[john lunzer]

I'm definitely using that phrase in the future.

On Wednesday, February 27, 2019 at 6:36:35 AM UTC-5, Edward K. Ream wrote:
>
>
>
> On Wednesday, February 27, 2019 at 5:32:21 AM UTC-6, Edward K. Ream wrote:
>
> > WebAssembly is fascinating engineering. For example, consider the GC 
> proposal 
> , 
> referenced from this wasm proposal 
> . 
>
> Hehe.  There be jokes.  From the Reference types proposal:
>
> At this time, the contents of this repository are under development and 
> known to be "incomplet and inkorrect".
>
> 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: Pharo Chronicles: time for a break

[john lunzer]

As far as I know this is already possible 
. The author of Flexx, 
Almar Klein, seems to be devoting a fair amount of his free time to 
WebAssembly. Many (including Almar) see it as a good foundation for the 
future of programming languages.

On Tuesday, February 26, 2019 at 8:09:46 AM UTC-5, Edward K. Ream wrote:
>
> There is a clear path for Leo in the JS world. I've already prototyped Leo 
> in the browser. I hope Joe Orr is continuing to develop his vision. 
> Finally, WebAssembly  that will soon support 
> Python program in browsers.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Best Python IDE's on Slant.co

[john lunzer]

I seem to remember you saying that you're a writer. Let me know if you end 
up using Scribble (and subsequently Pollen) at all, they both look super 
interesting. 

On Monday, February 25, 2019 at 9:33:24 AM UTC-5, Chris George wrote:
>
> I recently got interested in Racket. 
>
> https://programbydesign.org/materials 
>
> Chris 
>
> On Mon, Feb 25, 2019 at 5:54 AM john lunzer  > wrote: 
> > 
> > Thanks, I've read this before but I read it again. The quality of 
> "power" as Dr. Graham describes it is only useful if it can be accessed. 
> > 
> > If you're a startup and your goal is to make a huge splash and 
> obliterate your competitors, as he implies, then a nuclear powered 
> programming language could help. If you work for a large company in a mixed 
> discipline team with a large legacy of code then a nuclear powered language 
> with less than upper tier readability is going to hold your team back long 
> enough for your competitors to "crush" you. In my experience lisps struggle 
> in the readability department. 
> > 
> > Maybe things are different now than they were in 2001. Perhaps lisps do 
> have great power, but if 18 years has proven anything it's that the power 
> of lisps is not accessible (and therefor has low utility) to the vast 
> majority of those who program. On both the TIOBE and PYPL indexes there are 
> no lisps in the top 20 and only a single functional language (scala, at 14 
> on PYPL). Redmonk is more generous, which has scala at 12 and haskell at 
> 19, but still has no lisps. To be clear I'm not making any judgement on the 
> "goodness" of lisps or functional languages. I'm noting trends in an effort 
> to show that choosing a programming language based only on "power" is not 
> an intelligent choice. 
> > 
> > Readability and accessibility fuel my ability to program effectively, I 
> have not felt the need for more power. My biggest needs as a professional 
> engineer (who mostly programs all day) have been better tools, better 
> organization, and better documentation. Perhaps that is how I ended up in 
> the Leo community as those three things appear to be pillars of the 
> community. 
> > 
> > On Monday, February 25, 2019 at 3:05:15 AM UTC-5, Matt Wilkie wrote: 
> >>> 
> >>> [1] http://www.paulgraham.com/avg.html 
> >> 
> >> 
> >> Thanks 
> >> 
> >> 
> > -- 
> > You received this message because you are subscribed 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: Best Python IDE's on Slant.co

[john lunzer]

Thank you for the this other article, seems I wasn't the only one to come 
the same conclusion after reading Dr. Graham's article. Context is 
definitely key when making these arguments, which I think Dr. Graham 
acknowledged only in spirit. "Power" is his sole focus and despite 
acknowledging the startup vs. big business context his argument is that if 
you're not using lisp you're "at a disadvantage".

Matthew Butterick's article is a much more balanced exposition of Lisp and 
Racket was probably a good choice for language evangelism as Racket seems 
to have a strong focus on their tooling and documentation. The Scribble 
sublang in particular is pretty interesting. 

On Monday, February 25, 2019 at 2:58:31 PM UTC-5, Offray Vladimir Luna 
Cárdenas wrote:
>
> Mattew Butterick has similar concern about Lisp flattery regarding its 
> power and even touch another popularity index (based on GitHub this time 
> and before Clojure), as you can see on [1]. I think that he makes a pretty 
> good argument about Lisp as a non professional programmer who codes (like 
> myself), that can be also be applied to Pharo, connecting power with 
> expressiveness, and later with the documentation and the ecosystem
>
> [1] https://practicaltypography.com/why-racket-why-lisp.html
>
> Discourse about alternative programming languages has been also co opted 
> by the "startup fashionist logic" and put them in a contrast with 
> traditional business programming languages, but some times they could make 
> sense also in research, writing and other contexts, where we are trying to 
> build a case for communities of non professional programmers who code and 
> are interested also in accessibility and readability, but from different 
> perspectives. That's the path I'm exploring with Grafoscopio. It has been 
> an important community building tool (despite its early stage and bugs).
>
> Cheers,
>
> Offray
> On 25/2/19 8:54, john lunzer wrote:
>
> Thanks, I've read this before but I read it again. The quality of "power" 
> as Dr. Graham describes it is only useful if it can be accessed. 
>
> If you're a startup and your goal is to make a huge splash and obliterate 
> your competitors, as he implies, then a nuclear powered programming 
> language could help. If you work for a large company in a mixed discipline 
> team with a large legacy of code then a nuclear powered language with less 
> than upper tier readability is going to hold your team back long enough for 
> your competitors to "crush" you. In my experience lisps struggle in the 
> readability department.
>
> Maybe things are different now than they were in 2001. Perhaps lisps *do 
> *have 
> great power, but if 18 years has proven anything it's that the power of 
> lisps is not accessible (and therefor has low utility) to the vast majority 
> of those who program. On both the TIOBE and PYPL indexes there are no lisps 
> in the top 20 and only a single functional language (scala, at 14 on PYPL). 
> Redmonk is more generous, which has scala at 12 and haskell at 19, but 
> still has no lisps. To be clear I'm not making any judgement on the 
> "goodness" of lisps or functional languages. I'm noting trends in an effort 
> to show that choosing a programming language based only on "power" is not 
> an intelligent choice. 
>
> Readability and accessibility fuel my ability to program effectively, I 
> have not felt the need for more power. My biggest needs as a professional 
> engineer (who mostly programs all day) have been better tools, better 
> organization, and better documentation. Perhaps that is how I ended up in 
> the Leo community as those three things appear to be pillars of the 
> community.
>
> On Monday, February 25, 2019 at 3:05:15 AM UTC-5, Matt Wilkie wrote: 
>>
>> [1] http://www.paulgraham.com/avg.html 
>>> <http://www.google.com/url?q=http%3A%2F%2Fwww.paulgraham.com%2Favg.html=D=1=AFQjCNH0azmoEUUGmILOkVA1JqtZ1mLPoA>
>>
>>
>> Thanks 
>>
>>
>> -- 
> You received this message because you are subscribed 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: The Pharo Chronicles: First impressions

[john lunzer]

I don't think I dug far enough to notice the bugs, but I had a similar 
impression about Pharo's browsers, and after some consideration clumsy is 
the right word. I felt like if there was a powerful system of live coding 
somewhere in Pharo the browsers weren't revealing it to me in an elegant or 
efficient manner. 

On Saturday, February 23, 2019 at 7:19:29 AM UTC-5, Edward K. Ream wrote:
>
> I am now actually using Pharo, as opposed to reading about it and 
> executing a few lines in the playground.  The "Pharo Chronicles" threads 
> will be notes to myself, and possibly to others down the road.
>
> This post will be pre-writing for various Pharo bug reports.  Nobody knows 
> better than I how irritating it can be for devs to deal with unjustified 
> criticisms from clueless newbies. I welcome any corrections Offray or 
> others may have.
>
> *The most important first impression*
>
> There is *only one reason* why I am interested in Pharo, namely that it 
> provides a "live" environment that can be changed without reloading. Imo, 
> exploring how this happens is worth any amount of work, regardless of 
> problems with Pharo. Please keep this in mind as you read on.
>
>
> *The good*
>
> The Pharo launcher is a VM manager.  The ability to create specialized 
> images easily is a big plus. Especially since newbies like me are prone to 
> having to recreate them frequently ;-)
>
> The language is good to excellent. Moreover, the browser/runtime 
> integrates reports quality (linting) problems automatically.  And it's easy 
> to configure (enable or disable) those message in a flexible manner.
>
> *The not so good...*
>
> For such a supposedly powerful system, Pharo suffers too many problems.  I 
> suspect the Pharo devs have either gotten used to these problems, or have 
> work flows that minimize them.  But newbies surely will be aware of the 
> following...
>
>
> *The IDEs suffer from Alzheimer's*
>
> 1. The Launcher has a "quit on launch" checkbox, but there seems to be no 
> way to remember what it should be on the next launch.  Certainly it is not 
> saved automatically.  Using the Settings Browser (in the launcher) to 
> change this also has no effect.
>
> 2. Neither the Launcher nor Pharo images remember the save status.  
> Quitting immediately after a save *still* brings up the "Do you want to 
> save" dialog.  It's bush league.
>
> *Bugs*
>
> 1. There seems to be no way to configure what a plain click in an open 
> area does.  Imo, the first click (of any kind) should set the focus if 
> focus is not already in the Pharo pane.  But no, the first click brings up 
> the "World" menu.  This is wretched interface design.  At the very least, 
> the user should be have the option to configure what plain clicks do.
>
> 2. On Windows (and possibly other platforms) colons in image names confuse 
> the launcher.
>
> 3. The Pharo file dialogs are wretched. The native file dialogs on Windows 
> and Linux are much better.
>
> 4. I just got bit by a serious bug.  An image suddenly started complaining 
> that it doesn't have the proper write permissions to save itself...
>
> *Pharo browsers are clumsy*
>
> For me, this is the big one. The Pharo community is putting up with an 
> ancient interface design for browsing. A Leonine browser would solve a lot 
> of problems.  Naturally, this creates a big opportunity for me to 
> contribute to the Pharo world.
>
> Pharo browsers show you what *they* want to show you, not what *you* want 
> to see.  Leo is a template for a *much* better way.  
>
> The general idea is simple:  use a single outline for *everything.*  
> Instead of dragging in the entire browser view, the Leonine view would use 
> *references* to only those objects that the user wants to see.  These 
> references would be a behind-the-scenes "artifact".  They may well exist in 
> existing browsers. Unless I am completely mistaken, references (or their 
> equivalent) must be possible in Pharo.
>
> The Leonine browser would, of course, also support Leo's clones.
>
> An example will clarify what Leo has to offer.  Suppose you want to create 
> a new class, along with its test class.  You would create those classes in 
> the Leo browser, and *that's all you would see.* You would use *real* 
> organizer nodes, as usual, not as a special case but as a natural part of 
> creating your classes.  You would use clones to focus on the methods of 
> interest.  You could put related methods in the same node.  Etc.
>
> This would be an earth shaking development in the Pharo world.  No more 
> filters.  No more wretched side-by-side browser panes.  Much better use of 
> screen real estate.  No more special cases.  Any Leonine node could refer 
> to any Pharo object, including tracebacks.  Which brings me to...
>
>
> *Exception handling in the transcript*
>
> The ui may be able to represent exceptions, say in the Transcript.  The 
> analogy is Terry's clickable error messages generated by pylint and other 
> parts of Leo. 

Re: Best Python IDE's on Slant.co

[john lunzer]

Or Pharo, or emacs... depending on who you ask. 

On Friday, February 22, 2019 at 5:33:50 AM UTC-5, Edward K. Ream wrote:
>
> On Fri, Feb 22, 2019 at 12:57 AM Matt Wilkie  > wrote:
>
> I added Leo to the list of Python IDE and Editors to the Slant.co 
>> comparison site and seeded a few pros and a con. I get a kick out of the 
>> fact that it seems to number 42. ;-) 
>> 
>>
>
> Hehe.  Surely Leo is the Answer to the Ultimate Question of Life, the 
> Universe and Everything.
>
> 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: Is it time to require Python 3?

[john lunzer]

>
> If it won't cause trouble with downstream distributions I'd even go so far 
>> as to request v3.6+ -- simply because I absolutely love f-string formatting 
>> (
>> https://www.blog.pythonlibrary.org/2018/03/13/python-3-an-intro-to-f-strings/
>> ).
>>
>
> We can consider that later.
>

I think Matt has a good point, if you're going to jump the Python2 ship you 
might as well jump into the latest model. 3.6 seems reasonable, it was 
released December 23, 2016. It's not like Leo 5.x is going to disappear and 
leave users with no Leo. In fact you might even consider super critical bug 
fixes and security fixes for the last of the 5.x series. They just wouldn't 
get the new bits and bobs. Personally I would go with Python 3.7 (released June 
27, 2018) as it is *the* most up to date and it, to me, has one of the more 
important official language changes: dict now *officially* maintains 
insertion order. The same reasoning works for justifying Python 3.7, if you 
want to use Python 3.6 or lower you always have the option of using Leo 
5.x. 

Time flies, before you know it Python 3.8 will be out 
, and you be wondering why you 
didn't go with Python 3.7. 

I think it makes sense for Leo's legacy as well. When you "move on" there 
is every reason to try to make Leo's code base future proof.

All that said, if you don't think you can utilize the features in newer 
releases of Python 3.x it obviously doesn't make sense to require the newer 
versions. 


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: My new friend Altix

[john lunzer]

>
> On 'minibuffer': I think some of the long delay for me is not knowing the 
> term 'buffer' in this context and thus following the lazy thinking route, 
> "huh. that's a nonsensical-to-me word, must not be for me". In my 
> experience buffering was what you needed to stop your music and videos from 
> skipping. Maybe it should be called the Command Bar?
>

I've seen in this forum and in emacs conversations a call for just such a 
change, in some cases people have proposed the compromise "Command buffer", 
but the bar/buffer itself would just say "Command: ". Vim calls it 
"command-line mode". Sublime Text calls it "command palette". 
 

> Had I known this, Leo would likely have started life in emacs...
>>
>  
> Well I for one am grateful for your delay in seeing. At one point I tried 
> to learn emacs, I really did. While I could appreciate it as a cathedral to 
> visit, working in it was painful -- literally. I was on the border of RSI 
> and all the chorded keyboard commands made my wrists hurt. So vim won. ;-) 
> ...and lost later, but that's a different story.
>
> Matt
>

I failed to learn emacs a couple of times. I would so sad if somebody wrote 
off emacs because they felt they had to wear uncomfortable heels to the 
party, so to say. Trust me, it's not that formal of an event. The spirit of 
emacs, just as with Leo, is: if it doesn't work you then change it. With 
both emacs and Leo, that option is given to you when you walk through the 
door.

There are many solutions to the physical interface problem. The simplest is 
to rebind caps lock to CTRL. Another option is to swap left-ALT and 
left-CTRL (this configuration is actually what the physical keyboards 
looked like when emacs was developed, hence why CTRL is used so 
prominently). This is probably something everyone should do anyway, but it 
becomes particularly helpful in emacs. If the vim input model worked for 
you then evil  provides robust vi 
bindings. god-mode  is another 
solution which puts you into a "command" mode that allows you to enter your 
commands without pressing CTRL or ALT. 

Obviously "you gotta want it", which I doubt you do anymore, but just felt 
I had to do my civic duty.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: My new friend Altix

[john lunzer]

In emacs you can often find the command you want by executing 
apropros-command.

By enabling the built-in ido-mode in emacs you get completion as you type 
in the minibuffer, very useful:

(setq ido-enable-flex-matching t)
(setq ido-everywhere t)
(ido-mode 1)


The next evolution of emacs's minibuffer is ivy 
. It makes the minibuffer do everything 
you didn't know you needed. Amongst many other useful features, not only do 
you get completion as you type but you're also shown the "docstring" for 
each command.

Had I known this, Leo would likely have started life in emacs...
>
> Edward
>

Leo and emacs would have been a great match, though I much prefer writing 
Python to elisp. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Who should be using Leo

[john lunzer]

I would add: you are a programmer that desires powerful code/project 
organization tools.

I'm not sure what brought me to Leo, but I stayed because I could divide up 
my code into language agnostic chunks that made sense to me, no longer 
confined to what any one's syntax had to offer in terms of organization. 

Leo is a king here. emacs with outshine and ivy can give you cheap 
imitation of what Leo offers. Obviously there is pharo+grafoscopio but my 
work culture can't tolerate that level of unorthodoxy, it could barely 
handle Leo. 

On Thursday, January 17, 2019 at 1:13:21 PM UTC-5, Edward K. Ream wrote:
>
> There are two main reasons to use Leo:
>
> 1. Programmers use Leo's API to write powerful scripts.
>
> 2. Non programmers use clones to organize data.
>
> So if you *aren't* a programmer, and you *don't* use clones, then why, 
> exactly, are you using Leo? You would be much better off with TheBrain 
> .  Really.
>
> Edward
>
> P.S. Imo, all programmers should use clones, but that's a matter of the 
> next posting.
>
> 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: Leo in 2019

[john lunzer]

Recently I (foolishly?) implemented a fairly complex workflow management 
software entirely in `bash`. Often seen advice on stackoverflow regarding 
bash is many variations of: "bash lacks this/that/other, don't use it for 
serious/medium/large projects! Don't even think about it!". 

I was surprised to find that the deficiencies of bash forced me to think 
more deeply about data structures, testing, and managing scope. I don't 
recommend anyone do this in a production setting but as a 
learning/expanding exercise I think this kind of paradigm "shrink" has 
value.

This benefit could probably be achieved more elegantly in other "batteries 
*not* included" languages. I've read that Lua has only one data structure, 
Tables , the rest you implement yourself.  
As another option scheme is often cited as "batteries not included". 

On Monday, January 7, 2019 at 10:05:14 AM UTC-5, Edward K. Ream wrote:
>
> On Monday, December 31, 2018 at 4:32:43 PM UTC-6, Edward K. Ream wrote:
>
> I am most interested in grand challenges.
>>
>
> Some intermediate challenges:
>
> - Applied type checking: support for rope (refactoring) and better code 
> completion (jedi, etc.).
>
> - It's time to expand my programming horizons with stuff like prolog and 
> haskell.
>
> Edward
>

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

Re: LeoWapp Getting Started

[john lunzer]

Interest yes, but not time. Likely also why the issue has lain dormant for 
this long. I once had aspirations of doing much of what you've done but 
worked picked up quite significantly and hasn't settled down. That said, 
I'm grateful that you've come so far. Almar obviously would be in the best 
position but I think his bandwidth is very limited.

On Friday, December 7, 2018 at 8:50:33 AM UTC-5, Edward K. Ream wrote:
>
> On Friday, December 7, 2018 at 7:30:08 AM UTC-6, Edward K. Ream wrote:
>
> thanks for the heads up about PhosphorJS .
>>
>
> As I read the PhosphorJS sources for the widgets 
> , 
> I wonder whether Almar might have transliterated the TypeScript sources 
> into pscript.  If so, this would be the path to adding support for menus to 
> flexx.
>
> John, is this something that might interest you?  If so, the first step 
> would be to check in with Almar to see if my suspicion is correct.
>
> Edward
>

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

Re: LeoWapp Getting Started

[john lunzer]

>
> The menus are missing because I haven't created them.  I've just made a 
> note of this in #1005.  I don't see any menu demo's on the flexx demo and 
> howto page 
> .  I'll 
> ask Almar Klein about this.
>

Flexx hasn't implemented them either, I opened an issue for this about a 
year ago (https://github.com/flexxui/flexx/issues/315).  Flexx uses an 
underlying JS library called Phosphor for its GUI elements. Phosphor fully 
supports menus and they look and feel great. I'm not sure what the effort 
is to map Phosphor's menu's to Flexx but given that it's been a year and 
Almar hasn't touched it (granted he has seemed very busy) I'm guessing it's 
not trivial. 

On a side note JupyterLab also uses Phosphor. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: cool things: python-fire

[john lunzer]

Very interesting. Sounds like it removes a lot of the effort for a process 
I execute all the time. 

Another "one liner" I use for code disection is:

from IPython.terminal.embed import InteractiveShellEmbed; ips = 
InteractiveShellEmbed(); ips()


Although if I have pudb available I'll often just use that.

On Sunday, November 4, 2018 at 1:10:23 PM UTC-5, Matt Wilkie wrote:
>
> Drop this in the "cool things seen out there" and "probably room for this 
> in my toolkit" bins:
>
> *Python-fire  -* 
> *a library for automatically generating command line interfaces (CLIs) 
> from absolutely any Python object. *
>
>
> *...call Fire in your library, then you can run all of it's functionality 
> from the command line without having to keep making changes to a main 
> method. *
>
> *...**take an existing module, maybe even one that you don't have access 
> to the source code for, and call Fire on it. This lets you easily see what 
> functionality this code exposes, without you having to read through all the 
> code.*
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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 LeoWapp and flexx are important

[john lunzer]

I can't believe somebody else got excited about Flexx! Nice to see you've 
also made the developer aware as well.

I too think that Flexx is important to the future of Python. 

On Monday, November 12, 2018 at 10:07:24 AM UTC-5, Edward K. Ream wrote:
>
> My brother Speed and I are excited about LeoWapp and flexx.  Here are some 
> notes from a conversation we had two days ago.
>
> *Goals*
>
> Speed wants to edit Leo files on a cell phone without an internet 
> connection.  This would be useful for road warriors.  Do edits in a cafe 
> somewhere. There is little need for scripting features such as Ctrl-B. That 
> can be done later, when using a laptop.
>
> *Applications*
>
> Speed uses a remotely hosted Ubuntu desktop without a front end. Only a 
> console is available.  LeoWapp will supply the missing front end!  This 
> opens up Leo to anyone with a cell phone or anything else that has a 
> browser.
>
> LeoWapp opens up every single JS package to the python world, including 
> Joe Orr's LeoVue. Almar shows us how to instantiate *any *JS package from 
> Python. He has invented an amazingly simple, general methodology to hook 
> everything together.
>
> Imo, flexx is one of world's most important programming tools, on a par 
> with Python itself and git. It is a wonderful bridge between the Python and 
> JS worlds. It is a major contribution to Python.
>
> *Summary*
>
> LeoWapp will not be for everyone. However, LeoWapp promises to be more 
> useful more powerful than Leo's console gui.  *Important*: LeoWapp is *only 
> *a gui.  Leo's core will remain unchanged.
>
> asyncio became official with Python 3.5 (September, 2015) so flexx and 
> leoflexx.py are on the leading edge.
>
> 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: Some tips for those new to Leo from hacker news

[john lunzer]

I've seen scathing accusations of other codebases as well. I've seen Vim's 
codebase regarded poorly, as is Vim's scripting language. I've seen 
articles belying the complexity of Netbeans' codebase. Elisp (on which much 
of emacs is written) is often referred to as "terrible" or "horrible", 
resulting in an ugly/brittle codebase. 

My conclusion is that mature IDEs and editors are complex and challenging 
design decisions (made by talented people) must be made along the way. For 
random commenters to make these accusations is just foolishness. Foolish if 
they think they could have made markedly better decisions if put in the 
same position. Foolish if they think that they could have had the 
persistence to *continue *making them for the decades necessary to create 
such a complex piece of software. 

On Thursday, August 16, 2018 at 11:31:58 AM UTC-4, Edward K. Ream wrote:
>
> *Horrible code*: A pretty wild accusation. Please file an enhancement or 
> bug request if a specific part of Leo's code gives you problems.  Leo's 
> code has improved spectacularly many times in the past, but there is always 
> room for improvement.
>
> 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: A prototype of fast Qt tree drawing

[john lunzer]

This was an amazing "conclusion" to these events. I too want to take the 
opportunity to apologize to Edward for accusations, implied or explicit. I 
learned from this series of interactions and it appears Vitalije has as 
well. Edward, it is my hope that you can take something good away from 
this, ideally: inspiration, confidence, and a new skill set for dealing 
with an "uprising". Edward, you will always be the father of Leo. While in 
an open source community that doesn't mean you deserve the final word, as I 
believe that type of policy can ultimately harm a community, it does mean 
you deserve the highest level of respect for being the unwavering core of 
this community.

In my own defense, I do not think my own comments were motivated by any 
lack of confidence in Edward, but in a deep desire that Leo evolve. 
Vitalije's proposal appeared to offer a tantalizingly expedient path toward 
that evolution. However, it is embarrassingly clear now that deep desire 
should not allow "progress" to become the bottom line. A lesson I will take 
with me through life.

Equally as important, to Vitalije, I hope you feel no embarrassment or 
shame behind your proposal. Whether you consider it to be failed or not it 
appears your motivations were similar to mine. I've never sensed ill-will 
present in any of your interactions. You are clearly an extremely skilled 
individual and have every reason to be confident in your proposals. I 
encourage you to never shy away from making audacious proposals. I am 
excited to see your future work and hope you share with us. 

Thank you to everyone who has put in time and energy into improving Leo. 

On Wednesday, August 8, 2018 at 2:10:16 PM UTC-4, vitalije wrote:
>
> I am glad that you started to work on this issue. 
>
> Your recent posts in other thread have opened my eyes and I was planing to 
> encourage you to go and do this issue yourself in your own way.
>
> In our previous discussions and disagreements I misjudge you. I was at 
> some points annoyed by your replies because I was thinking that you 
> disagree with my ideas for some bad reason. I was suspecting that your 
> pride is being hurt or something similar, but I was very wrong indeed. You 
> haven't done anything to hurt me or annoy me yet I was annoyed. Now I see 
> it was all my fault. My suspicions were the only reason I was annoyed by 
> your comments. It was very hard for me to believe that you really think the 
> way you write. So, I suspected that you weren't fully honest. Now I am 
> truly sorry and I do apologize  for even mentally accusing you for 
> something you were not guilty of. 
>
> Your recent posts made me believe that you are honest in your opinions and 
> you truly think the way you write. The only trouble is that your opinions 
> are quite different than mine. We are looking at the same code but we see 
> totally different things and we make opposite conclusions. When I see 
> something as a design flaw you proudly claim that it was your intention to 
> make it just like that. When I am proud of some code thinking it is almost 
> perfect, you see some flaws and defects in it and naturally you feel need 
> to improve it.
>
> It is astonishing how different our minds are. Considering all this, it is 
> hard to believe that you and me will ever be able to work on the same file 
> and both be satisfied with it. Most likely if one of us is satisfied the 
> other one will be unsatisfied. 
>
> Our differences are not necessarily a bad thing. It could be also an 
> advantage to have different perspectives and different opinions about any 
> programming problem.
>
> After all efforts I put in ltm-leo branch and having all unit tests pass, 
> I am not very happy with the resulting code. Yes, I have put on my todo 
> list to clean up and document the code, but somehow I cant find enough will 
> power to do this. Personally I am unsatisfied with the code I just wrote. 
> In fact if I should vote on this code right now, I might not wish to 
> approve it.
>
> I just learned that Leo is in so many places designed in the way that is 
> most unnatural for new data model. To make it work with new model, I had to 
> write many lines of code that I am not very proud of, and final result is: 
> Leo works with it, but make a very poor usage of new data model. To really 
> take the advantage of new data model it has to be redesigned quite a lot. 
> It is highly unlikely to happen that we fully agree on all these changes.
>
> *Conclusion*
>
> I think that the best (or most productive) way forward is that I continue 
> to work on miniTkLeo and perhaps one day it may become a mini Leo or Leo's 
> little brother. I hope that you dont mind this repository staying under 
> leo-editor team on github. I might borrow some code from Leo. I see this as 
> an opportunity to start from a clean sheet, and to leave out some ancient 
> features of Leo and also to use latest Python version. Python 3.6 and later 
> are huge 

Re: Update re: new model

[john lunzer]

This *is* exciting. One of my more pressing questions: if a future front 
end were written which does not use PyQt/PySide, would it benefit from the 
same speedups during drawing? 

On Saturday, July 28, 2018 at 3:40:15 PM UTC-4, vitalije wrote:
>
> I have incorporated new data model into Leo and all unit tests pass. I 
> have estimated two weeks would be enough for the task, and today is 
> fifteenth day since I have started (see other thread 
> ). 
> Running all unit tests with new model on my machine takes 40.875s, while 
> running them without new model takes 45.292s. So, after all some speed 
> improvement has been achieved. Certainly this is negligible improvement, 
> but it is important. Let me explain why. 
>
> Two days ago I had a version which passed all tests for the first time. 
> However, there have been serious speed issues. Running all tests with new 
> model were almost two times slower than running without new model. I was 
> utterly disappointed and almost had given up. During the last two days I 
> rewrote new position class and commander generators and now everything 
> works at least not slower than without new model.
>
> Please note, unit-tests are executed using NullGui, so the speed 
> difference between the new tree drawing and old one were not taken into 
> account. And this difference is major speed improvement.
>
> Running experiment like the one shown in the video 
> now takes on average 35ms. 
> The example in video is 1.3ms but it didn't create undo/redo data. Now with 
> creating undo data it takes a bit longer (35ms). It is still 48 times 
> faster than Leo without new data model (which needs 1700ms).
>
> By the way, running demote/promote cycle 100 times with creating undo data 
> every time didn't cause any GC activity. There has been an increase in 
> memory usage (about 300Mb) for these 200 operations on LeoPyRef.leo. If 
> this ever becomes a problem, there are some easy ways to encode only the 
> difference between current and previous data.
>
> There are still some things that I have to do before publishing code. For 
> example, status line is not updated on selection, selecting chapter using 
> minibuffer commands works, but selecting from the select box in the toolbar 
> has no effect. Most likely some plugins that use old tree are not working 
> with the new tree at the moment. I don't expect those issues will take more 
> than a week or two to complete.
>
> Since I have rewritten my initial solution, there are certainly some 
> unused methods and functions all around that I need to clean before 
> publishing code.
>
> There are also new things I have learned about Leo and I wish to discuss 
> them but right now I am a bit exhausted and I have to rest for the next few 
> days.
>
> 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: Guidelines for collaboration

[john lunzer]

I like your more verbose discussion but your summary lacks the human 
element present in your more comprehensive statements. 

I recommend adding "Be specific" to the guidelines, disagreements often 
arise simply from people holding two different definitions for the same 
concept. 

I recommend dropping "The less said the better". Sometimes "more" needs to 
be said. Some people are also naturally more verbose. Both of those things 
are fine and simply need to be dealt with on a case by case basis.

I recommend avoiding "Being blunt". The word "blunt" has more negative 
connotations than positive. It's a word with a lot of ambiguity and dual 
meaning, thusly telling somebody to be blunt can be interpreted in a way 
you may not have intended. 

Other than that, almost everything said here can help avoid "heated 
discussions". 

On Saturday, July 14, 2018 at 4:23:35 AM UTC-4, Edward K. Ream wrote:
>
> There have been several remarks on collaboration in the "Three demos" 
> thread .  
> It's worth its own thread.
>
> > John: Skepticism is fine when maintaining a mature code base, but *any* 
> show of hostility to change ends in results like this: contributor 
> alienation. 
>
> I understand John's wanting to "make nice", but the word "hostility" can 
> be taken several ways, as I'll explain.
>
> > Xavier: premature judgement is the root of all evil!
>
> This is a fine principle, but I don't think it is the heart of the matter.
>
> Here are the principles I follow. I recommend them to all devs.
>
> *Use "I" messages*
>
> Talk about what *you* think, or what *you* feel.  Rebecca taught me this 
> when we were first married.  It makes a world of difference.
>
> Not: "You are an unfeeling so and so".
>
> But: "I feel hurt by what you said".
>
> This can lower the temperature when things get hot. It is less likely to 
> be perceived as a personal attack.  But beware of false "I" message, like, 
> "I'm sorry you are an unfeeling so and so" :-)
>
> Another caveat: The "Boeing Way" is management's statement: "You can do X 
> if...".  Imo, this is a superb mental "trick". It works because it empowers 
> the messages receiver to solve problems.
>
> *Make the subject technical, not personal*
>
> Discuss the pros and cons of the technical issue under discussion, not the 
> people discussing the issue.
>
> Don't take criticism of your ideas personally, but be aware that anyone, 
> including yourself, is prone to do so.
>
> *Say what you mean*
>
> My intention is to always say what I mean as clearly as I can, without 
> weasel words.  This can be mistaken for premature judgement.
>
> There is one great benefit to plain speaking. If I am wrong, I shall be 
> seen as *clearly *wrong, and my mistakes will be corrected.
>
> I train devs to push back against my ideas by changing my mind. Two days 
> ago I said that I would not approve the new data model while I was project 
> leader.  Yesterday I said that I would approve Vitalije's work if Terry 
> also agreed.
>
> Was my first statement a "premature judgement"?  No.  It was my clear 
> opinion at the time.  And implicitly, it was a test of Vitalije's 
> commitment. If Vitalije did not have the gumption to fight for his ideas, 
> he would not have earned the right to put them into practice.
>
>
> *The less said, the better*
>
> We mistake words for power. We think, more the better.  Often, the reverse 
> is true.
>
> I changed my mind yesterday for several reasons, but one was Vitalije's 
> statement that supporting hoists (and chapters) would take about 30 minutes.
>
> Then he said that a hoist would just be a slice of the data structure. 
> It's a great picture. My thought was, that's elegant.  A hoist is, 
> conceptually, exactly that slice.
>
>
> *Keep calm, don't panic*
>
> Don't write what you may regret.  Sleep on important replies.  Edit out 
> anything that could be considered a personal attack.
>
> *Summary*
>
> The following are useful guidelines, not cure-alls:
>
> - Use I messages.
> - Keep discussions impersonal.
> - Be concise, even blunt. The less said, the better.
> - Pictures are more persuasive than words.
> - Be willing to change your mind.
> - Be willing to push back, to fight for your ideas.
> - Stay calm and respectful.
>
> All comments welcome.
>
> Edward
>

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

Re: Three demos showing how to improve drawing speed

[john lunzer]

While cooler heads prevailed it easily could have gone the other way, so I 
will not retract my post. I'm happy to see this positive movement.

On Friday, July 13, 2018 at 3:08:46 PM UTC-4, john lunzer wrote:
>
> I don't blame you. I agree that contributions should be considered 
> unconditionally based on multiple metrics of merit (solves problems, adds 
> features, increased or decreased usability, addition or reduction of code 
> complexity, adherence to user API, and passes unit test). 
>
> Skepticism is fine when maintaining a mature codebase, but *any* show of 
> hostility to change ends in results like this: contributor alienation. 
>
> In the news you will see that Guido van Rossum stepped down as head and 
> face of python. He cited many reason for leaving but one of them was a 
> "fight" over a proposed change, quote from theregister 
> <https://www.theregister.co.uk/2018/07/13/python_creator_guido_van_rossum_quits/>
> :
>
>> In a mailing list post 
>> <https://mail.python.org/pipermail/python-committers/2018-July/005664.html> 
>> on 
>> Thursday titled, “Transfer of Power,” he wrote: “Now that PEP 572 is done, 
>> I don't ever want to have to fight so hard for a PEP and find that so many 
>> people despise my decisions.”
>
>  
> Guido probably would have started transitioning to a support role anyway 
> soon, given myriad other reasons he gave for stepping down, but it seems 
> like the "fight" he was part of left him with the same feeling that 
> vitalije may be leaving with (at least as a regular contributor).
>
> I've involved myself only because I've been hostile in this and other open 
> source projects in the past and seen the damage it did to the community and 
> the project. In every case my hostility either pushed me away or pushed 
> somebody else away. 
>
>
> On Friday, July 13, 2018 at 9:54:50 AM UTC-4, vitalije wrote:
>
>> What makes you think that I would do something like that under all these 
>> conditions and knowing your general attitude towards new data model? It 
>> seems like waste of my time. I have better things to do. The #942 is a bug 
>> in the code that I don't think I am responsible for. I haven't write it, 
>> and I have suggested several workarounds which were all ignored. I have 
>> even expressed real doubt that it can be fixed the way you would approve. 
>> So, unless you or anyone else do something about that bug it will remain 
>> unsolved. If other users can live with this bug, I can live too. But those 
>> who are bothered with this bug should raise their voices and try to 
>> convince you.
>>
>> 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: Three demos showing how to improve drawing speed

[john lunzer]

I don't blame you. I agree that contributions should be considered 
unconditionally based on multiple metrics of merit (solves problems, adds 
features, increased or decreased usability, addition or reduction of code 
complexity, adherence to user API, and passes unit test). 

Skepticism is fine when maintaining a mature codebase, but *any* show of 
hostility to change ends in results like this: contributor alienation. 

In the news you will see that Guido van Rossum stepped down as head and 
face of python. He cited many reason for leaving but one of them was a 
"fight" over a proposed change, quote from theregister 

:

> In a mailing list post 
>  
> on 
> Thursday titled, “Transfer of Power,” he wrote: “Now that PEP 572 is done, 
> I don't ever want to have to fight so hard for a PEP and find that so many 
> people despise my decisions.”

 
Guido probably would have started transitioning to a support role anyway 
soon, given myriad other reasons he gave for stepping down, but it seems 
like the "fight" he was part of left him with the same feeling that 
vitalije may be leaving with (at least as a regular contributor).

I've involved myself only because I've been hostile in this and other open 
source projects in the past and seen the damage it did to the community and 
the project. In every case my hostility either pushed me away or pushed 
somebody else away. 


On Friday, July 13, 2018 at 9:54:50 AM UTC-4, vitalije wrote:

> What makes you think that I would do something like that under all these 
> conditions and knowing your general attitude towards new data model? It 
> seems like waste of my time. I have better things to do. The #942 is a bug 
> in the code that I don't think I am responsible for. I haven't write it, 
> and I have suggested several workarounds which were all ignored. I have 
> even expressed real doubt that it can be fixed the way you would approve. 
> So, unless you or anyone else do something about that bug it will remain 
> unsolved. If other users can live with this bug, I can live too. But those 
> who are bothered with this bug should raise their voices and try to 
> convince you.
>
> 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: Three demos showing how to improve drawing speed

[john lunzer]

This sounds like the right next step. If it passes all unit tests and 
doesn't break user scripts while at the same time solving issues and making 
improvements to usability then it deserves careful consideration. Results 
will speak more loudly than any amount forum deliberation.

On Friday, July 13, 2018 at 6:30:22 AM UTC-4, Edward K. Ream wrote:
>
>
>
> But if you want to demonstrate the new data model in a separate git 
> branch, I won't reject it without study, provided it passes all unit tests.
>
> At the very least, your work would fix #942, which is something that I 
> don't particularly want to do now.
>
> For now, if I can, I would like to do something new.
>
> 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: A detailed critique of the new data model

[john lunzer]

I have been following this story with interest because it is my opinion 
that the responsivity of Leo's tree is not fast enough in enough cases to 
make it a daily annoyance. My fuzzy memory of participation in this group 
tells me that others feel similarly, though I will let them speak for 
themselves. 

I think it's important at this point that we keep separate responsivity 
concerns and the merits of this or that data model. Responsivity is the 
result of an implementation, whatever it may be. If responsivity in Leo is 
an issue, then if resources permit it should be addressed at the 
appropriate level of urgency.

This may not need to said but I will say it anyway, I believe that Vitalije 
has Leo's best interest at heart. He has met situations and concerns at 
least half way, often more. He is skilled, enthusiastic, and confident. I 
can say the exact same thing of Edward. Try to keep in mind that everyone 
here is trying to take Leo to the same place and we should support each 
others efforts where ever possible. 

On that note, every community member should be encouraged to solve Leo's 
problems and make improvements. And if they are willing to take 
responsibility for the implementation and presenting that implementation to 
the community the merit's of their solution should be carefully considered. 

There is no benefit at this point, and likely ever, to a forceful rejection 
of contributions to the community. Contributions are a rare and valuable 
resource.


On Thursday, July 12, 2018 at 11:29:27 AM UTC-4, Edward K. Ream wrote:
>
> On Thursday, July 12, 2018 at 10:04:38 AM UTC-5, vitalije wrote:
>
> Ok. I will wait until you redesign the drawing code so that it gives us 
>> possibility to make a fair comparison of speed between the new data model 
>> and present Leo data model. 
>>
>
> I have no further interest in the new data model.  It won't happen while I 
> am Leo's project leader.
>
> It will be good for Leo and it certainly will amuse me. When you finish 
>> this project, I will run again the test used in the video 
>>  and see if you can beat 
>> that last result of 1.3ms. Just for the record Leo at the moment takes 
>> 1700ms for the same job and test scripts used in video are in this 
>> repository . Let's see how 
>> much ms of these 1700 can be saved by improving draw methods.
>>
>
> I have just created #942 
> : Speed Leo's Qt 
> drawing code. It has no milestone associated with it. 
>
> Leo's tree redraw is already fast enough for most purposes.  Speeding it 
> up might be good, but drawing speed alone does not begin to justify the new 
> data model.
>
> 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: updates about new data model

[john lunzer]

Extracting and distilling Leo's node/tree model is exciting work and I 
thank you for doing it. One of my lingering annoyances when using Leo is 
the sluggishness of tree operations and it sounds like your code will be 
able to completely mitigate that, if incorporated. I appreciate you taking 
the time to map out what you think is the path of least resistance to 
incorporate the code into Leo. 

Sadly I do not use Leo that much anymore as I work primarily in a resource 
constrained environment where it is not possible for me to reliably use 
GUIs, and Leo's terminal front-end is no where near mature enough to use on 
a daily basis. As such, I echo your hopes about other editor's benefiting 
from this. 

Thank you again for your ongoing contributions to Leo and this community.

On Wednesday, July 4, 2018 at 9:19:17 AM UTC-4, vitalije wrote:
>
> On Wednesday, July 4, 2018 at 2:39:45 PM UTC+2, Kent Tenney wrote:
>>
>> Yes, I find the blog posts to be excellent documentation, very well
>> written and structured.
>>
>> Thanks for this comment and for the time you spent reading posts. It 
> gives me courage to continue writing.
>
> Your line
>
>> The difference ... is qualitative, not just quantitative. 
>>
>
> made me think about my initial goals. My initial goal was code quality and 
> not speed, but speed came as a by product and somehow it grabs focus and 
> attention to itself.
> It is hard to remain focused on the quality difference which I was hoping 
> to provide in the first place.
>
> Beauty of new data model is in its independence from Leo code. It doesn't 
> depend on anything inside Leo. If it gets included in Leo code base it 
> would be just a single python module that can be turned on and off or even 
> replaced by some improved version, very easily.
>
> This model can be included in some other editors as well and provide Leo's 
> unique features to other editors. I believe every editor would benefit from 
> these features. The users of other editors just don't know it yet, so they 
> can't appreciate them at the moment. But I am sure if they ever learn about 
> those features they will certainly love them.
>
> I don't know what will be Edward's decision about the new model. I guess 
> it won't be an easy one for him to make. Let's hope it would be the best 
> possible decision whatever it may be.  I would be glad to help anyway I can.
>
> 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: Wanted: missing features from VS code, Atom, etc

[john lunzer]

On Monday, May 21, 2018 at 2:30:25 PM UTC-4, Edward K. Ream wrote:
>
> *Other panes*
>
> Most IDE's support lots and lots of other views.  It's an open question 
> how useful these would be in Leo.
>

Rather than focus entirely on usefulness (which is always important to 
focus on) it is also important to consider what this would me 
architecturally. Supporting views requires considering how "panes" are 
represented programmatically. Acting on this might hopefully bring with it 
a simplification of the code for window configuration and would likely also 
aid *Non-outline tabs *or tabbed windowing in general. 

As a point of comparison, take a look at emacs's buffer system. In emacs a 
buffer and a pane are separate concepts, panes being views into buffers. 
You can close a pane but it will not close the buffer. Because you can 
modify/eliminate views without losing the underlying content emacs windows 
tend to be quite fluid in their layout with panes appearing when needed and 
disappearing/closed when not needed anymore, but with their respective 
buffers remaining if needed again. It allows for saving a view history and 
being able to navigate backwards and forward through the views. 

This level of modularity and separation may not be necessary. I've never 
been unhappy with Leo's window configuration options. Leo has a unique 
interaction paradigm (file nodes and the tree), such that I haven't 
particularly missed views. But that doesn't mean that the user experience 
wouldn't benefit from them.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Basic Layout of the Leo GUI

[john lunzer]

Matt's reasoning is sound and explains the design decision well. 

That said, your argument appears to be based on something, the "conventions 
and standards" of IDE GUIs, that if it exists at all is a rapidly changing 
amorphous blob at best. I say this because I spend about half my day using 
*emacs. *If you invest in emacs like you invest in Leo you discover an 
amazing amount of power and configurability (and sometimes frustration). 
emacs strays perhaps even further from convention than Leo does but it is 
been around for 42 years and publicly available for 33 years! 

emacs has seen many "conventions" and many "standards" come and go and yet 
it has remained mostly as it was since it was young. To this day it is not 
the most popular editor/IDE, not by far, but it is unarguably one of the 
most feature complete and powerful editors/IDEs in existence. In emacs you 
can get top level tabs for context switching through several plugins (or 
through tmux), it is a desirable feature by many dedicated and talented 
programmers. 

When I came to Leo I distinctly remember the top level tabs being odd, I 
didn't really make sense of it at the time but now that you point it out I 
realize it's because you are right that it isn't too common. However, not 
being common is a poor indicator of desirability. and utility. 

Based on my extensive use of Leo and emacs I would argue that the fabled 
"conventions and standards" you spoke of are yet young and naive and if 
they have settled on anything it is more by chance than based on merit. If 
anything they need to be tested, to authenticate their utility. Over a 
decade ago Microsoft decided to break convention with the switch to ribbon 
based menus and to this day they are cursed by many.

The primary measure against which any software feature should be judged is 
in it's utility. To argue that top level tabs have markedly less utility 
than other layouts, to the point of driving users away from Leo, borders on 
nonsense. If any one thing drives people away from Leo it is by not giving 
themselves enough time to come to terms with outline based editing and the 
uncomfortable cognitive dissonance caused by the paradigm shift; in other 
words, *outlining itself*. To those ends Edward has put in countless hours 
trying to help new users understand how outlining works and how outlining 
can improve their workflow.

There is no doubt that Leo could be marketed more professionally, given 
that Leo is not a commercial product it is hardly surprising. When somebody 
steps up to volunteer their time to take on that role I suspect Leo will 
attain greater use and visibility. 

Until that time I would advise all to think carefully before posting doom 
and gloom topics. Ask yourself, "will this improve the tone and efficiency 
of the community?" Likely the answer will be no. A simple feature request 
will have sufficed. As Matt said perhaps the location of the tab bar will 
one day be configurable, perhaps when there is enough public support to 
warrant it or when someone with enough desire takes it upon themselves to 
implement. 

On Tuesday, April 17, 2018 at 4:48:02 AM UTC-4, rengel wrote:
>
> Leo uses tabs to switch workspaces (contexts). Each .leo file can define 
> or redefine what menus, settings, plugins and so on are available within 
> it's context. So tabs are the highest level of containment.
>
> IMO this is only partly true. There are always menus, menu items, and 
> functions that are globally used (i.e. File, Help, View, the arrangement of 
> panes/windows) AND items that are context-specific, so it's not an 
> either-or question. Other IDEs (i.e. PyCharm) solve this dilemma by 
> providing two menus: one global menu bar and - within a tab - a 
> context-specific menu bar, sometimes even with an additional toolbar. I.e. 
> in the Web Development world this is exemplified by the CKEditor plugin for 
> web pages (https://docs.ckeditor.com/) or even the comment function of 
> this Google group.
>
>
> Reinhard
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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 crashes when using iPython plugin

[john lunzer]

I would sort of expect a crash like this. I don't believe there is anything 
built into the Leo-IPython bridge which would allow Leo to provide keyboard 
input to IPython. Somebody with more knowledge could provide additional 
detail but I might steer away from this method of trying to provide 
keyboard input.

On Sunday, October 8, 2017 at 9:31:35 PM UTC-4, Andreas Gehrmann wrote:
>
>
> Hi, I try to execute python code from Leo with the iPython plugin.
>
> I start Leo from the windows terminal with python leolauch.py --ipython 
> and as expected a Jupity QTconsol is opening.
> If I run a print("hello world") via ipython excec it shows the result s 
> expected.
>
> However, if I run an input() command, Leo crhes.
>
> Any suggestion?
>
> Thanks for your attention, Andreas
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Web help wanted: viewing Joe Orr's Leo view page locally

[john lunzer]

I want to thank you for this work Joe, this is really amazing and has the 
potential how I use Leo to share information. I was able to download all 
the files listed in index.html from the aws site and run the entire thing 
locally without having to run a web server. Just open the link up in my web 
browser and I've got an instant Leo file viewer that I can package up.

But I would like to ask you Joe: I would like to be able to to just zip up 
a directory with all the required javascript/html and a .leo file and send 
it to somebody for viewing. Outside of the files listed in the index.html 
file are there any other javascript dependencies I'm not taking into 
account?

On Saturday, September 30, 2017 at 11:42:16 AM UTC-4, Joe Orr wrote:
>
> Sorry for the slow reply, been busy with a startup and another side 
> project, but getting back to this now.
>
> About getting a leo file to load up in LeoViewer easily, see this repo:
> https://github.com/kaleguy/leo-examples
>
> All you need to do is download index.html and put it in the same folder as 
> the leo file you'd like to view, edit index.html (settings are self 
> explanatory) and then view index.html in the browser. You'll need to use 
> something like http-server if you want to do this locally.
>
> Also, the relative links in the main demo site were broken, just fixed 
> those.
>
> The example site above shows Leoviewer displaying Youtube videos. If you 
> look at the source Leo file, you'll see this a simple Vue component. Next 
> steps for LeoViewer is to make more Vue components work out of the box + 
> integrate form.io, so that you can build analytics dashboards and other 
> complicated programs using Leo to design your UI. Probably will change the 
> name to LeoVue.
>
> Joe
>
> On Tuesday, September 12, 2017 at 11:01:48 AM UTC-4, Edward K. Ream wrote:
>>
>> In another thread (don't remember where), I said that I wanted to 
>> "recreate" Joe Orr's Leo viewer page 
>> , or words 
>> to that effect.  The conversation then shifted to discussions about web 
>> frameworks, abstraction layers, etc.
>>
>> But I meant something much simpler!  I just want to be able to download 
>> the page on my local machine, and have the page work as it does via the 
>> link above.  But it doesn't.  Maybe scripts got "disconnected" somehow, or 
>> maybe the problem lies in the css. Or somewhere else.
>>
>> I've studied the code on the page in a text editor (and anyway, the page 
>> displays its own source code). I don't see why things don't "just work".
>>
>> Can anyone explain what is going on, and how to make the local page work 
>> like the original? I'm guessing that just a few tweaks would do the job.  
>> That would be a big step forward for me.
>>
>> Any volunteers?
>>
>> 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: NEW: cloud storage plugin for Leo

[john lunzer]

Just read through this properly and it sounds like a step into the future 
(or present). 

The part about cloudifying/centralizing @settings would be friggin 
fantastic. sFTP might be nice to have for people behind restrictive 
firewalls.

Great job, thank you for your contributions.

On Sunday, September 24, 2017 at 4:41:02 PM UTC-4, Terry Brown wrote:
>
> The new leo_cloud plugin allows subtrees within a .leo file to be 
> stored in the cloud.  It should be possible to support various cloud 
> platforms, currently git is supported (i.e. you can use GitLab or 
> GitHub or your own remote git server). 
>
> A leo_cloud subtree has a top node with a headline that starts with 
> '@leo_cloud'.  The rest of the headline is ignored.  The body of this 
> top node is used to describe the cloud service, e.g.: 
>
> type: Git 
> remote: g...@gitlab.com:tnbrown/leo_cloud_storage.git 
> local: ~/.leo/leo_cloud/gitlab_leo_cloud_storage 
> ID: shortcuts 
> read_on_load: ask 
> write_on_save: ask 
>
> The first three lines can be repeated with different IDs to store 
> different subtrees at the same remote cloud location. 
>
> read_on_load: / write_on_save: can be yes, no, or ask.  If it's not one 
> of those three, there's a warning dialog. 
>
> There's also a file system backend, which would look like this: 
>
> type: FileSystem 
> root: ~/DropBox/leo_cloud 
> ID: my_notes 
> read_on_load: ask 
> write_on_save: ask 
>
> The FileSystem backend was meant to be for development, but of course 
> if you map it into a folder that is sync'ed externally, as shown above, 
> it can serve as a cloud adapter too. 
>
> In addition to the Git and FileSystem cloud types it should be possible 
> to add many others - Google Drive, OneDrive, DropBox, AWS, WebDAV, 
> sFTP, whatever. 
>
> Note: https://gitlab.com/ gives you free private repos., in case you 
> didn't know. 
>
> The data stored is basically headline, body, and uA (unknown 
> attributes).  The caveat is that it must be JSON serializable, this is 
> to avoid pickle flavor issues.  I don't think this will cause problems 
> except for legacy datetime objects from the todo.py plugin and set()s 
> in the tags plugin.  I think both can be fixed easily - a custom JSON 
> writer can write datetime as iso string time and sets as lists, and the 
> tags plugin can coerce lists to sets.  I think the todo.py plugin 
> already reads iso string time values. 
>
> My intended use was a common synchronized todo list across machines, 
> which this achieves.  (note to self, make sure todo icons are refreshed 
> properly). 
>
> An unintended bonus is that you can use it to sync. your settings 
> across machines easily too.  Because Leo is brilliant ;-), this: 
>
> @settings 
>   @keys 
> @leo_cloud 
>   @shortcuts 
>
> "just works", so now your shortcuts etc. can be stored on a central 
> server. 
>
> Lightly tested, but seems to work - testing and other feedback 
> appreciated. 
>
> 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: Clone Find All / Clone Find Flat could benefit from auto highlighting of search term

[john lunzer]

I had gotten close to getting past the trickiness before I got slammed at 
work leaving no time after work for hobby dev. 

There is a lot I don't understand about the Qt/PyQt highlighter, running 
Leo in the debugger around the highlighting code was rough. Do you remember 
if there were any resources you used when initially writing the highlighter?

I'd still like to get this done if work lets up.

On Thursday, September 21, 2017 at 11:38:25 AM UTC-4, Edward K. Ream wrote:
>
> On Tue, Sep 12, 2017 at 7:22 AM, john lunzer <lun...@gmail.com 
> > wrote:
>
>> I've been pouring through the syntax highlighting code and I think I've 
>> actually come up with a pretty elegant solution: custom highlighting rules
>>
>> The QSyntaxHighlighter is likely the best option for this. Basically 
>> rather than matching a regex syntax in a headline you would use the newly 
>> proposed directive *@highlight*. So for the simplest example, as it 
>> relates to clone-find-all and clone-find-flat, given the search term 
>> ​​
>> LeoHighlighter the Found collection node would include the directive 
>> @highlight 
>> ​​LeoHighlighter. The syntax highlighter would then either highlight or 
>> underline for every instance of the string "LeoHighlighter".
>>
>
> ​Yes, I think this could work.  Implementing it could be tricky, because 
> entering any node would potentially push or pop a stack of custom rules.  
> Furthermore, these rules would themselves be non-trivial to do. For 
> example, when @language python is in effect the custom rules would affect 
> virtually all the data structures in leo\modes\python.py.
>
> 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: The biggest picture

[john lunzer]

I was always under the impression that ZeroMQ 
 was the way 
that Jupyter front-ends communicated to the kernels. I'm not entirely sure 
how the web-interface fits into that.

That said, this all sounds reasonable. There is really no way to compete 
with Jupyter, and also no reason to compete. Leveraging all the great work 
being done makes sense. 

On Thursday, September 14, 2017 at 12:23:06 PM UTC-4, Edward K. Ream wrote:
>
> On Thu, Sep 14, 2017 at 11:03 AM, Terry Brown  > wrote:
>
> Right - my thought is that we want to be able to execute any Jupyter
>> cell, be it in Python or javascript or R or Go or whatever.  And making
>> that happen, from software installation to invocation to exposing
>> variables across environments, should be Jupyter's problem, not ours.
>>
>
> ​Ok.
>
> ​Funny how my memory works.  I remembered that I have a j.bat file that 
> starts the jupyter server.  It just executes "jupyter notebook".  This 
> serves jupyter pages on http://localhost:/
>
> So a simple http client should be able to access the data as the jupyter 
> web page at http://localhost:/tree does.
>
> There may be other ways to access this data, but I would imaging that the 
> web-based approach would be most natural.
>
> What do you think?
>
> Edward
>

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

Re: langserver - this looks important

[john lunzer]

On Wednesday, September 13, 2017 at 9:40:04 AM UTC-4, Phil wrote:
>
> I just ran across this 5 minutes ago, so I can't really comment on it 
> other than that it appears relevant to Leo, so I though I'd pass along the 
> info:
>
> http://langserver.org/
>

I agree, this does *seem* important. Hard to place it, I think it's a "keep 
it on the radar" project.

On Wednesday, September 13, 2017 at 9:57:16 AM UTC-4, Terry Brown wrote:
>
> I wonder if you can run it locally for cases where you have no internet 
> connection?  Or perhaps I'm misinterpreting, perhaps it's typically 
> meant to be run locally - that would make more sense. 
>
> So perhaps the server architecture is just to avoid library binding 
> issues for each client / language client's are implemented in. 
>

I think it's a local client/server relationship.  

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Clone Find All / Clone Find Flat could benefit from auto highlighting of search term

[john lunzer]

I've been pouring through the syntax highlighting code and I think I've 
actually come up with a pretty elegant solution: custom highlighting rules

The QSyntaxHighlighter is likely the best option for this. Basically rather 
than matching a regex syntax in a headline you would use the newly proposed 
directive *@highlight*. So for the simplest example, as it relates to 
clone-find-all and clone-find-flat, given the search term LeoHighlighter 
the Found collection node would include the directive @highlight 
LeoHightligher. The syntax highlighter would then either highlight or 
underline for every instance of the string "LeoHighlighter".

It feels very Leonine (directive based) and also self-explanatory/literate 
as the verb highlight is very explicit.

I'd like to get some feedback, I would like to start to try to develop this 
idea, but sort of want to get it blessed before I really start studying the 
highlight code.

On Monday, September 11, 2017 at 10:01:59 PM UTC-4, john lunzer wrote:
>
> I was comparing the Quick-Search plugin to Clone Find All / Clone Find 
> Flat today and I realized one of the reasons I prefer Quick-Search is 
> because it highlights my search term in the body text. I find this critical 
> to quickly "flipping through" search results.
>
> It would be awesome if each "Found" collector node could keep each 
> individual search term highlighted for all their respective children. I 
> think the syntax of the found collector node's is unique enough that auto 
> highlighting could actually be done completely separately to the cfa/cff 
> functionality. It could simply be in the form of an auto-highlight plugin 
> that highlighted all the search terms given a specific regex in the node 
> headline.
>
> I'd like to get some thoughts on this, hopefully I'm not missing some 
> obvious functionality already built into Leo.
>

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

Clone Find All / Clone Find Flat could benefit from auto highlighting of search term

[john lunzer]

I was comparing the Quick-Search plugin to Clone Find All / Clone Find Flat 
today and I realized one of the reasons I prefer Quick-Search is because it 
highlights my search term in the body text. I find this critical to quickly 
"flipping through" search results.

It would be awesome if each "Found" collector node could keep each 
individual search term highlighted for all their respective children. I 
think the syntax of the found collector node's is unique enough that auto 
highlighting could actually be done completely separately to the cfa/cff 
functionality. It could simply be in the form of an auto-highlight plugin 
that highlighted all the search terms given a specific regex in the node 
headline.

I'd like to get some thoughts on this, hopefully I'm not missing some 
obvious functionality already built into Leo.

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

Following Up: About org mode.

[john lunzer]

Coming from the recent Org-mode follow up topic 
 I thought 
would I continue the Org-mode dialogue here after Israel Hands' last post 
in that thread. This thread is a follow-up to a separate Org-Mode thread 
that also took place back in Feb 
. 
There was a lot of good conversation and a strong call for many Org-mode 
features. As a disclaimer, it is not my wish/goal for Leo to be emacs. But, 
emacs is a great piece of software with some great features, and mimicking 
a few could make day-to-day life within Leo more efficient.

There is a continued desire for displaying multiple nodes at once, to get a 
better feel for the overall content of a tree. I believe that Terry's work 
will address this and that once he releases what he has been working on 
that others will be able to contribute and help refine the vision for what 
a multi-node edit pane should be.

Another strong call was for better within-pane rendering (specifically 
Latex, but I think this would extend to other rendering as well).

In addition Edward listed:

   - An agenda plugin (possibly built on the To Do plugin)
   - Node drawers for "hidden" information (basically an easy way to edit 
   node uA )
   - Better shell support
   - Better language support (make, C, C++, Java)?

Of these it seems like Agenda has public interest. 

It seems either people don't understand the need for drawers or simply 
don't see them as I high priority item over many of the other org-mode 
features.

Once there is a multi-node editor in place I plan on giving serious thought 
to better shell support (the sh library  might 
be a good stepping stone).


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Cross pollination: Hopscotch: dynamic browser-style IDE and Leisure: document-based computing environment

[john lunzer]

On Friday, September 8, 2017 at 12:34:25 PM UTC-4, Offray Vladimir Luna 
Cárdenas wrote:
>
>
> I think that also. Gilad Bracha says something about how hypertext could 
> look like if you're freed from the web and its standards bodies.
>

I've been giving some thought lately about adding directive-based hypertext 
capabilities to Leo. Basically anywhere in any outline you could add @tag 
TagName. If you wanted to add this to code in any language you would have 
to put it in a comment.

Then anywhere else in the code (or even a headline) you could add 
@link:TagName:"But display this text instead of the TagName" and Leo would 
automatically replace with a hyperlink. 

The biggest challenge I have come with when thinking about the design is 
coming up with a system to keep track of the location of @tags. I imagine 
it would require some heavy lifting to autodetect @tags and to keep a valid 
live database of @tag locations. 

I'm still thinking about it but if anybody has any ideas I'd be happy to 
hear about them.

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

Re: Trying to find a thread re. quick access to 'inbox' node

[john lunzer]

Not sure what specific functionality you're referring to but I think 
@chapter nodes would be a good option.

I have this shortcut defined:

chapter-select ! tree= z


The nice thing about chapters is that they save your view state within the 
chapter. 

So you could have a minimum of two toplevel @chapter nodes maybe:

   - @chapter Inbox
  - My Note 1
  - My Note 2
   - @chapter Work
  - My fancy work
 - Part 1 of fancy work
 - Part 2 of fancy work
  
And when you flip back and forth between chapters you will be transported 
back to where you previously left off when you left the chapter. 
Unfortunately I don't think your position is saved when you close an 
outline. And actually you don't even need @chapter work if you don't want, 
since there is an inherent main chapter which is non-chapter view of the 
tree. In both cases you could use the chapter-next to quickly flip between 
your chapters.

I'm sure there are 10 other ways to do it, but that is how I would do it. 

On Thursday, September 7, 2017 at 1:09:18 PM UTC-4, jkn wrote:
>
> Hi all
> I remember reading a conversation, I presume on this list, where 
> someone described a Leo workflow with a special node at the top of their 
> outline (named specially IIRC) and some scripts/key-bindings to make 
> navigating to that node, entering some text, and then presumably returning 
> to their previous position, very quick and easy.
>
> I am looking for this but can't find the thread. Does it ring bells with 
> anyone?
>
> search-challenged-ly yours
> Jon N
>
>

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

Re: Following up: Leo 5.5 will challenge org mode

[john lunzer]

I always expected the focused pane would be c.p, all other panes would have 
no explicit reference other than being +/- N positions from c.p. I'm not 
sure I see the benefit of giving them a programmatic reference. The 
potential downside is serious, needing to wrap a more complicated model 
around Leo's existing model.

Your get-it-out-the-door solution is the simplest solution and therefor 
probably the best option.

I can't wait to see what you're able to come up with. As discussed in Feb, 
it could be a game changer for many applications. I'm really excited about 
cell based (or node based in Leo's case) jupyter-notebook and org-mode 
style interactions within Leo. 

On Thursday, September 7, 2017 at 11:48:37 AM UTC-4, Terry Brown wrote:
>
> On Thu, 7 Sep 2017 05:34:28 -0700 (PDT) 
> john lunzer <lun...@gmail.com > wrote: 
>
> > Anyway, just checking in. Multi-pane editing is definitely at the top 
> > of my list and it seems like Terry had put a bunch of work in, would 
> > be a shame if it never saw the light of day. 
>
> Thanks for the nudge :-)  I really should have another look at it.  It 
> basically works, but needs Leo syntax highlighting (probably not a big 
> deal) and Leo key handling (much bigger deal). 
>
> The challenge is that c.p isn't a clearly defined concept in the new 
> model.  Maybe the best approach would be to make c.p follow the focused 
> pane as an initial 'get it out the door' kind of solution, then look at 
> possible decoupling further down the track. 
>
> 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.

Following up: Leo 5.5 will challenge org mode

[john lunzer]

Back in February there was a pretty awesome thread about some pretty 
awesome features 
 that were 
planned for Leo 5.5. 

One of the big ones there was a new multi-pane editing mode. Just wanted to 
check with Terry and Edward on where this left off. I still think this 
could be a killer feature. 

Another was a execute-script-in-common-namespace command.

Lastly there was a proposed show-drawer command, looks like Edward tested 
the waters on this back in May but didn't get much back.

Anyway, just checking in. Multi-pane editing is definitely at the top of my 
list and it seems like Terry had put a bunch of work in, would be a shame 
if it never saw the light of day.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: (Kinda) "Learning How to Learn" from Coursera

[john lunzer]

On Friday, August 25, 2017 at 10:19:53 AM UTC-4, Edward K. Ream wrote:

> I would like to learn more about web technologies.  I'll start by 
> replicating the appearance of Joe Orr's Leo Viewer page 
> .
>

Been thinking about this and a future web UI for Leo. With the dynamic and 
constantly changing nature of the web and web technologies it seems like 
the best investment would be to implement a web GUI front-end which is 
actually an abstraction layer to a messaging protocol which defines a 
generic (but based on Leo's needs) GUI API. It would then be the 
responsibility of the "Leo Web Client" to implement the display logic and 
UI event logic and communicate to Leo using the defined API. Leo would 
require no knowledge of the client implementation.

I sort of got the idea from this article about the cost of X-to-Javascript 
transpilers . The long term view 
is that if your goal is putting your application into a browser you're 
better off learning and working in Javascript on the client/browser side. 
There is a good analogy about learning German if you live and work in 
Germany and about how much it would cost to hire a translator full time for 
an extend period. 

But that doesn't mean we all need to switch to Javascript, just that the 
best tool for the job if you're interacting with an application inside a 
browser is Javascript. I think you can (and should) write your application 
logic on whatever platform you see fit and implement server/client 
communication. 

I will make sure to say I have very little experience with web technologies 
or implement a system as described and I know almost no Javascript. Maybe 
it's a naive notion or maybe I'm making it overly complicated. I think 
these thoughts put into perspective what a huge undertaking it would be to 
write a web front-end. I would be interested to get some feedback. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: cross-platform file references - how to deal with?

[john lunzer]

I totally agree with that logic. If you *were* going to add it to the c 
namespace I would name it c.getConfig (which is more descriptive as to what 
it is doing) rather than c.getString. 

On Wednesday, September 6, 2017 at 12:01:58 PM UTC-4, Edward K. Ream wrote:
>
> On Wed, Sep 6, 2017 at 10:27 AM, john lunzer <lun...@gmail.com 
> > wrote:
>
>> Would it be possible to to add {{sep}} as a shorthand for {{os.sep}} and 
>> {{getConfig()}} as a shorthand for {{c.config.getString()}}? 
>>
>
> ​Rev ceca81e defines {{sep}} as {{os.sep}}, but I see no way to pass 
> arguments to getConfig as you want.  So the best that can be done is:​
>
> @file {{c.config.getString('my-dir')}}{{sep}}myFile.py
>
> In other words, g.os_path_expandExpression doesn't support macros, and 
> likely never will.
>
> I've also updated the docs for path expressions 
> <http://leoeditor.com/directives.html#path-expressions>.
>
> Hmm, I suppose as a "special dispensation" Leo could define  c.getString 
> as c.config.getString, but I'm not sure that it's a good idea, and I'd 
> rather not do this just before a new release. It's a global addition to the 
> namespace, and not entirely trivial to do.
>
> 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: Cross pollination: Hopscotch: dynamic browser-style IDE and Leisure: document-based computing environment

[john lunzer]

On Tuesday, September 5, 2017 at 3:52:55 PM UTC-4, Edward K. Ream wrote:
>
>
> When I was first learning to program, I often wanted to find some "magic" 
> that would make tasks easier.  Now, I have enough experience to know about 
> how much work a task will take.  However, this might blind me to other 
> approaches that would, in fact, be much better/elegant.  Vitalije's new 
> read code could be called an example.
>

It's nice to know my search for programming "magic" is an *ailment* that 
others have experienced.

Part of Leo's "magic" that has attracted me more than other outline based 
programming tools is that it aspires to be (in the outlining editor sense) 
language agnostic. As an engineer this is a huge consideration for me. I 
should clarify that I'm not looking for the "next big thing". The farther 
civilization expands digitally the more "legacy" code we will have. Despite 
being "legacy" that code is likely going to be still be responsible for 
people's lives and because the effort of updating or porting the code would 
be prohibitive. 

To survive in the future every engineer/programmer is going to need a tool 
that will break down any program in any language into structured code. What 
is structured code? When I develop a larger program in Leo my outline tree 
naturally take on an organized structure that is beyond the limits of what 
the structuring elements of the language provides. I will also do the same 
thing when integrating external code, after Leo does its standard parsing 
and tree construction I go in and move things around so that code/nodes are 
grouped using some classification/categorization logic that is project/code 
dependent.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: cross-platform file references - how to deal with?

[john lunzer]

Would it be possible to to add {{sep}} as a shorthand for {{os.sep}} and 
{{getConfig()}} as a shorthand for {{c.config.getString()}}? 

I think these would be perhaps the two most common use of of path 
expression evaluations. Would be nice to have them be a little shorter.

On Tuesday, September 5, 2017 at 4:02:55 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, Sep 5, 2017 at 11:05 AM, jkn  > wrote:
>  
>
>> I was looking at the 'Directives Reference' page myself last night, but 
>> missed the (rather short) 'Path Expressions' section. Perhasp if it were to 
>> be a bit bigger, say by incorporating your example above, that might help?
>>
>
> ​Done.  See this section 
> . The example uses 
> {{os.sep}}.
>
> 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: Cross pollination: Hopscotch: dynamic browser-style IDE and Leisure: document-based computing environment

[john lunzer]

The "web" (as in always connected to the net and files saved on the cloud) 
as a development platform is dubious. However, the "browser" being the 
driver is another matter. Given what browsers are designed to display this 
might be the most natural environment for mixing 
code/data/docs/visualization. You can kind of see this happening too. 
Leisure is just one example. 

ipywidgets is an exciting library. I will say it's not something new in 
general. Mathematica has had the kind of interactive functionality that 
ipywidgets offers for a long time. But it is a good example of mixing code 
directly with UI elements. 

In the presentation on Hopscotch the presenter said something along the 
lines of, "Why are our development UIs and environments still primarily for 
text only manipulation". The more I think about coding in general the more 
I think about how valid this question is. And combine with the Leisure 
example I want to know the same thing. 

Why can't my coding environment be filled with whatever I want? Why can't I 
have an interactive graph as a comment? Offray you shared the literate 
devops example and that example was a great example of how stream of 
consciousness can be captured with executable scripts and commentary.

On Sunday, September 3, 2017 at 1:02:17 PM UTC-4, Offray Vladimir Luna 
Cárdenas wrote:
>
> Hi John,
>
> Thanks for these links. I just finished to see the Hopsotch video, 
> including questions, that are interesting to me as a Smalltalker, and is 
> curious to see the misreadings once and again, about "but we're giving too 
> much power to the 'end user' kind of questions". Also the live Leisure demo 
> and the idea of Illuminated Programming, which seems pretty much like 
> Literate Computing [1].
>
> [1] 
> http://blog.fperez.org/2013/04/literate-computing-and-computational.html
> I'm exploring similar ideas, inspirations and traditions with Grafoscopio 
> [2], and I like to think that I'm getting a more balanced approach between 
> a research tool/medium and practical one. For example, you can see the idea 
> of mixing code, data, docs and publishing in a single environment in my 
> Panama Papers demo [2a] (see picture below). As you can see, web for me is 
> mostly a publishing platform (instead of a development one), because I 
> think that web as a development environment is over complicated and over 
> hyped. Yes, no installation is fine when connectivity is a given and/or you 
> don't go under the wiring to modify something.
>
> [2] http://mutabit.com/grafoscopio/index.en.html
> [2a] http://mutabit.com/offray/blog/en/entry/panama-papers-1
>
>  
>
> There is still a lot of work to do on user experience, particularly when 
> writing markup, and recently developments in GT Documenter (in the 
> tradition of moldable tools) will change that soon [3][4].
>
> [3] https://twitter.com/feenkcom/status/901373363985240064
> [4] https://twitter.com/feenkcom/status/901219343115177986
>
> I'm, like you, constantly questioning my tools. On that front, what I have 
> found with Pharo Smalltalk in terms of moldability, simplicity, 
> practicality and dynamism (live coding constant evolution) is unbeaten by 
> any other computer environment/language I have found until now. In the 
> spirit of crosspollination and sharing link, you may be interested in the 
> tools showed here:
>
> http://feenk.com/#rd
>
> Cheers,
>
> Offray
>
> On 02/09/17 14:33, john lunzer wrote:
>
> I came off a big project recently which fortunately (or maybe 
> unfortunately) allowed me some time to do my semi-annual search for the 
> holy grail of programming. I don't know why but I am never fully content 
> with my tools and am always looking for a better way to interact with my 
> system. 
>
> Anyway, I ended up getting lost on the internet and came across two really 
> interesting projects.
>
> The first is Hopscotch, which is a dynamic browser-style IDE for the 
> Newspeak programming language/environment. Newspeak is heavily inspired by 
> Smalltalk. The Hopscotch IDE is an interesting evolution of the programming 
> environment presented by modern Smalltalks. It seems a bit cleaner and bit 
> more intuitive to navigate thanks to the browser-style controls. I will 
> link to a video demonstration 
> <https://www.youtube.com/watch?v=4cMCYx4Gbkc> here. I recommend watching 
> at 1.5x speed (to maximize your time) and dropping out before the questions 
> portion as most of the questions are not relevant to the IDE itself.
>
> The second is Leisure, and rather than explaining it you should probably 
> just jump into the live demo 
> <http://zot.github.io/Leisure/?load=elisp/README.org> or visit the repo 
> <https://github.com/zot/Leisure

Cross pollination: Hopscotch: dynamic browser-style IDE and Leisure: document-based computing environment

[john lunzer]

I came off a big project recently which fortunately (or maybe 
unfortunately) allowed me some time to do my semi-annual search for the 
holy grail of programming. I don't know why but I am never fully content 
with my tools and am always looking for a better way to interact with my 
system.

Anyway, I ended up getting lost on the internet and came across two really 
interesting projects.

The first is Hopscotch, which is a dynamic browser-style IDE for the 
Newspeak programming language/environment. Newspeak is heavily inspired by 
Smalltalk. The Hopscotch IDE is an interesting evolution of the programming 
environment presented by modern Smalltalks. It seems a bit cleaner and bit 
more intuitive to navigate thanks to the browser-style controls. I will 
link to a video demonstration  
here. I recommend watching at 1.5x speed (to maximize your time) and 
dropping out before the questions portion as most of the questions are not 
relevant to the IDE itself.

The second is Leisure, and rather than explaining it you should probably 
just jump into the live demo 
 or visit the repo 
 (which links to the demo), which explains 
the project in detail.

Anyway, I don't have anything invested in either of these technologies, 
just sharing some interesting projects to help stir people's imaginations. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Curses gui progress report

[john lunzer]

Just tested this in the wild on Windows for the first time. While minimally 
functional it's exciting to see this running. The command "print-bindings" 
works, but doesn't wrap properly in the log window (which is fine). I just 
wanted to check that anything other that "exit-leo" would work, and it does!

It may go without saying but Python on Windows does not by default come 
with curses. Anyone wanting to demo the curses GUI on Windows can go 
to http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses to get a curses wheel 
for your version of Python.

Fantastic work Edward. 

On Wednesday, May 10, 2017 at 12:21:11 PM UTC-4, Edward K. Ream wrote:
>
> On Wednesday, May 3, 2017 at 2:30:44 PM UTC-5, Edward K. Ream wrote:
>
> Almost nothing is functional.
>>
>
> The minibuffer now works. For example, typing exit-leo  exits Leo.
>
> Most other commands will likely fail. Nevertheless, this is an important 
> milestone. Considerable work was required to get key bindings working.
>
> The next step will be to implement the high-level interface between 
> wrapper and the underlying npyscreen widgets. This should be relatively 
> straightforward. This will allow many more unit tests to pass.
>
> 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: Unexected difficulties "remembering" toggle-split-direction

[john lunzer]

As an extension to "arrange the panes how you want and save the layout", 
there could be multiple saved (and custom named) layouts and Leo could ship 
with "vertical" and "horizontal" default layouts and the binding to 
"toggle-split-direction" could be replaced with a binding to 
"cycle-layouts". Then the user could either modify/overwrite the stock 
layouts or scrap those and just create their own layouts. I think this 
would maintain simplicity and also offer a powerful system for quickly 
changing layouts.

Just a thought for creating a simple/unified layout interface.

On Tuesday, May 9, 2017 at 3:37:22 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, May 9, 2017 at 2:30 PM, Terry Brown  > wrote:
>
> ​...​
>> I wonder if we should
>> ​ ​
>> be thinking about obsoleting these settings (and the split ratio one,
>> ​ ​
>> too).  As long as it works, and it already exists in free_layout, it
>> ​ ​
>> seems the "arrange the panes how you want and save the layout" approach
>> ​ ​
>> ​is simpler for all concerned.
>>
>
> ​I agree.  This seems like the best idea.​
>  
>
> Toggle split direction should (if it doesn't already) just call
>> free_layouts rotate all function.
>>
>
> ​That's exactly what it does:
>
> @cmd('toggle-split-direction')
> def toggleSplitDirection(self, event=None):
> '''Toggle the split direction in the present Leo window.'''
> if hasattr(self.c, 'free_layout'):
> self.c.free_layout.get_top_splitter().rotate()
> ​
>  
>
>> Which, appropriately, has been relabeled "toggle split direction" in
>> the pane layout menu.
>>
>
> ​So it looks like we have a plan.  When docks work we can get rid of 
> several settings.  Until then, we can do nothing.
>
> 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: Curses gui progress report

[john lunzer]

Exciting progress. This is going to be valuable work not just for using Leo 
in a console but also for any future work on integrating a new UI 
framework. 

On Monday, May 8, 2017 at 6:18:51 AM UTC-4, Edward K. Ream wrote:
>
> On Sun, May 7, 2017 at 10:07 PM, Terry Brown  > wrote:
>
> > Today's work added several new helper classes. The work is relatively
>> > straightforward, if a bit slow. I remain confident that all panes can
>> > be made fully functional.
>>
>> Very nice.
>>
>
> ​Glad you like it.  But don't hold your breath ;-)
>
> 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: Linux Leo on windows

[john lunzer]

Vocola's syntax is very straight forward and reminds me a bit of 
AutoHotKey, it looks like your'e already using the right tool for the job. 
I think what I would say is that if you ever felt like Vocola didn't have 
enough granularity you could probably combine AutoHotKey with Vocola to do 
something a little more advanced. 

I know Leo can do Pyflakes now but I haven't used it myself (I should be), 
if you can't find anything about it in the documentation or by searching 
the forums. Maybe wait for Edward to chime in or start a new thread if you 
can't get his attention here.

On Friday, April 21, 2017 at 1:03:42 PM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Friday, April 21, 2017 at 12:04:32 PM UTC-4, john lunzer wrote:
>>
>> Sorry there is such a gap in understanding. You're absolutely right, I 
>> have no clue what the day to day of a disabled person using a computer 
>> looks like. I think you've helped me understand a little bit, but this 
>> "speech recognition interface" is still a nebulous concept, what software 
>> do you use?
>>
>
> I use a combination of NaturallySpeaking and a community maintained 
> toolkit called vocola. Vocola takes a grammar and assigns an action to that 
> grammar. For example I have a grammar which allows me to create a variety 
> of timestamps.
>
> ( date | time | log | job | 24 ) stamp = stamp.string($1);
>
> Called an extension to take the variable part of the grammar and create 
> the appropriate time date stamp. Examples, in order of the grammar are
>
> Apr 21, 2017
> 12:52
> 21-Apr-2017 esj: 
> time 21-Apr-2017 12:52 
> 12:52
>  
>
>> What you say about "building your own accessibility UI". It would be a 
>> huge personal project and I'm not entirely sure it's up to the task but I 
>> will reiterate, AutoHotKey is the most powerful scripting language 
>> available with direct access to lower and higher levels of the HID (human 
>> interface device, such as keyboard and mouse). It is well before the GUI. 
>> It also has the facilities to tailor commands and configurations on a per 
>> application level. If you look on their forums people use AutoHotKey for 
>> all types of automation. My opinion is that if you're using Windows but not 
>> using AutoHotKey for anything then there is at least one thing you're doing 
>> that could be made a lot easier.
>>
>> You might not get the ability to build a full accessibility layer but it 
>> might offer you the ability smooth out a few bumps. I'm sort of shooting 
>> from the hip, I haven't tried this. So again, if my ignorance is showing, I 
>> apologize. 
>>
>
> No problem. If you don't mind, I may contact you directly with a "this is 
> what I'm trying to do" query if I think auto key might work. Right now I'm 
> going back to figuring out how to turn on pyflakes in leo
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Linux Leo on windows

[john lunzer]

Sorry there is such a gap in understanding. You're absolutely right, I have 
no clue what the day to day of a disabled person using a computer looks 
like. I think you've helped me understand a little bit, but this "speech 
recognition interface" is still a nebulous concept, what software do you 
use?

What you say about "building your own accessibility UI". It would be a huge 
personal project and I'm not entirely sure it's up to the task but I will 
reiterate, AutoHotKey is the most powerful scripting language available 
with direct access to lower and higher levels of the HID (human interface 
device, such as keyboard and mouse). It is well before the GUI. It also has 
the facilities to tailor commands and configurations on a per application 
level. If you look on their forums people use AutoHotKey for all types of 
automation. My opinion is that if you're using Windows but not using 
AutoHotKey for anything then there is at least one thing you're doing that 
could be made a lot easier.

You might not get the ability to build a full accessibility layer but it 
might offer you the ability smooth out a few bumps. I'm sort of shooting 
from the hip, I haven't tried this. So again, if my ignorance is showing, I 
apologize. 

On Friday, April 21, 2017 at 11:36:20 AM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Friday, April 21, 2017 at 11:04:30 AM UTC-4, john lunzer wrote:
>>
>> Out of curiosity, and you can tell me to buzz off (I won't be offended, 
>> because I know I will have offended you), what is your disability and to 
>> what extent are you able to individually use your hands, feet, and eyes?
>>
>
> It really takes a lot to offend me and I have no problems telling people 
> (politely) when they have offended me. You have nothing to worry about.
>  
>
>>
>> I ask because I don't have any physical disabilities but I still think 
>> the human/computer interface can always be improved. Personally I bind 
>> myself to windows for one reason only, Autohotkey. It is without doubt the 
>> best tools available for keyboard customization. 
>>
>
>> Some thoughts. I had never heard of these but roller mice 
>> <https://www.amazon.com/Contour-RollerMouse-Red-Ergonomic-mouse-central-device-wired-USB/dp/B00DE83RSC/ref=pd_sim_147_3?_encoding=UTF8_rd_i=B00DE83RSC_rd_r=SXYSCBD2N5DJG4GN7KBA_rd_w=UALtz_rd_wg=C7yDa=1=SXYSCBD2N5DJG4GN7KBA>
>>  look 
>> like an amazing option for people with hand troubles. I haven't bought this 
>> but the reviews are amazing.
>>
>
> Yes the roller mice are amazing but only if you use a traditional 
> keyboard/desktop environment. I'm always on a laptop and it's probably just 
> my clumsiness but really count on wireless mice and headsets. Back when I 
> was using a wired headset, a replace it about every 3 to 6 months because I 
> was always rolling over the cord with my chair. At 150 bucks a pop, that 
> gets expensive really fast. A $200 wireless headset is so much more 
> convenient especially when you take a bio break and are reminded to take 
> your headset off about 6 feet from the computer.
>  
>
>>
>> Foot pedals 
>> <http://www.gamingmouse.com/ergonomics/usb-foot-pedals/omnipedal-quad/> can 
>> be used to replace some keyboard functionality, taking the load of of hands 
>> and arms. I haven't bought this but it looked the most promising in my 
>> research (also has the max pedals I've seen which is 4).
>>
>
> I'm never try foot pedals. Among the other Crips, some people love them, 
> other people hate them.
>
>
>> There is also some promising looking (but still young) eye tracking 
>> mouse technology 
>> <http://www.pcworld.com/article/3014523/peripherals/tobii-eyex-review-the-eye-mouse-is-magical-but-just-not-for-everyone.html>.
>>  
>> I think there are more recent models than in that article, but that article 
>> has a video which demonstrates.
>>
>
> I think the eye tracking mouse technology is very impressive. I'm looking 
> forward to when it becomes a work tool, and not a science project. 
>
>>
>> Between eye tracking and foot pedals you could replace the mouse 
>> completely (instead of using the roller mouse option). After that you'd 
>> still be at the mercy of the speech recognition for the rest of the 
>> keyboard. 
>>
>
> And right there, you just express the classic misunderstanding about 
> speech recognition. It is not a replacement for the keyboard. It's a 
> totally different interface. You don't spell out the letters. You don't try 
> to smooth the shift key by voice. You want to say short phrases that mean 
> something in the context of the application. For example, you should be 
> able

Re: OT: Time for a Linux laptop

[john lunzer]

>
>  I'm not convinced they actually fixed anything.
>

Funny, I say the same thing every time I get my car back from the shop.
 
On Wednesday, April 19, 2017 at 11:20:11 AM UTC-4, Edward K. Ream wrote:
>
> On Friday, April 14, 2017 at 11:22:23 AM UTC-5, Edward K. Ream wrote:
>
> > Alas, I won't have it with me at the sprint.
>
> Wow. I just got it back, two days after sending it to Atlanta.  I'll test 
> it for a few days before changing anything.  I'm not convinced they 
> actually fixed anything.  We shall see what the battery indicator says 
> tomorrow.
>
> 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: Linux Leo on windows

[john lunzer]

Out of curiosity, and you can tell me to buzz off (I won't be offended, 
because I know I will have offended you), what is your disability and to 
what extent are you able to individually use your hands, feet, and eyes?

I ask because I don't have any physical disabilities but I still think the 
human/computer interface can always be improved. Personally I bind myself 
to windows for one reason only, Autohotkey. It is without doubt the best 
tools available for keyboard customization.

Some thoughts. I had never heard of these but roller mice 

 look 
like an amazing option for people with hand troubles. I haven't bought this 
but the reviews are amazing.

Foot pedals 
 can 
be used to replace some keyboard functionality, taking the load of of hands 
and arms. I haven't bought this but it looked the most promising in my 
research (also has the max pedals I've seen which is 4).

There is also some promising looking (but still young) eye tracking mouse 
technology 
.
 
I think there are more recent models than in that article, but that article 
has a video which demonstrates.

Between eye tracking and foot pedals you could replace the mouse completely 
(instead of using the roller mouse option). After that you'd still be at 
the mercy of the speech recognition for the rest of the keyboard. 

Anyway, just curious and hopefully technology keeps improving to mitigate 
your disability.

On Friday, April 21, 2017 at 9:49:00 AM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Thursday, April 20, 2017 at 6:20:15 PM UTC-4, Edward K. Ream wrote:
>>
>> I don't understand what benefit there could be to running it non-natively.
>>>
>>
>> ​Neither do I.  Leo runs extremely well on Windows.
>>
>
>  This experiment was motivated by a couple things. First, I have broken 
> remnants of Leo all over my Windows environment. For some reason, I just 
> can't get the complete environment to work and stay working. I was trying 
> to see if this hybrid environment would be more stable. I've discovered 
> that it's not so I'm going to try again this morning with Windows but, it's 
> not fun. Second, I use Windows to run speech recognition, a browser and 
> now, Leo. All of my "real work" takes place on Linux. My workflow is edit 
> in Leo, rsync to one of a few linux boxes, install my changes, and test. 
>
> In order to implement my workflow, three quarters of the time, I need to 
> run something like cygwin or bash on Windows so I have an environment where 
> I can easily automate much of my workflow and take a load off of my hands. 
> I tried using Windows native equivalent tools but they don't automate well 
> or there is such a huge mismatch between the Windows environment and the 
> tool's UNIX roots that my working environment becomes even more fragile and 
> easily broken. The remaining fraction of the time I'm running X11 
> applications displaying on my Windows box because my work is taking place 
> on a linux machine somewhere
>
> This is not a leo issue. It comes from my frustration with being disabled 
> and having to count on accessibility tool made by a company that gives a 
> big middle finger to disabled users.  I'm not happy with how things work 
> with speech recognition I'm not accepting the limitations the accessibility 
> environment places on me because I know it can be much better.  I don't 
> want my tools to further damage my hands and increase my pain level. Part 
> of the way I'm trying to accomplish this is through Leo plug-ins. I'm 
> picking away at understanding how to write Leo plug-ins so I can try and 
> automate some of my workflow within Leo as well as add some accessibility 
> specific features.
>
> Rough analogy, if the task was building a road, you guys can just use 
> existing tools and start construction. Me, I have to go harvest the iron 
> ore to make the metal parts to assemble into machines before I can start 
> building the road. And lately, to continue the analogy, it seems like every 
> time I harvest ore, the mine keeps collapsing.
>
> So now I'm going to go to turn my attention to cleaning up the Leo 
> fragments in my Windows environment and try again with Anaconda.
>
>
>
>
On Friday, April 21, 2017 at 9:49:00 AM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Thursday, April 20, 2017 at 6:20:15 PM UTC-4, Edward K. Ream wrote:
>>
>> I don't understand what benefit there could be to running it non-natively.
>>>
>>
>> ​Neither do I.  Leo runs extremely well on Windows.
>>
>
>  This experiment was motivated by a couple things. First, I have broken 
> remnants of Leo all over my 

Re: Linux Leo on windows

[john lunzer]

don't forget you simply need to do run the command: "conda install pyqt"

On Friday, April 21, 2017 at 10:51:54 AM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Friday, April 21, 2017 at 10:45:26 AM UTC-4, john lunzer wrote:
>>
>> Unless your download was compromised or not downloaded from the official 
>> miniconda site I'm highly doubtful that the Continuum folks would have let 
>> any exploits into their software. Make sure you're hitting the official 
>> site <https://conda.io/miniconda.html> and if you must, do a checksum/MD5 
>> <https://repo.continuum.io/miniconda/> on the file you downloaded. 
>>
>> There is certainly always the possibility that something malicious 
>> slipped through or both continuum sites were hacked but I think the odds of 
>> that are small.
>>
>> Beyond that I'd do a search for Anaconda/Miniconda and malwarebytes or 
>> just whitelist Miniconda/python. 
>>
>
> Oh yes, I've done all that (official site, checksum etc.) additionally, I 
> have scanned for potential viruses etc. if I run conda from the command 
> prompt, it's fine but I can't run it from the Windows start menu. I mostly 
> chronicling the hurdles I have to jump through to get anything to work.
>
> Now installing PY QT and will see if I can get basic Leo and then the 
> various linting tools to work.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Curses prototype: phase 2 design and process

[john lunzer]

Blasphemy! Haha, jk. I too probably would have recommended pycharm if I 
were going to go with anything "pro". As much as I try not to give 
commercial software kudos they've got a good piece of software.

It's a shame the debugging experience on Windows isn't more fluid. I'm not 
sure how long I'd survive with Python on Linux without pudb. At least it 
wouldn't be nearly as fun. Another reason to lament urwid not working on 
Windows.

On Friday, April 21, 2017 at 8:14:26 AM UTC-4, Kent Tenney wrote:
>
> or https://www.jetbrains.com/pycharm/
>
>
> On Fri, Apr 21, 2017 at 7:11 AM, Kent Tenney <kte...@gmail.com 
> > wrote:
>
>> It might be worth biting the bullet, buying a commercial IDE like
>> https://wingware.com/
>>
>>
>> On Fri, Apr 21, 2017 at 6:51 AM, john lunzer <lun...@gmail.com 
>> > wrote:
>>
>>> Ahh, I'm sorry to have suggested urwid. I totally forgot about the Linux 
>>> only limitation. 
>>>
>>>
>>> On Friday, April 21, 2017 at 7:24:11 AM UTC-4, Edward K. Ream wrote:
>>>>
>>>> On Friday, April 21, 2017 at 5:56:29 AM UTC-5, Edward K. Ream wrote:
>>>>>
>>>>>
>>>>> Ok.  Misleading 'help attach' and error message confused me for awhile.
>>>>>
>>>>
>>>> Sorry, I mis-remembered what I had just done!
>>>>
>>>> In the second console, first do:
>>>>
>>>> password 
>>>>
>>>> Then do:
>>>>
>>>> attach
>>>>
>>>> to get a list of pid's. Then do:
>>>>
>>>> attach 
>>>>
>>>> to actually attach to the first console.
>>>>
>>>> This *does* work, but alas rpdb2 doesn't print *anything* useful after 
>>>> single-stepping, so I'm always having to type l (list).  So using the 
>>>> winpdb gui version is probably best after all.
>>>>
>>>> I've just tried to use rpdb2 in both consoles on Windows.  There is a 
>>>> problem connecting to the newly-created server on localhost.  Something 
>>>> about a timeout.  Not sure if this is a programming problem (fctrl?) or a 
>>>> firewall problem.  However, there is no great need to do debugging on 
>>>> Windows.
>>>>
>>>> In short, urwid doesn't seem to work on Windows, but npyscreen runs 
>>>> anywhere and can be debugged on Linux with rpdb2 and winpdb.  I'd say this 
>>>> is a good enough resolution to the problem of what curses widgets to use.
>>>>
>>>> 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+...@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: ENB: Curses prototype: phase 2 design and process

[john lunzer]

Ahh, I'm sorry to have suggested urwid. I totally forgot about the Linux 
only limitation. 

On Friday, April 21, 2017 at 7:24:11 AM UTC-4, Edward K. Ream wrote:
>
> On Friday, April 21, 2017 at 5:56:29 AM UTC-5, Edward K. Ream wrote:
>>
>>
>> Ok.  Misleading 'help attach' and error message confused me for awhile.
>>
>
> Sorry, I mis-remembered what I had just done!
>
> In the second console, first do:
>
> password 
>
> Then do:
>
> attach
>
> to get a list of pid's. Then do:
>
> attach 
>
> to actually attach to the first console.
>
> This *does* work, but alas rpdb2 doesn't print *anything* useful after 
> single-stepping, so I'm always having to type l (list).  So using the 
> winpdb gui version is probably best after all.
>
> I've just tried to use rpdb2 in both consoles on Windows.  There is a 
> problem connecting to the newly-created server on localhost.  Something 
> about a timeout.  Not sure if this is a programming problem (fctrl?) or a 
> firewall problem.  However, there is no great need to do debugging on 
> Windows.
>
> In short, urwid doesn't seem to work on Windows, but npyscreen runs 
> anywhere and can be debugged on Linux with rpdb2 and winpdb.  I'd say this 
> is a good enough resolution to the problem of what curses widgets to use.
>
> 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: Linux Leo on windows

[john lunzer]

What is the value in running the "linux version" of Leo in windows with 
emulated X11 server?

An easy way to get going on Windows is by installing anaconda. It will 
install everything you need to run Leo from the anaconda command prompt. If 
you're worried about how bloaty anaconda is you can install miniconda and 
then install PyQt manually from the conda package manager. 

I don't understand what benefit there could be to running it non-natively.

On Thursday, April 20, 2017 at 2:39:36 PM UTC-4, Eric S. Johansson wrote:
>
> Okay, the title was click bait. :-)
>
> Running Leo on Windows has been frustratingly inefficient. For some 
> reason, I keep breaking things, fixing things, and then breaking them 
> again. I just got fed up. So this is what I am currently trying:
>
> Installed bash on Windows 10 Creators update[1]. --> Instructions 
> 
> Buy Xming[2] ---> Xming 
> add "export DISPLAY="localhost:0.0" to the end of .bashrc
> test the X11 in connection by running some kind of X11 app like a terminal 
> emulator or Emacs
> update 
> install python-qt4/5 and any other packages you may need[3]
> Copy Leo from git repository
> update path to include the leo git repository path
> test Leo "python launchLeo.py"[4]
>
> The only thing I would suggest is putting in a soft link to where ever in 
> the Windows file system you want to store your code. The reason I do this 
> is because when I backup, I backup from the window side. However, having 
> said, depending on how well bash in windows works, I may backup my Windows 
> file system from the bash environment.
>
> For me, a big problem is finding stuff that works well with speech 
> recognition. In this case, it's kind of - sort of ok. I'm having problems 
> with Xming but it probably won't interfere with the rest of you.
>
> [1] I highly recommend installing the creators update because then the 
> bash on Windows environment is based on 16.04.
> [2] the free version may work. I went for the paid version because I felt 
> it was important to support the project.
> [3] for example, I installed the gnome-terminal just because I like it 
> better
> [4] yes I'm still using Python 2.7 because I was getting a plug in error 
> with Python 3. Didn't bother to chase down, I just wanted something that 
> worked.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Curses prototype: phase 2 design and process

[john lunzer]

I realize you're doing this as an exercise but if you're getting frustrated 
with npyscreen (I also think the docs are a little sparse) there is always 
urwid, which I think has much better documentation. It's also got all the 
widgets necessary for Leo.

Also, again, a good example of a full screen application which has a layout 
somewhat similar to what you'd expect in Leo is *pudb*. It's got a tree 
widget which lists variables and a code widget which shows source code. 
It's also got a list widget that lists the frame stack.

I've mentioned it before but there is also a full fledged code editor name 
xo (exofrills) which is also written in urwid.

My plan, when I magically found time, was to study both pudb and xo, 
because I think between the two there is enough there to put together a 
full fledged Leo curses GUI.

On Thursday, April 20, 2017 at 8:46:27 AM UTC-4, Edward K. Ream wrote:
>
> On Thursday, April 20, 2017 at 6:21:05 AM UTC-5, Edward K. Ream wrote:
>
> Remember, to run the app, use the --gui=curses command-line option. To 
>> quit the app, click on the ok button in the lower right corner, then hit 
>> return.
>>
>
> Also, when not editing, tab moves between widgets, and shift-tab moves in 
> the opposite direction.
>
> The npyscreen docs are weak.  Reading the code (or trial and error) is 
> more helpful.
>
> 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: Aha: think process, not knowledge

[john lunzer]

I think you've been saying this for years in less pointed ways. This post 
(potentially expanded to include the specific example you walked through 
with the curses GUI in the other thread) deserves a place in Leo's 
documentation.

On Wednesday, April 19, 2017 at 6:58:20 AM UTC-4, Edward K. Ream wrote:
>
> I've said many times that you don't have to remember much in order to work 
> on Leo.  That's true, but it in some ways its backward and negative.
>
> Yesterday I realized that there is a simpler, more direct, and more 
> positive way to express what I have been trying to say to devs for so many 
> years: *Focus on programming process, not knowledge.*
>
> Let's look at two examples.
>
>
> *Fixing bugs*
> 1. Find the code involved using searches, especially cff.
> 2. Discover what the code does, in detail, using g.trace or g.pdb.
> 3. Change the offending code.
> 4. (Optional) Create a new unit test.
> 5. Run all unit tests.
>
> As with all things, some practice will be required.  That *experience *will 
> give you all the knowledge you need.
>
> *Porting to curses*
>
> 1. Create one or more new files from leo/plugins/qt_*.py. These new files 
> will contain all the gui code called by Leo's core except for an event 
> loop.  See below.  Note: plugins/curses.py already exists. Use as you see 
> fit.
> 2. Disable all the code, replacing it by g.trace or by "assert False, 
> g.callers()".
> 3. Create a new gui in leoApp.py that inits an event loop.
> 4. Implement the event loop in one of the new files.
> 5. Run Leo until it starts up without crashing and everything works. Heh.
> 6. *Very important*: make sure that LeoTree.select handles node switching 
> properly.  Failures can cause loss of data. This is the only "extra" thing 
> you have to know.
> 7. Run all unit tests until they all pass.
>
> You could say that this is a high-level view of the port.  But I think the 
> better way to understand it is as a process.
>
> In particular, point 2 requires *no* knowledge of how Leo's core will 
> call the new code.  You will find that out soon enough as you examine the 
> crashes :-) There is no need for documentation, protocols, API's or 
> standards. 
>
> *Conclusion*
>
> Processes are incredibly powerful.  A single process, evolution, created 
> (and still creates) all aspects of the biological world, including humans. 
> A co-evolutionary process molded (and still molds) humans and their 
> societies.  Likewise, simple programming processes will allow anyone with 
> enough time on their hands to maintain or extend Leo.
>
> I will leave this world without having finished all that I would like to 
> do with Leo.  As my mother pointed out, that is a blessing.  Now, today, 
> for the first time, I have some confidence that others will be able to 
> continue the work of improving and extending Leo.  Following the simple 
> programming practices and processes sketched above will suffice.  Any 
> python programmer can start practicing these practices now.
>
> This Aha carries over to any skill or profession.  Yes, there can be a lot 
> of knowledge involved.  But more important are the processes of acquiring, 
> evaluating and using that knowledge. Imo, that's likely the reason so many 
> children follow in their parent's footsteps. They learn what their parents 
> do, and in the process learn what they need to know.
>
> 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: The design of a curses gui for Leo

[john lunzer]

Wow Edward, thank you for getting the ball rolling on this and describing 
the process so clearly. I'm going to study this process and try to follow 
what you've done if I ever get some time.

I agree wholeheartedly that the minibuffer is infinitely more important 
than menus, which are rarely if ever utilized by full screen terminal 
interfaces. Emacs includes a menu but the first thing I did when learning 
emacs at the command was turn it off the menu (which just seemed to each up 
valuable terminal real estate). 

On Wednesday, April 19, 2017 at 12:39:48 PM UTC-4, Edward K. Ream wrote:
>
> On Wednesday, April 19, 2017 at 11:28:22 AM UTC-5, Edward K. Ream wrote:
>
> Two new do-nothing classes, CursesFrame and CursesMenu, use the same 
>> __getattr__ trick.
>>
>
> There is no way I could have predicted that only the Gui, Frame and Menu 
> classes would be sufficient to get through Leo's entire startup sequence.  
> This is another illustration that process teaches us much more than 
> documentation or standards.  Sorta like "the game teaches the game".
>
> This has immediate practical importance.  We could dispense with menus 
> entirely (and maybe permanently) simply by having CursesMenu stay as it 
> is!  We just disable the trace in its __getattr__ method. Who could have 
> foreseen it would be this easy? Having a working minibuffer is much more 
> important than menus.
>
> 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: The design of a curses gui for Leo

[john lunzer]

Any curses oriented library should be sufficient for use over SSH, one of 
my favorite tools is pudb which is a wonderful linux-only python debugger. 
It is built using urwid which is based on curses.

As a curiosity there is also python-prompt-toolkit which does not use 
curses yet can also achieve full screen terminal applications (it is 
currently being refactored/redesigned to make full screen application 
development easier).

On Wednesday, April 19, 2017 at 7:40:23 AM UTC-4, Edward K. Ream wrote:
>
> It's all very well to understand that porting Leo to the curses gui is a 
> process, but that's not the end of the story.
>
> In particular, replacing the entry points in the new files will require 
> emulation of *all* of Leo's screen widgets.
>
> There are at least two starting points for curses widgets, npyscreen 
> <http://npyscreen.readthedocs.io/introduction.html>and and the very-old 
> urwid <https://www.peterbe.com/plog/blogitem-041030-1>.  In both cases, 
> the process would be the same.  Look at their source code, and copy (not 
> import) any relevant code into Leo so it can be hacked at will.
>
> The question arises, what does the python curses module do, and why does 
> it require compiled libraries?  There are at least two answers:
>
> 1. curses provides an abstraction layer, hiding details of individual 
> consoles on various platforms. The primary purpose of this layer seems to 
> be to represent the console/screen as an array of text cells.
>
> 2. curses provides an interface to system code that provides mouse-down 
> and keystroke events. These allow an event loop that avoids a busy form of 
> waiting.
>
> *Summary*
>
> The only crucial question is whether the curses model will suffice for 
> SSHing into a machine as John Lunzer wants.  I suspect curses *will* 
> suffice, but I don't know enough to be sure.
>
> Once that question is answered affirmatively, the bulk of the 
> design/coding work will be to map Leo's screen onto the curses screen.  
> npyscreen contains menu, text and tree widgets.  We will probably want 
> docks and tab widgets and anything else Leo uses. An icon bar is optional: 
> @button nodes create commands just like @command nodes do.
>
> Once the curses gui code converts an incoming character to a LeoKeyEvent, 
> passing that event to k.masterKeyHandler is all that will need to be done.  
> Leo's core will handle everything else, including key bindings.  Or so I 
> say now :-)
>
> HTH.  To repeat, I'm not likely to follow this path to its conclusion any 
> time soon, but for now it seem I can't stop thinking about this project.  
> All comments and especially corrections welcome.
>
> Super-high level, process-oriented thinking is super easy.  No need to do 
> any actual programming ;-) No wasted code or time.
>
> 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: Where have you been? Stuck at the command line.

[john lunzer]

What I've done in the short term is rather than using rsync I use fossil 
because it is cleaner and gives me reliable two way updating capabilities. 

I set up a fossil repo in a "online" location, where ever I'm keeping my 
files I want to keep synced. Then I clone the repo using fossil's ssh clone 
capabilities individually on the "offline" machines. fossil saves the 
"remote url" of where the clone came from. 

A "fossil sync" command at any cloned repo will request the most up to date 
versions of the files (as well as new files added to the repo) from where 
they were cloned from and also attempt to merge in any local changes. 

I still have to cascade updates between the second and third level. But I 
suppose if the main repo was on the node with access to both the "online" 
and "offline" network I wouldn't have to do the cascade. I'll toy with that 
soon. Each clone of the repo has a "remote-url" setting which allows you to 
point each clone to another clone to affect the topology of the repo 
distribution. The "master" clone has an empty "remote-url".

Using RSA keys it should be possible to set this up so that the machines 
don't ask each other for passwords, but in keeping with security policies 
I've opted to simply input my password every time I update.

fossil is cross platform to it shouldn't be an issue to set this up between 
linux and windows workstations.

I've also been thinking of ways to mix entr <http://entrproject.org/> 
(linux only) into this to try to automate things further.

On Wednesday, April 19, 2017 at 1:48:03 PM UTC-4, Eric S. Johansson wrote:
>
>
>
> On Tuesday, April 18, 2017 at 7:50:30 AM UTC-4, john lunzer wrote:
>>
>> A lot of my recent work has been on Linux workstations/servers on these 
>> offline networks. These require two levels of SSH to pass through. SSH to 
>> secured computer on corporate network, then SSH to offline workstations. In 
>> fact I usually have several PuTTY terminals open at once, one of them is 
>> always the node the "offline" computers are connected to. I then 
>> painstakingly haul over everything I need by means of scp/rsync.
>>
>
> I have a similar need for different reason. Because of my disability and 
> use of speech recognition, I'm bound to Windows. However, I do all my work 
> on Linux systems. What I want is for Leo to trigger an rsync to a remote 
> host and then, somehow trigger an install script to update the production 
> environment such as a Web server. The second stage is usually required to 
> cross security perimeters, fix permissions, ownership etc. 
>
> The first stage would require a plug-in that implements "I saved in this 
> directory, this directory means that machine target, synchronize to that 
> machine target".
> The second stage requires an inotify reaction routine that knows how to do 
> the appropriate transformations on a file or directory to a given location. 
>
> Obviously, there would be a lag in copying and synchronization that 
> hopefully wouldn't be too bad. I may take a stab at the second stage soon 
> because this would make my development life easier. The place to start is a 
> way of representing the file/directory and destination PUG (permission, 
> user, group). I did something like this years ago I don't know if I still 
> have the code.
>
> John, I suspect you could use something similar except you would need a 
> second and third stage. Where the second stage simply replicates (another 
> rsync).
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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 have you been? Stuck at the command line.

[john lunzer]

I will investigate sshfs and the sftp plugin. Given my two levels of SSH 
I'm not sure if either would be workable but I will check.

On Monday, April 17, 2017 at 3:30:55 PM UTC-4, Terry Brown wrote:
>
> On Mon, 17 Apr 2017 12:16:46 -0700 (PDT) 
> john lunzer <lun...@gmail.com > wrote: 
>
> > I'm not trying to manipulate anyone into somehow getting Leo onto the 
> > command line. 
>
> If you can manipulate someone into doing this, please do ;-)  I'd love 
> to have command line Leo too.  I work on marginal connections too - 
> just quick enough to make putting up with laggy X11 forwarding doable, 
> but tty would be nice. 
>
> > I'm just reporting in from deep on the front lines as 
> > somebody who loves and appreciates Leo and misses it sorely. 
>
> You've probably thought of these things, and they're much easier if 
> your local machine is linux, not Windows, but you could sshfs mount the 
> remote machines and use Leo locally.  Or look at Jake's @sftp plugin, 
> which is a sort of push / pull approach. 
>
> I think the "what does it take to write alternative interfaces for Leo" 
> discussion is worthwhile.  Command line, web based, the edit pane 
> component I've been working on... all variations on that theme. 
>
> I think the tricky bits are things like key handling and abbreviations 
> and so on.  But not everything has to be supported everywhere. 
>
> 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: Where have you been? Stuck at the command line.

[john lunzer]

Of course Edward, I tried to make it clear in original post that in now way 
was I trying to manipulate/trick you into taking this on. It's a *huge* 
project. 
I think you've got important core work to do that doesn't involve writing 
GUIs. Terry alluded to this but the only thing I would say, perhaps as a 
discussion for your sprint, is simply that you consider the current 
interface for writing front-ends in Leo. 

I think if I *were* going to try to coerce you into anything it would be in 
reviewing the boundary between Leo's core and Leo's Qt interface to ensure 
that it is fully generic/decoupled so that it becomes as easy as possible 
for *others beside you* to write front-ends for whatever comes along. From 
my limited attempts to understand this interface it looked like the line 
might have blurred a bit over the years, but that might also be me just not 
having the expertise with either Leo or Qt to know where the line is 
exactly. Blurry line or blurry vision? Not sure.

Despite you being a constant with Leo for decades I think we all know all 
good things must come to an end at some point. My only wish, when you 
leave, is that Leo's abstraction layers are clear, clean, concise. That way 
when you're gone perhaps a team of 5 or 6 of us can hobble enough effort 
together to keep Leo alive (by writing new parsers for new languages and 
new GUIs for whatever popular framework is available).


On Tuesday, April 18, 2017 at 7:32:27 AM UTC-4, Edward K. Ream wrote:
>
> On Tuesday, April 18, 2017 at 6:10:19 AM UTC-5, Edward K. Ream wrote:
>
> > I'll see if I can do a hello world app today. 
>
> '''hello_curses.py: Hello world in curses.'''
> import curses as c
> import time
> w = c.initscr()
> w.insstr('Hello World')
> w.refresh()
> time.sleep(2)
> c.endwin()
>
> To repeat, this would be a major project.  I'm not going down this rabbit 
> hole any time soon.
>
> 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: Where have you been? Stuck at the command line.

[john lunzer]

For about half of my SSH work my files are on what is called the "primary 
network", which is accessible to all windows workstations (where I sit) and 
a few authorized more powerful and capable Linux workstation/servers. When 
I'm accessing these particular remote Linux workstations through PuTTY, I 
do use Leo because my machine has access to the same network shares that 
the Linux servers do.

In many large corporations it is difficult to get a new piece of hardware 
blessed to join the "primary network", but the pace of business is such 
that we have to use new hardware far before jumping through the hoops of 
getting something hardened by security. In these cases we will set up an 
"offline" network (usually in labs) which connects to workstation already 
on the "primary network". The idea is that if the other workstations do not 
have direct access to the internet and they're only being remotely accessed 
through hardware that's already been locked down by IT. 

A lot of my recent work has been on Linux workstations/servers on these 
offline networks. These require two levels of SSH to pass through. SSH to 
secured computer on corporate network, then SSH to offline workstations. In 
fact I usually have several PuTTY terminals open at once, one of them is 
always the node the "offline" computers are connected to. I then 
painstakingly haul over everything I need by means of scp/rsync.

So the whole thing is a bit ugly and setting up network file sharing to the 
"offline" hardware with NFS/sshfs starts to get sketchy from a security 
standpoint. 

Initially I attempted to do all my editing on files on the "primary" 
network and then scp/rsync them over to the "offline" workstations but I 
quickly lost the discipline due to the need for quick edits, instead opting 
for terminal based editing facilities.

That's where I'm at, one of the only solutions I can think of longterm is 
having a localized (offline) terminal based outlining editing tool. I think 
there are only two candidates, Leo + full terminal UI or emacs + leo-mode. 
I think they both involve a lot of work. 

I think ideally Leo would gain a full terminal UI. I'm personally waiting 
for Jonathan Slenders to finish python-prompt-toolkit 2.0 because he is 
rewriting huge portions of it to make it easier to write full screen 
terminal applications. He had already the 0.x and 1.x versions to write 
PyMux and PyVim but really he was the only one capable of coercing 
python-prompt-toolkit to producing full screen terminal applications.

On Monday, April 17, 2017 at 3:25:59 PM UTC-4, Edward K. Ream wrote:
>
> On Mon, Apr 17, 2017 at 2:16 PM, john lunzer <lun...@gmail.com> wrote:
>
> > ​stuck SSHing into workstations remotes...I am desperate and saddened by 
> not having Leo. I so badly desire to walk through code in a proper outline.
>
> Interesting problem.  Let's see what we can do...
>
> I've never done any SSHing, so correct me if I'm wrong.  Is the problem 
> that your external files are on another machine and it would be too 
> expensive to copy them over the link to a machine with Leo on it?
>
> 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.

Where have you been? Stuck at the command line.

[john lunzer]

My job has me primarily stuck SSHing into workstations remotes over not so 
great connections, so -X forwarding is not really an option. A lot of this 
is manually processing data with in-house tools and workflow automation 
tasks.

As a result I've been primarily been stuck with CLI only editors. My 
obvious choice is between vim and emacs. I used to use vim but I feel like 
I've recently groked emacs so I'm using that now.

Regardless. I am desperate and saddened by not having Leo. I so badly 
desire to walk through code in a proper outline. As many know emacs has Org 
mode but it is too "bulky" for trying to emulate what Leo does. I have some 
intuition that built-in to the core of emacs are all the tools necessary to 
create a "Leo-mode" but I certainly don't have the time right now to 
investigate. Long term, I'm trying to contemplate if it would be easier to 
write a limited CLI front-end for Leo or if it would be easier to write a 
limited Leo style outlining mode in emacs. They both seem daunting.

I'm not trying to manipulate anyone into somehow getting Leo onto the 
command line. I'm just reporting in from deep on the front lines as 
somebody who loves and appreciates Leo and misses it sorely. 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: Another small glitch (recurring icon problem)

[john lunzer]

I'm going to have to agree with Edward, I can't see how the two issues 
could possibly be linked. Anything is possible of course but I just can't 
see the link. Sorry we couldn't be more help. I've never heard of any 
Python application causing an issue like this.

On Wednesday, March 8, 2017 at 1:18:14 AM UTC-5, tscv11 wrote:
>
> Thank you very much to EKR for immediately fixing my previous issue 
> (Internet Explorer kept popping up, trying to connect to sites that my 
> firewall reported were unsafe). That has not happened again, and I'm very 
> happy!
>
> However, I've had a stubborn new problem for a while now. Unfortunately 
> it's been difficult to pinpoint the how and why, but every time I start 
> using Leo again it's not long (a day or two, typically) before my desktop 
> icons become covered with white sheets of paper, folded at one corner. They 
> do not replace the original icons. Instead, they partially cover them (you 
> can still see the edges of the original icons underneath).  When I've tried 
> *not* using Leo for extended periods, my icons have remained pristine.
>
> I know that I could be barking up the wrong tree but I did become more 
> suspicious when, right after restoring Windows from backup (and then 
> reinstalling Leo again), I accidentally (doh!) pushed the Sphinx button 
> (before doing anything else in Leo), then switched to the desktop -  there 
> were the freshly covered icons again.
>
> I have tried various "solutions" from the net, but nothing has worked,
>
> Thank you for any assistance - I am just a python novice, or I wouldn't 
> bug anyone with small things like this!
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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: HTML 5 Leo Viewer

[john lunzer]

Last time I used Atom this was one of my big complaints, though these days 
I feel like most editors have performance issues in one way or another.

On Tuesday, March 7, 2017 at 11:46:09 AM UTC-5, Arjan wrote:
>
> Regarding Atom, it might be interesting to take a look at Visual Studio 
> Code as well https://code.visualstudio.com. Very similar, also an 
> Electron app, but much faster opening of large files, and more snappy in 
> general (unless Atom improved a lot recently).
>
> Arjan
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-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

[john lunzer]

On Monday, March 6, 2017 at 11:41:26 AM UTC-5, Kent Tenney wrote:
>
> 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.
>

Leo is what it is, and what it happens to be is an editor. I don't think 
anything is going to change that and I don't think it should change. But, 
perhaps, Leo could be the editor of choice for your for your hierarchical 
data store

Abstraction is important. I see the big three primary layers as: data, 
"actions on data", visualization. I think Leo's focus is primarily on 
"actions on data" with enough visualization (tree pane) to make acting on 
data fluid. 
 

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

I'd love to hear more about this or read some docs about what you're 
working on. Any time I hear the word 'spatial' in relation to data my ears 
perk up a little. 
 

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

This may not be very helpful but you might want to take a look at Fossil 
, which is a versioning system that uses a database 
to store version artifacts. Dr Richard Hipp and co has put about a decade 
of work into merging the ideas versioning and databases. There are a lot of 
design documents and I've been told the C code is pretty clean and well 
commented. 
 

> Thanks,
> Kent
>

Anyway, I'm excited to hear about what comes out your work. As an aside, I 
think Offray is exploring some ideas related to versioning and databases as 
well.
 

> 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+...@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: solution: clearDirty @ nodes when working with chapters/organizational nodes

[john lunzer]

I have commit access, I'll see if I can make some time this week(end).

On Monday, March 6, 2017 at 7:29:21 AM UTC-5, Edward K. Ream wrote:
>
> On Sun, Mar 5, 2017 at 2:24 PM, john lunzer <lun...@gmail.com 
> > wrote:
>
> After using these for a few days I think mark-node-clean and 
>> mark-subtree-clean commands would be nice additions to the core.
>>
>
> ​Do you have git commit access?  If so, please issue a PR (Pull Request).
>
> 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: HTML 5 Leo Viewer

[john lunzer]

The differentiating factor in using Flexx rather than building the UI 
elements directly in Javascript is the "talking to" part. The Flexx UI 
Framework has built up a robust two way communication system between Python 
and JS which I think would be difficult to replicate. 

I'm not trying to derail your enthusiasm, but I wouldn't want you to spend 
your personal time on something where a reasonable solution may already 
exist. Although if you're more comfortable in JS than Python Flexx may be a 
non-starter.

Anyway, I'm excited to see what comes out of your work.

On Monday, March 6, 2017 at 8:30:16 AM UTC-5, john lunzer wrote:
>
> There is certainly a lot to think about here. As Edward stated, keeping up 
> with the Javascript world is a daunting task if you've already deeply 
> immersed in a whole other world. 
>
> To address your OP, there is currently a long term goal of investigating 
> using Flexx to build a web-based GUI for Leo 
> <https://github.com/leo-editor/leo-editor/issues/338>. It's definitely 
> long term, there are plenty of other priorities in Leo's core. I encourage 
> you to take a look at Flexx as well as the JS GUI Widget framework it is 
> built on, Phosphor <https://github.com/phosphorjs/phosphor>. While 
> Phosphor is not yet super popular I predict its popularity will rise when 
> JupyterLab <https://github.com/jupyterlab/jupyterlab> (which is also 
> built on Phosphor) comes out of alpha. 
>
> As you can see there is a strong desire in the Python universe to harness 
> web-based GUIs.
>
> If you plan on using Vue and your project grows to any reasonable size 
> then I encourage you take a look at Vuex 
> <https://vuex.vuejs.org/en/intro.html> which offers some tools and 
> constructs to help organize Vue projects.
>
> On Monday, March 6, 2017 at 5:36:19 AM UTC-5, Joe Orr wrote:
>>
>> Thanks for the welcome back!
>>
>> A few more thoughts on this topic:
>>
>> Cool trees is D3 v4:
>> https://bl.ocks.org/mbostock/e9ba78a2c1070980d1b530800ce7fa2b
>> https://bl.ocks.org/mbostock/4063550
>>
>> I'll get the Leo Viewer project up and running within a week or so on 
>> Github. 
>>
>> I'm currently working in full stack node development with Angular / Vue 
>> on front end + D3 at moment so I should be able to leverage some of that. 
>> Vue seems better for this project than Angular.
>>
>> I'm thinking the Leo Viewer could be used to generate some nice display 
>> examples from Leo generated content. Could be a good way to introduce more 
>> people to Leo. Besides D3 there are other HTML5 components that could be 
>> added fairly easily. For example I'm also thinking it would be cool to have 
>> reveal.js make a slide show out of a subtree.
>>
>> Once the viewer is useful, it is simple to make an Electron version, 
>> which makes it a complete cross platform desktop app:
>> https://electron.atom.io/
>>
>> And once that is working, the viewer could become an alternate front end 
>> to the existing Leo program by wrapping Leo in a node server. Node can talk 
>> to Python.
>>
>> Another thing to think about down the road is making a version of Leo 
>> from Atom, basically a similar technique (wrap Python in node).
>> https://github.com/atom/atom. Already thought of a good name for it: 
>> @Leo :-)
>>
>> Joe
>>
>>
>>
>> On Monday, March 6, 2017 at 5:06:25 AM UTC-5, Edward K. Ream wrote:
>>>
>>>
>>>
>>> On Mon, Mar 6, 2017 at 3:57 AM, Edward K. Ream <edre...@gmail.com> 
>>> wrote:
>>>
>>>> On Mon, Mar 6, 2017 at 3:44 AM, Joe Orr <joe...@gmail.com> wrote:
>>>>
>>>>> D3 demo:
>>>>> https://bl.ocks.org/kaleguy/57266b6fff9f864403e007e9efd06401
>>>>>
>>>>> ​Excellent!​
>>>>
>>>
>>> ​I've just purchased the ebook you referenced: d3.js tips and tricks.  
>>> One reason I did so was to test out the leanp
>>> https://leanpub.com/bookstoreub distribution.  Impressive.
>>>
>>> I guess I have to resign myself to always being a bit behind 
>>> <https://groups.google.com/d/msg/leo-editor/E094jyjF0c8/1uIoxOFoDwAJ>.
>>>
>>> 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.