2019 retrospective. Plans for 2020

[Edward K. Ream]

2019 was supposedly going to be the year of playful prototypes. Instead, it was consumed by the following ponderous projects :-)

1. Support for Qt docks

A ponderous success. Qt docks are not easy to use, but some people appreciate having them, despite the difficulties.

2. The pyzo_in_leo plugin

At present, this plugin is mostly a failure. There is no real connection between pyzo running within Leo and Leo itself.

3. The beautify and fstringify commands

These commands are complete successes. They work well within Leo, and they use the new token-order classes in leoAst.py effectively.

There was a big surprise, however. Leo's beautify commands must needs be completely separate from the external black program. This means that the Orange class in leoAst.py can't be considered a replacement for black. Leo 6.1 added the black command. Leo 6.2 will remove it. It's a bad idea.

4. Coverage testing using traditional unit tests

This got a thorough vetting while testing new code in leoAst.py. This is a marvelous new pattern for me. It made the last four month's work worthwhile.

Plans for 2020

Three items aim to complete projects started in 2019:

1. I am considering making Leo's legacy operation (no Qt docks) the default. This will simplify life for newbies. I'll ask for comments in another thread.

2. It may be possible to use pyzo's yoton framework to communicate between Leo and the embedded copy of pyzo. I few hours of work will show whether this is feasible. As a bonus, it may be possible to use Leo's plugin manager within pyzo. I do not intend this to turn into a major project.

3. I will likely announce the new token order generators (in leoAst.py) to the wider world. This announcement will be strictly a FYI. There will be no claims that Leo's beautify command is superior to black.

After these items are complete I'll focus on continual incremental improvements to Leo.

Schedule

Leo 6.2 will go out the door when all bugs scheduled for 6.2 have been fixed. This will likely take a few more weeks.

It's too late to fix #1437. That must wait until early in the 6.3 release cycle.

Summary

2019 involved heavy work on projects with minimal impact on most Leo users. This is disappointing. I would like to focus on more consequential projects.

On a happier note, except for VS Code, there are no more plans to embed Leo in other editors. This removes a long term distraction for me.

Instead of embedding, Leo's bridge module allows IPC (Inter-Process Communication) between Leo and other editors. IPC may offer a low-cost way of connecting Leo with pyzo, thereby rescuing the pyzo_in_leo plugin. No way am I going to spend months on this project. It will fail if it doesn't succeed quickly.

And that's it. As always, fixing bugs will be near the top of the list.

Edward

[Thomas Passin]

On Tuesday, February 25, 2020 at 9:43:57 AM UTC-5, Edward K. Ream wrote:

2019 was supposedly going to be the year of playful prototypes. Instead, it was consumed by the following ponderous projects :-)

There was a big surprise, however. Leo's beautify commands must needs be completely separate from the external black program. This means that the Orange class in leoAst.py can't be considered a replacement for black. Leo 6.1 added the black command. Leo 6.2 will remove it. It's a bad idea.

Orange is the new Black??

[Edward K. Ream]

On Tue, Feb 25, 2020 at 11:31 AM Thomas Passin <tbp1...@gmail.com> wrote:

Orange is the new Black??

Right. It was a joke name.

I had intended that the code in leoAst.py would become a stand-alone alternative to black. But I've abandoned that plan, for several reasons. First, and most importantly, I see no reason to complete with black. It does things better than Leo, and I can't justify the work required to compete successfully. Second, Leo's beautifier must know about Leo's outline structure, so the two "products" must be different.

Edward

[Edward K. Ream]

On Tuesday, February 25, 2020 at 8:43:57 AM UTC-6, Edward K. Ream wrote:

> After [6.2] I'll focus on continual incremental improvements to Leo.

I forgot to mention one more topic. Leo 6.1 removed emacs-like macro commands, and various expand/contract commands related to windows. Both decisions have disappointed some users.

My present plan is to reinstate both sets of commands in Leo 6.3. Imo, these commands are worth having even if only a few users want them.

I'll experiment with making macro recording more Leonine, say by having a macro create a set of commands in body text. That would make macro potentially more flexible and permanent than emacs-like one-offs. Yes, I know emacs has a way of saving macros...

Edward

[Matt Wilkie]

Thank you for the retrospective summary. I was more or less present for all of it, yet it still read like news to me. ;-)

-matt

[Edward K. Ream]

On Tue, Feb 25, 2020 at 5:49 PM Matt Wilkie <map...@gmail.com> wrote:

Thank you for the retrospective summary. I was more or less present for all of it, yet it still read like news to me. ;-)

Hehe. You're welcome.

Edward