Re: Reusing design and code: the clash of cultures

[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

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAMF8tS3o4T7iZEEC92hKu5%2BOAZ06qQTPKeVTkQ668X46nFqAtA%40mail.gmail.com.

Re: Reusing design and code: the clash of cultures

[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

On 11/02/20 10:02 a. m., 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/0dfde5eb-a852-4cd2-9b02-5ca14972c5b9%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/8b28da20-c9e8-3bfa-b88a-603d870dd7ec%40riseup.net.

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

[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

-- 
You received this message because you are subscribed to the Google Groups 
"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/19d8e95b-2b0f-445f-8f2d-39250c5313a2%40googlegroups.com.

Re: Reusing design and code: the clash of cultures

[Edward K. Ream]

On Wed, Feb 12, 2020 at 5:42 AM john lunzer  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

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAMF8tS2Xn03BM3pyAx1Pk2z74CviMvk0kuMfTZ9uCJFxg0QGZg%40mail.gmail.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: Reusing design and code: the clash of cultures

[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

-- 
You received this message because you are subscribed to the Google Groups 
"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/c76dcd4f-e326-4c53-af56-8629edad83eb%40googlegroups.com.

Re: Reusing design and code: the clash of cultures

[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  于2020年2月11日周二 下午11:02写道：
>
> 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/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 ..

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAAFijRdb_deRWvLOoA9EAHH3GX_fDXkV6RXT1AH189aZ%2Bv2RGg%40mail.gmail.com.