Ipython looks up completions from live objects. It only works in interactive 
mode and so is not useful for leo.


On 10/9/11 7:06 PM Edward K. Ream wrote:

On Sun, Oct 9, 2011 at 10:26 AM, Terry Brown <[email protected]> wrote:
> I think the power and challenge of Leo is that it's such a general
> purpose environment.

True, but that doesn't necessarily add to the *perceived* weight.

> But none of them have the `for i in p.children() do stuff with p.b/p.h`
> layer that Leo has - at least not that I'm aware of.

Right. And look how light this is. It is, by far, the simplest, most
powerful data-centric API/DOM in the universe :-)

> To me the heaviness, in Leo, and I do know what you mean when you talk
> about that, it mostly in the interface.

You have hit the nail on the head.

After I wrote this post I realized that it mostly my *workflow* that
is heavy, not Leo itself.

- The import @auto nodes script that I have been using has some
serious flaws. They can be corrected without changing Leo in the
slightest.

- Kent has, over the years, been harping on exactly these kinds of
interface issues. This morning I realized that his remarks point the
way to some simple changes that would make Leo appear much lighter:

1. The open dialog *must* show all files, not just .leo files. This
is a big blunder, because Leo can *already* open non-.leo files: they
get opened in @edit nodes, just like in SciTe. Doh! It is already
possible to use Leo in "SciTe" mode.

2. As Kent suggested long ago, it would be good to unify various
open/import commands. For instance, if I *open* an external file with
embedded sentinels, an @edit node gets created, and all the ugly
sentinels are visible and no nodes are created. Instead, the open
command should test the file for sentinels (easy to do) and *import*
the file instead.

I shall make both all these changes immediately. They will make a
huge difference.

> It continues to look old to me.

Thanks for this. Wow factors are very important. Leo could use a
designated designer. Any help in this area would be appreciated.

Clearly, Steve Jobs was a master at getting design right.

If you don't get around to this yourself, it might be good to remind
me from time to time. Come to think of it, filing a bug would be
appreciated.

> But I think a lot of this could be addressed with incremental
> improvement.

Exactly. A day or two's work could make a huge difference.

> I'd like the see the solarized color scheme available.

It's on the to-do-first list.

> Maybe the scroll bars could be made less visually dominant.

Interesting design idea.

> Maybe the Minibuffer line could hide when it's not being used.

Possible, although it should always be visible by default so that
newbies know that it is there.

> The key handling and focus handling I think suffers from a tension
> between letting the gui toolkit do what it wants and trying to make it
> do very specific things, I've wondered what a more vanilla gui
> system would be like.

Oh my. That would be huge change. True, the more minimalist
emacs/vim way does have appeal.

> Other IDEs has sometimes startlingly smart autocompletion - I need to
> play with Leo's more to decide what level it's at at the moment.

Leo's code is similar to IPython's code in this regard, but IPython's
completion is considerably better. There is a big opportunity here
for "borrowing" more of the IPython way. I looked at the IPython code
yesterday, and I am definitely suffering from completion envy :-)

> But at the end of the day it's the flexibility of Leo which makes it
> unique and uniquely useful and productive.  There are plenty of
> products competing to most neatly and cleanly package the gui toolkit's
> default behavior, the world doesn't need another one of those.

I agree. Only incremental changes are needed. Improving the open
command would go a *long* way to making Leo lighter, that is to say,
making a "SciTe mode" of operation perfectly natural.

> Perhaps Eclipse is the best thing to compare Leo to, in terms of power,
> and customization potential.  Does Eclipse have a better learning curve
> than Leo?  If so, why?  I've never really used it, before Leo I used
> Emacs for coding and Freemind and other things for outlining.

Imo, Eclipse sucks compared to Leo :-) But, like Blender, it does
invite us to create a framework in which new *kinds* of windows are
possible. Terry, you have already created the backdrop for that
framework. It only needs to add more kinds of windows...

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.



-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Reply via email to