Reusing design and code: the clash of cultures

[Edward K. Ream]

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

[Zoom.Quiet]

> ...Leo's history, and my own personal history

Yes, that is true,
and this is one great history for everyone Leo's user,
whatever EKR choice which one new feature ,
always keep the kernel Leo feel:
0: outline view with quickly control
1: grace node types, make notes input and export match mind wand
2: great plugins, support all kinds of programming action

that all i need Leo help;

and thanx again, EKR made the so grace tools for editor everything as Literate.


Edward K. Ream <edre...@gmail.com> 于2020年2月11日周二 下午11:02写道：

> --
> You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/0dfde5eb-a852-4cd2-9b02-5ca14972c5b9%40googlegroups.com.



--
life is pathetic, go Pythonic. 人生苦短, Python当歌 ;-)
课: https://py.101.camp/
怼: https://du.101.camp/
俺: http://zoomquiet.io
许: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦.
KM keep growing environment culture which promoting organization learning ..

[Edward K. Ream]

On Tuesday, February 11, 2020 at 9:12:09 AM UTC-6, Zoom.Quiet wrote:

and thanx again, EKR made the so grace tools for editor everything as Literate.

You're welcome. Thanks for the kind words. I appreciate them.

Edward

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

[Edward K. Ream]

On Wed, Feb 12, 2020 at 5:42 AM john lunzer <lun...@gmail.com> wrote:

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 doesn't' 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. 

Thanks for your perspective.

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.

At present nobody is complaining.

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.

I was referring to the underlying key-related problems of browsers. Afaik, flexx is not to blame.

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.

Collapsing complexity is an ongoing project. So is converting non-outline-related @test nodes in unitTest.leo to "proper" test cases in individual files.

That said, I rely on feature requests and bug reports to move Leo forward. Naturally, I give priority to my own desires, but Leo is close to perfect for me.

Edward

[Edward K. Ream]

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

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

[Offray Vladimir Luna Cárdenas]

Hi,

I think that Leo has been pretty good at creating its own singular place that no other program occupies. There are a lot of interactive notebooks, for example and a lot of overlapping ideas in such space. But the way Leo (de)construct text (markup or code) is pretty unique and inspiring, even if to think in new combinations (like in my case with Grafoscopio, mixing ideas from Leo, Jupyter and Pharo).

I'm not looking for an emergent interactive outliner in the Python world anymore. I don't know if Leo can be extended in that way, but in any case, seems that the way to do it, should be following the Leo culture, instead of embedding Leo in other programs. Maybe there is some kind of Qt widget that can be used to show interactive outputs for calculations, graphics and/or rendered text that can be added as a (real time?) lateral pane, but that exploration could borrow ideas from other places, while belonging to the "Leo Culture".

Thanks for the exploration and inspiration that comes from the Leo culture and worldview.

Cheers,

Offray

[Edward K. Ream]

On Sun, Feb 16, 2020 at 7:36 PM Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

I'm not looking for an emergent interactive outliner in the Python world anymore. I don't know if Leo can be extended in that way, but in any case, seems that the way to do it, should be following the Leo culture, instead of embedding Leo in other programs.

I agree.

Maybe there is some kind of Qt widget that can be used to show interactive outputs for calculations, graphics and/or rendered text that can be added as a (real time?) lateral pane, but that exploration could borrow ideas from other places, while belonging to the "Leo Culture".

The VR pane already can do a lot.  See the node "Viewrendered examples" in leo/test/test.leo.

Edward