date:20190803

It' not missing, it's just named 'leo', not 'leo-editor'. Should that 
matter?

Rob...

On Saturday, August 3, 2019 at 5:08:52 PM UTC-4, Edward K. Ream wrote:
>
>
>
> On Sat, Aug 3, 2019 at 4:02 PM Rob > wrote:
>
>> Also, I should add the Leo log window's next line shows the current 
>> directory as where launchLeo.py and the .git folder reside. Is that the 
>> same thing as cwd?
>>
>>
>> current dir: D:/Synced/github repos/leo
>> load dir: D:/Synced/github repos/leo/leo/core
>>
>  
> This is the problem.  The cwd should be the leo-editor directory, which 
> seems to have gone missing!
>
> My log shows:
>
> current dir: c:/leo.repo/leo-editor
> load dir: C:/leo.repo/leo-editor/leo/core
>
> 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/edafcee3-769e-4e0c-96dc-41fba709d37b%40googlegroups.com.

Re: Leo version in log

On Sat, Aug 3, 2019 at 4:02 PM Rob  wrote:

> Also, I should add the Leo log window's next line shows the current
> directory as where launchLeo.py and the .git folder reside. Is that the
> same thing as cwd?
>
>
> current dir: D:/Synced/github repos/leo
> load dir: D:/Synced/github repos/leo/leo/core
>

This is the problem.  The cwd should be the leo-editor directory, which
seems to have gone missing!

My log shows:

current dir: c:/leo.repo/leo-editor
load dir: C:/leo.repo/leo-editor/leo/core

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/CAMF8tS01O%3DuRYrS6r419YgFz5wk%3DqvD-DpgVA-qL0XUD5O9DEA%40mail.gmail.com.

Re: Leo version in log

Also, I should add the Leo log window's next line shows the current 
directory as where launchLeo.py and the .git folder reside. Is that the 
same thing as cwd?


Leo Log Window
Leo 6.1-devel, devel branch
Python 3.7.3, PyQt version 5.9.6
Windows 10 AMD64 (build 10.0.17763) SP0
current dir: D:/Synced/github repos/leo
load dir: D:/Synced/github repos/leo/leo/core


On Saturday, August 3, 2019 at 4:53:51 PM UTC-4, Rob wrote:
>
> Did that and confirmed I'm in the cwd. Wondering if it's related to how I 
> get GitHub updates, but don't see a repo setting to change.
>
> Rob...
>
>
>> Apparently not. From the powershell prompt, do pwd :-)
>>
>> 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/7e495414-a7b0-4d2d-a7b1-9b455aa7e10d%40googlegroups.com.

Re: Leo version in log

Did that and confirmed I'm in the cwd. Wondering if it's related to how I 
get GitHub updates, but don't see a repo setting to change.

Rob...


> Apparently not. From the powershell prompt, do pwd :-)
>
> 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/3c019691-4542-45a7-97f0-3aac3b325181%40googlegroups.com.

Re: Leo version in log

On Sat, Aug 3, 2019 at 3:33 PM Rob  wrote:

> That helps to understand. However, I *am* launching from the main
> directory which contains the .git folder.
>
> I open an Anaconda Powershell prompt in the main Leo directory and invoke
> python launchLeo.py. Isn't that then the cwd?
>

Apparently not. From the powershell prompt, do pwd :-)

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/CAMF8tS1wG6-8HWr%2B2zz07M97kMvn-WUPawi0jS36mH818YXuMQ%40mail.gmail.com.

Re: Leo version in log

That helps to understand. However, I *am* launching from the main directory 
which contains the .git folder.

I open an Anaconda Powershell prompt in the main Leo directory and invoke 
python launchLeo.py. Isn't that then the cwd?

Rob...


On Saturday, August 3, 2019 at 4:17:49 PM UTC-4, Edward K. Ream wrote:
>
> On Sat, Aug 3, 2019 at 3:12 PM Rob > wrote:
>
> Sorry, but I don't know what 'cwd' means
>>
>
> cwd is the current working directory.  It can be affected by how you 
> launch Leo. Your startup script should "cd" (change directory) to the 
> leo-editor directory, which contains the (hidden by default) .git directory.
>
> For example, I launch Leo with from a .bat file containing:
>
> python c:\leo.repo\leo-editor\launchLeo.py --gui=qttabs %*
>
> which sets the cwd as desired.
>
> 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/20595b49-d48b-4e24-b8c1-c16b2f638eb0%40googlegroups.com.

Re: Leo and fossil merged with Rust

Hi,

On 30/07/19 10:26 a. m., Matt Wilkie 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.
>
>
> I've long been enamored with Fossil, though I've never used it in a
> real way. I just love it's self contained and portable nature. If
> python is batteries included, then Fossil is power plant included. ;-)

Fossil is really cool. Unfortunately Git has kind of monopolized
developers imagination and work flow, which makes even cooler to see
this demo of Fossil and Leo working together.

We have been using Fossil for all documentation related projects in
Grafoscopio, except for source code itself which is managed in
SmalltalkHub. Hopefully at some point we will merge code and doc repos
to use Fossil for both.


>
> 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 
>
>
> This is so cool. Being able to flip through all the versions of a node
> so quickly, to see it grow before my eyes. Wow, that is exciting.
>
So true. I was thinking? Can be this used as a way to sync real time
multi-author writing in a outline, ala CoreObject?[1]

[1] http://coreobject.org/

Cheers,

Offray

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/cd47b80f-12cf-da14-84cd-c000c747f731%40riseup.net.

Re: Leo 6.0 final released

On Sat, Aug 3, 2019 at 11:23 AM Matt Wilkie  wrote:

gitk shows the following labels on this branch:  v6.0, v6.1-dev,
>> 6.0-final-rel, master, remotes/origin/6.0-final-rev,
>> remotes/origin/master.  But not remotes/origin/v6.0.  Is that a problem?
>>
>
> I'm seeing the same with gitk and I honestly don't know if it's a problem.
> I was hoping you knew! At any rate, v6.0 self published to PyPi so Travis
> is fine with it. I guess we just keep going and wait and see. :)
>

Yes.  I think this is a good plan.

In black branch I just added black module as a dependency. In retrospect I
> can see it's better to wait until the active dev churn has dropped down
> before pitching something else in.
>

In future, base all your branches on devel, and only make changes to devel
(if you're sure) or in one of your own branches, based on devel.  That way
you won't step on anyone's toes.

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/CAMF8tS3-tjoEc5eyiZQCNCMWX7p2t-YmavLLTK8H4Lj7fhmHWQ%40mail.gmail.com.

Re: Leo version in log

On Sat, Aug 3, 2019 at 3:12 PM Rob  wrote:

Sorry, but I don't know what 'cwd' means
>

cwd is the current working directory.  It can be affected by how you launch
Leo. Your startup script should "cd" (change directory) to the leo-editor
directory, which contains the (hidden by default) .git directory.

For example, I launch Leo with from a .bat file containing:

python c:\leo.repo\leo-editor\launchLeo.py --gui=qttabs %*

which sets the cwd as desired.

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/CAMF8tS07%2BvJ-hp%2BjESMWvvUHHtzzia7dmdvivd%3D%3DLvG%3DM3g3jA%40mail.gmail.com.

Re: Huge Aha: org mode/vimoutline champions don't have to transliterate Leo's python code!

On Saturday, August 3, 2019 at 10:02:53 AM UTC-5, Edward K. Ream wrote:

*Summary*
>
> The proposed interaction between org mode (or vimoutline) and Leonine 
> services is a momentous breakthrough in Leo's history. 
>
> Perhaps only a page or two of elisp (or vimscript) code would be needed, 
> and a page or two of python code.
>

And I am the pyzo champion!  A page or two of python code (patched into 
pyzo) should suffice to embed Leo into pyzo.  My experiences will guide 
champions for vimoutline and org mode.

Pyzo doesn't presently allow plugins or other code-level optimizations, but 
that doesn't matter.  I can patch any part of pyzo using the techniques in 
pyzo_support.py.

I'll be working on this project next.

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/a0e41e9c-74b0-489b-be39-d07305d68dc4%40googlegroups.com.

Re: Leo version in log

Sorry, but I don't know what 'cwd' means or how to fix it. Is that in a Leo 
or GitHub setting somewhere? BTW, I use GitHub desktop on both Mac and PC 
to update Leo (don't use command line).

So, why would they be different on two machines when I'm pulling from the 
same source?

Rob...
 

>
> It's not.  Look at app.computeSignon & printSignon.  It contains:
>
> branch, junk_commit = g.gitInfo()
> author, commit, date = g.getGitVersion()
> # Compute g.app.signon.
> signon = ['Leo %s' % leoVer]
> if branch:
> signon.append(', %s branch' % branch)
> if commit:
> signon.append(', build '+ commit)
> if date:
> signon.append('\n' + date)
> app.signon = ''.join(signon)
>
> So g.getGitVersion is returning "" for the commit (build).  It's likely an 
> issue with the cwd.  That is g.getGitVersion runs:
>
> git log -n 1 --date=iso
>
> HTH.
>
> Edward
>

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

Re: Huge Aha: org mode/vimoutline champions don't have to transliterate Leo's python code!

On Sat, Aug 3, 2019 at 2:02 PM Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> Congrats on this aha :-)
>
Thank you.

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/CAMF8tS2%3Dw5a_Y78fgrE2WH3Ug6G7XkL_s5BMUh1OMCzyVvup8A%40mail.gmail.com.

Re: Leo version in log

On Saturday, August 3, 2019 at 12:19:44 PM UTC-5, Rob wrote:

> Why does my Mac Leo log window display the Leo build number and date and 
the Win10 log not?

I get:

Leo 6.1-devel, devel branch, build 3427d65881
2019-08-02 14:48:24 -0500
Python 3.6.3, PyQt version 5.8.0
Windows 10 AMD64 (build 10.0.17134) SP0

> I can't imagine it's the minor version differences between Python 3x or 
PyQt 5.x.

It's not.  Look at app.computeSignon & printSignon.  It contains:

branch, junk_commit = g.gitInfo()
author, commit, date = g.getGitVersion()
# Compute g.app.signon.
signon = ['Leo %s' % leoVer]
if branch:
signon.append(', %s branch' % branch)
if commit:
signon.append(', build '+ commit)
if date:
signon.append('\n' + date)
app.signon = ''.join(signon)

So g.getGitVersion is returning "" for the commit (build).  It's likely an 
issue with the cwd.  That is g.getGitVersion runs:

git log -n 1 --date=iso

HTH.

Edward

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

Re: Emacs features in Leo: general remarks

Hi,

On 1/08/19 12:30 p. m., john lunzer wrote:
> 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.


I have advocated for something similar. I don't know what can be
borrowed from Pyzo (and if this is necessary). But I would like to see
something like an IPython kernel that computes Leo In nodes and produces
Leo Out Nodes. Leo directives can be used to traverse such tree,
updating computations, using outputs to create reports and so on.

Cheers,

Offray

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ea58495b-a1f6-a1d4-a91f-3fe446e8d62c%40riseup.net.

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

Hi,

Just some comments, now that I have the time.

On 24/06/19 8:00 a. m., john lunzer wrote:
>
>
> 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 share your thoughts. For me Emacs and Pharo are kind of modern
survivals of long gone ideas of computing from the Symbolics machines
and the Dynabook, with cohesive computing experiences and environments
to support them. Symbolics, done on Lisp (hence elisp) and the Dynabook
done in Smalltalk (hence Pharo). Both, Pharo and Emacs survived by being
able to run inside a hosted operative system, while keeping their ideas
about an Integrated Computing Environment (as you coined, ICE) that you
inhabit most of the time. Org Mode and (in some way) Grafoscopio, bring
outlining capabilities to the Emacs and Pharo ICE's, respectively (but
Org Mode is far mature that Grafoscopio). Because of the original vision
Emacs and Pharo bring live coding and meta-system capabilities to the
ICE, being able to change it in real time from a single language.

Leo, as I have told several times, brings this meta-system capabilities
to the operative system, flat file word, by adding emergent organizing
and execution operations to such files, as defined by the user. The live
coding part is still missing (despite of the @button and @command
utilities) and that's why some of us have talked about IPython
integration and a services architecture.

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

I think that Emacs is far better integrated with the host OS that Pharo,
but Pharo is getting there. I think this is related with the primary way
of interaction with the system. While Emacs is more text based, Pharo is
more graphical, so that did that the kind of experience on both
environments focused on the strong points. Emacs in disguising as a text
editor and Pharo in disguising as an Integrated Development Computing
Environment. With Iceberg, Pharo is improving its DVCS integration,
particularly with Git.

With all this I want to underline that that the issue seems to be how
you internalize the hosted environment in your ICE. Leo, Pharo and Emacs
share this concern, but with pretty different approaches.

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

Grafoscopio was my attempt to integrate a Jupyter and Leo like
experience, build into Pharo (after unsuccessful attempts to make it in
Python). Because it happened in the context of a Design and Creation PhD
research, that used software as a way to understand and communicate the
problem of moldable artifacts to a grassroots community, and because was
my first program done in Pharo, software was not the only center and a
lot of quality improvements are possible.

I think that many of us are interested in the way we can use computers
to organize our

Re: Leo version in log

2019-08-03 Thread Chris George

Leo 6.1-devel, devel branch, build 3427d65881

Leo 6.1-devel, devel branch, build 3427d65881


Neon Linux based on Ubuntu 18.04


Chris

On Sat, Aug 3, 2019 at 10:19 AM Rob  wrote:

> On my Win10 machine, I get this in the log window:
>
> Leo 6.1-devel, devel branch
> Python 3.7.3, PyQt version 5.9.6
> Windows 10 AMD64 (build 10.0.17763) SP0
>
>
> On my Mac, I get this:
>
> Leo 6.1-devel, devel branch, build 3427d65881
> 2019-08-02 14:48:24 -0500
> Python 3.7.4, PyQt version 5.13.0
> darwin
>
> Both machines use the most current version on the GitHub (devel branch).
>
> Why does my Mac Leo log window display the Leo build number and date and
> the Win10 log not? I can't imagine it's the minor version differences
> between Python 3x or PyQt 5.x.
>
> Also curious what shows up for Linux users or on other systems.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/d3cd9ca6-99a5-4a22-8a2a-93db2fda35a7%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CADWQas0f9bOegK%3DXCPxurgXX4RUfQ6WMr59geSxM%2BSVfjKzsnA%40mail.gmail.com.

Re: Huge Aha: org mode/vimoutline champions don't have to transliterate Leo's python code!

Congrats on this aha :-)

Really glad to see the Leo services coming finally to the picture. It
was a long path, but surely a pretty powerful one.

Cheers,

Offray

On 3/08/19 10:13 a. m., Edward K. Ream wrote:
> On Saturday, August 3, 2019 at 10:02:53 AM UTC-5, Edward K. Ream wrote:
>
> *Summary*
> *
> *
> The proposed interaction between org mode (or vimoutline) and
> Leonine services is a momentous breakthrough in Leo's history.
>
> Perhaps only a page or two of elisp (or vimscript) code would be
> needed, and a page or two of python code.
>
>
> I forgot to mention something very important.  There will be no need
> for a champion to design anything new. Org mode will work exactly as
> before, but it will support Leonine operations on the org mode nodes.
>
> Do you see how important this is? Org mode headlines might contain
> @file x.y or @clean x.y without org mode knowing or caring. 
> Similarly, org mode itself will know nothing about Leo directives and
> section references in org mode bodies.
>
> Syntax coloring would likely be another Leonine service.  That service
> might return a description of the colorizing for a particular org mode
> node.
>
> 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/5fb66438-9cb7-441d-92cd-455eca4cc8c9%40googlegroups.com
> .

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/49413f28-32a3-af9c-87ba-cc55e422c476%40riseup.net.

Leo version in log

On my Win10 machine, I get this in the log window:

Leo 6.1-devel, devel branch
Python 3.7.3, PyQt version 5.9.6
Windows 10 AMD64 (build 10.0.17763) SP0


On my Mac, I get this:

Leo 6.1-devel, devel branch, build 3427d65881
2019-08-02 14:48:24 -0500
Python 3.7.4, PyQt version 5.13.0
darwin

Both machines use the most current version on the GitHub (devel branch).

Why does my Mac Leo log window display the Leo build number and date and 
the Win10 log not? I can't imagine it's the minor version differences 
between Python 3x or PyQt 5.x.

Also curious what shows up for Linux users or on other systems.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d3cd9ca6-99a5-4a22-8a2a-93db2fda35a7%40googlegroups.com.

Re: Leo 6.0 final released

2019-08-03 Thread Matt Wilkie


>
> gitk shows the following labels on this branch:  v6.0, v6.1-dev, 
> 6.0-final-rel, master, remotes/origin/6.0-final-rev, 
> remotes/origin/master.  But not remotes/origin/v6.0.  Is that a problem?
>

I'm seeing the same with gitk and I honestly don't know if it's a problem. 
I was hoping you knew! At any rate, v6.0 self published to PyPi so Travis 
is fine with it. I guess we just keep going and wait and see. :)

In black branch I just added black module as a dependency. In retrospect I 
can see it's better to wait until the active dev churn has dropped down 
before pitching something else in.

-matt

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/266f8043-4cea-426b-a595-8e4c25c6f8cf%40googlegroups.com.

Re: Huge Aha: org mode/vimoutline champions don't have to transliterate Leo's python code!

On Saturday, August 3, 2019 at 10:02:53 AM UTC-5, Edward K. Ream wrote:

*Summary*
>
> The proposed interaction between org mode (or vimoutline) and Leonine 
> services is a momentous breakthrough in Leo's history. 
>
> Perhaps only a page or two of elisp (or vimscript) code would be needed, 
> and a page or two of python code.
>

I forgot to mention something very important.  There will be no need for a 
champion to design anything new. Org mode will work exactly as before, but 
it will support Leonine operations on the org mode nodes.

Do you see how important this is? Org mode headlines might contain @file 
x.y or @clean x.y without org mode knowing or caring.  Similarly, org mode 
itself will know nothing about Leo directives and section references in org 
mode bodies.

Syntax coloring would likely be another Leonine service.  That service 
might return a description of the colorizing for a particular org mode node.

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/5fb66438-9cb7-441d-92cd-455eca4cc8c9%40googlegroups.com.

Huge Aha: org mode/vimoutline champions don't have to transliterate Leo's python code!

The way is now clear for close integration with Leo and either emacs org
mode or vimoutline. Similar remarks apply to both, so I'll just discuss
org mode here.

I have been assuming that supporting Leo in emacs would require
transliterating much of Leo's core into elisp. But that's not so! An org
mode champion only need tweak org mode so it communicates with Leo. Using
Leo's bridge, elisp code would request various *Leonine services*.
Examples of such services are:

- Update the Leo outline when the org mode outline changes.
- Update external files using Leo's existing python code.
- Request a unique gnx for a new node.

The elisp code could request these Leonine services when saving the org
mode file, whenever an org mode node changes, or at other times.

*Python wrappers provide Leonine services*

An org mode champion need only define simple (python) wrappers (in Leo)
that provide these services.* There should be no need to transliterate
Leo's python code into elisp!*

*Summary*

The proposed interaction between org mode (or vimoutline) and Leonine
services is a momentous breakthrough in Leo's history.

Perhaps only a page or two of elisp (or vimscript) code would be needed,
and a page or two of python code.

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/dedc4da8-a7a2-407c-bdd9-853d1fe1ebde%40googlegroups.com.

The next 12 months

I'm always happy to get a new version out the door so that I can begin 
coding again. It's my first love.

I do try to do a bit of planning from time to time, as today's posts show 
:-)

The major items scheduled for 6.1 

 
will likely keep Team Leo busy for another year. The highlights:

- Documentation on GitHub pages, maybe using AsciiDoctor.
- Integration of pyzo features into Leo.
- Create an org-mode style tree/body pane.
- Improve xemacs and vim plugins.
- Add more languages to babel plugin.

And on and on.  Furthermore, I plan to experiment with IPC and web 
assembly, as time permits.

Let me know if you are particularly interested in one of the 6.1 projects.

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/ddf563e6-2f84-45f5-8c34-a130a38ba813%40googlegroups.com.

Thought experiment re IPC

Wouldn't it be great if we could somehow just replace Leo's body pane with
pyzo's or vim's. See #990
.

Well, that's not going to happen right away, but it might happen in a year
or three.

A thought experiment shows the problems. Suppose we could, say by using
D-Bus , magically connect vim and Leo
so that vim becomes Leo's body pane. Well, Leo's users would now have to
configure vim as well as Leo!

Worse, vim now has to be told how to "escape" back to Leo, and vice versa.
It's quite a design challenge.

Instead, a *single* app, (Leo or vim) must be responsible for all the
interactions. For now, this is the only way to maintain the illusion of
simplicity that I talk about so often.

Things could change in future. Desktop web assembly promises many cool
things, including a platform independent way of running C++ or rust (or
elisp) code. When that happens, we could imagine compiling both neovim (or
emacs) and Leo into webasm. In that case, we could tweak both Leo and vim
to work together.

*Summary*

Embedding vim or emacs into Leo isn't going to happen now, but might be
possible in a year or three.

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 view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/6109bd1d-ecd2-42ce-868c-e4a71074de74%40googlegroups.com.

Emacs is already scriptable with python

In another thread I said, "it doesn't seem likely that emacs will ever be 
scriptable with python.  Unless some hero steps up Leo in emacs will remain 
a tantalizing possibility, just out of reach."

Happily I was forgetting pymacs and Leo's bridge 
.  
In effect, Leo's support for pymacs *already* makes emacs scriptable using 
python!  To repeat the example:

; Step 1: load leoPymacs if it has not already been loaded.(setq reload nil)(if 
(or reload (not (boundp 'leoPymacs)))
(setq leoPymacs (pymacs-load "leoPymacs" "leo-"))
(message "leoPymacs already loaded"))
; Step 2: compute the path to leo/test/ut.leo using a Leo script.(setq script
"g.app.scriptResult = g.os_path_abspath(
g.os_path_join(g.app.loadDir,'..','test','ut.leo'))")(setq fileName 
(leo-run-script nil script))
; Step 3: execute a script in ut.leo.(setq c (leo-open fileName))(setq script 
"print 'c',c.shortFileName() ,'current:',c.p.h")(leo-run-script c script)


Folks, this is a big deal.  An emacs champion could easily:

1. Add any desired (python) functions to leoPymacs.py.
2. Add any desired (elisp) hooks to emacs, especially org mode.

The way appears open to embed Leonine support into emacs.

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/8e3efa10-6b55-47d9-a96f-3b7f93c31041%40googlegroups.com.

Aha re sharing code

A serious dilemma has been on my mind recently with regard to using pyzo's
code. Neither importing nor copying pyzo's code is free from serious
problems. Either way, changes to pyzo will ultimately affect Leo.

This morning I saw a sideways resolution of this dilemma. Regardless of
how Leo uses pyzo's code:

*Aha: Leo's devs become responsible for pyzo's code.*

Leo's devs will have to fix any bugs found by Leo's users, and probably
will want to fix bugs found by pyzo's users.

Furthermore, significant problems will arise in adapting pyzo's code,
regardless of whether Leo imports or copies pyzo's code. There is no
question about this: pyzo and Leo are two different worlds.

*Strategy*

The simplest way forward will be to copy relevant parts of pyzo into
leo/plugins/pyzo_support.py. This will give me complete control of the
code. It will be essential to mark (with comments) all changes made to the
pyzo code.

Notice I said "simplest" in the previous paragraph. Significant changes
may be required. For example, imports may have to be changed when copying
code from pyzo to pyzo_support.py. The code must not pull in the "real"
pyzo code by mistake.

*Summary*

This Aha is good news. There can be no clever way forward that somehow I
might have missed.

My first pyzoic project will be #1149
: dired browser.
This will be a good prototype for the much larger #1158
: pyzo shell.

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/433e0e56-7267-453e-8fd2-74657a122a2b%40googlegroups.com.

Re: Problems with git push --follow-tags in master

On Sat, Aug 3, 2019 at 6:34 AM Edward K. Ream  wrote:

I deleted my local "black" branch and then pulled it again.  Now all seems
well.  I was able to:

git push --follow-tags

but there is still no v6.0 tag on origin/master.  Otoh, gitk show the v6.0
tag as yellow, whereas gitk shows the tags that did get pushed to
origin/master as green.  No idea what this means.

BTW, I had to log in again to GitHub, after which I got a weird message
from github, but I don't think this is worrisome.

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/CAMF8tS2RdEb_ZQtFS0y%3DgUvsSf7-64wcnHCt-xZYh_NgDj%2BBBg%40mail.gmail.com.

Problems with git push --follow-tags in master

git push --follow-tags

[a64] c:\leo.repo\leo-editor>c:\apps\Git\bin\git.exe push --follow-tags
To https://github.com/leo-editor/leo-editor.git
 ! [rejected]black -> black (non-fast-forward)
error: failed to push some refs to 
'https://github.com/leo-editor/leo-editor.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I certainly do not want to pull anything! Perhaps I should destroy my local 
copy of the "black" branch.

Any other ideas?

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/f8a809f2-7256-4e7b-8d8f-6dc9761a54da%40googlegroups.com.

Re: Leo 6.0 final released

On Sat, Aug 3, 2019 at 6:13 AM Edward K. Ream  wrote:

gitk shows all is well.
>

For a panicky moment I thought perhaps I hadn't pushed to master, but I
did.  The latest rev on master is db55bd0, both on my machine and in the master
branch .

gitk shows the following labels on this branch:  v6.0, v6.1-dev,
6.0-final-rel, master, remotes/origin/6.0-final-rev,
remotes/origin/master.  But not remotes/origin/v6.0.  Is that a problem?

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/CAMF8tS2fsHXZgTvYnZgs25%3DFxjvVQuvYqmYcX4cfsFUunxsyZA%40mail.gmail.com.

Re: Leo and black

On Fri, Aug 2, 2019 at 4:38 PM Matt Wilkie  wrote:

> After playing with black for a bit, I quite like it. The only thing I've
> seen it change that I haven't wholesale agreed with is dedenting "next line
> comments".
>

This doesn't bother me.  In this black issue, amb states:

"Comments are not and will not be hand-edited by Black. Black is not able
to understand if the comment is safe to rewrap. Use your editor to re-flow
the comments which *are* safe and Black will respect your edit."

This is probably good enough for me, though I haven't actually blackened
much.  We'll see.

I am dithering whether to add black-like line breaking to Leo's own
(faster) beautify command.  I think I have to do it, just as a
possibly-useful experiment.  If the experiment works, we can insert any
desired options, regardless of what the black devs think about such things
;-)

Important: Leo will support @int blacken-max-line-length, default (I think)
88.  This is one of the few black options, and it is the crucial one.

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/CAMF8tS0sy0AyLWBV-8HOOFJD4oHjF8eDz%2BS29wv6SNNJGTSeYg%40mail.gmail.com.

Re: Leo 6.0 final released