Status report re Robin Dunn's mission
edream
replying directly to such an old thread.
Robin's mission has been a powerful behind-the-scenes influence on my
thinking. I've recently created a status report on Leo's google-
groups site: http://groups.google.com/group/leo-editor
This status report is very long: I'll just summarize it here.
1. The first post at http://groups.google.com/group/leo-editor/browse_thread/thread/4f76a0f57759aba
is a verbatim repost of Robin's original post.
2. The second (long) post on the same thread is an item-by-item
discussion of who Leo meets, or fails to meet, Robin's checklist.
3. The third (long) post is a discussion of how Leo goes far beyond
Robin's checklist. The basic idea is that if all you want is Emacs,
you know where to find it. To displace Emacs, an editor must offer
*much* more than Emacs. This, Leo does, imo.
I welcome any comments on http://groups.google.com/group/leo-editor/browse_thread/thread/4f76a0f57759aba
here from pyxides folk. My guess is that it would be most comfortable
to comment on Leo's site, but it's up to you.
Finally, I'd like to invite Robin, once again, to start using Leo.
Here is an excerpt from the third posting:
QQQ
the reason some of the items on Robin's list are week in Leo is
because nobody uses them in Leo :-) For example, nobody cares about
typing completion for file names in Leo's minibuffer because @thin or
@button are far easier ways to open files.
For more than seven years how I have been responding to requests from
Leo's users. What has gotten done are what people have actually
wanted, and almost nothing else. I plan to continue this strategy.
OTOH, if Robin started using Leo and made requests, I would certainly
listen very carefully :-)
QQQ
Edward
--------------------------------------------------------------------
Edward K. Ream email: edre...@gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
edream
> This status report is very long: I'll just summarize it here.
gui plugin applies directly to Leo's wxWidgets gui plugin, because
most of the hard work with the native tree widget is done in a common
base class. I'd love to have a fully functioning wx gui plugin for
Leo.
At present, there is too much flash when fully redrawing the wx gui
tree. Perhaps there is a way, now, to buffer wxTreeCtrl drawing in a
way that didn't seem to exist back in the day...
EKR
Christopher Barker
Thanks for the update. As it happens, My personal I-need-this-in-an
editor list overlaps Robin's write a bit, so this post has re-ignited my
interest in Leo. I just went an poked at Leo's web site a bit, and did
not find the answer (quickly!) to these questions:
OS-X support?
- native-ish key bindings (for the biggies, anyway - cut, copy,
paste, etc.).
- Set up to run as a *.app -- drag and drop file son it, etc.
Language support: what kinds of text files are supported out of the box?
- C/ C++ ?
- LaTeX ?
- HTML/ XML ?
- CSV (or tab-delimited) ?
- plain old text, with spell checking and stuff like that.
Other questions:
Why so long with the interactive search -- that is THE FEATURE that I
NEED in an editor -- it is really remarkable how much more efficient it
is than having to decide how much a search term I need to type, and then
search for it!
Interesting about the wx front-end -- frankly, I don't think I care --
I'm a wx guy, but if I have a good editor, I can't really imagine I'd
need to be writing custom GUI code for it, so I don't really care what
toolkit it uses -- as long as it runs on all three platforms I need.
Python scripting I do want -- so I am looking for an editor scriptable
in Python
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
edream
> OS-X support?
> - native-ish key bindings (for the biggies, anyway - cut, copy,
leoSettings.leo doesn't necessarily give the OS-X bindings, but there
is a setting to switch, iirc, command and clover keys, which may be a
start.
> paste, etc.).
> - Set up to run as a *.app -- drag and drop file son it, etc.
> Language support: what kinds of text files are supported out of the box?
> - C/ C++ ?
> - LaTeX ?
> - HTML/ XML ?
> - CSV (or tab-delimited) ?
> - plain old text, with spell checking and stuff like that.
which is several dozen at least. See
http://webpages.charter.net/edreamleo/coloring.html
> Why so long with the interactive search -- that is THE FEATURE that I
> NEED in an editor -- it is really remarkable how much more efficient it
> is than having to decide how much a search term I need to type, and then
> search for it!
have isearch commands. At present they are limited to the present
node, but there is at least the start of cross-node matches. It's
hairy. This will be this weeks work.
The lack of isearch hasn't bothered me, but maybe I'm missing
something truly useful. OTOH, sometimes Leo's environment changes the
design point.
> Interesting about the wx front-end -- frankly, I don't think I care --
> I'm a wx guy, but if I have a good editor, I can't really imagine I'd
> need to be writing custom GUI code for it, so I don't really care what
> toolkit it uses -- as long as it runs on all three platforms I need.
gateway to eclipse. But maybe that's not such a great idea :-)
> Python scripting I do want -- so I am looking for an editor scriptable in Python.
Scripting is Leo's forte. See
@button: http://webpages.charter.net/edreamleo/scripting.html#creating-script-buttons
@test: http://webpages.charter.net/edreamleo/unitTesting.html
iLeo: http://webpages.charter.net/edreamleo/IPythonBridge.html
Edward
Bill Baxter
>
>> Why so long with the interactive search -- that is THE FEATURE that I
>> NEED in an editor -- it is really remarkable how much more efficient it
>> is than having to decide how much a search term I need to type, and then
>> search for it!
>
> Again, because none of Leo's power users has asked for it. Leo does
> have isearch commands. At present they are limited to the present
> node, but there is at least the start of cross-node matches. It's
> hairy. This will be this weeks work.
>
> The lack of isearch hasn't bothered me, but maybe I'm missing
> something truly useful. OTOH, sometimes Leo's environment changes the
> design point.
I use incremental search as basically my main means of navigating
through a large file of code. Basically when I want to go somewhere
in the code I try to recall a short, fairly uncommon string of letters
that was associated with that place. Like maybe I recall that I used
the word "inaccurate" in a comment in the function I'm looking for,
I'll just start searching for "inac" and since I already picked it to
be a not-so-common word, usually by the 4th or 5th character I've
arrived where I want to be. The word could also be a variable name or
part of the function name.
Re: leo fulfilling Robin's dream (a dream which I share)
[Disclaimer: my knowlege of Leo come only from going through a few of
the tutorials just now]
It seems to me that Leo kind of oversteps the bounds, going from being
an editor to being a different way to work. More like a text file
IDE. That's fine but I think (for better or worse) what most people
want something that is essentially just an editor. It seems Leo wants
me to turn every little editing task into some kind of
hierarchy-building exercise. I have to admit I've never liked any of
the "code folding" or "outline view" modes in any product I've ever
used. I don't find them even remotely compelling. I'd rather just
have things presented simply, with a good way to navigate around
(read, powerful search). It's kind of the same philosophy as you see
in Sherlock and other desktop search paradigms these days. I don't
want to spend time managing or navigating hierarchies. I just want to
be able to jump directly to what I need by typing a few letters. I'm
sure there are great benefits to the Leo approach but, not being a fan
of outlines, these things don't jump out at me.
I also really don't like the idea of my directories becoming littered
with .leo files all over the place. Or the idea of my files
themselves becoming littered with funky comments that only Leo
understands. I think that just won't fly in an environment where you
work on code with other people.
Looking forward to your response.
--bb
Ali Afshar
> I also really don't like the idea of my directories becoming littered
> with .leo files all over the place. Or the idea of my files
> themselves becoming littered with funky comments that only Leo
> understands. I think that just won't fly in an environment where you
> work on code with other people.
>
I would have to agree. I simply wouldn't use any tool that did either of
those things.
Can't all the .leo files live in one place per project project?
Ali
Edward K. Ream
> Why so long with the interactive search?
My apologies for not replying sooner. I didn't realize there were
replies: emails from this group were being sent to a dead address.
I added a much improved isearch to Leo last week. I forgot to mention
it here because for the last 5 days or so I have been obsessed with
improving the speed of Leo's colorizer. I've just pushed the new code
to Leo's trunk. It's a big improvement.
But I digress :-) Leo's new isearch command is built on Leo's well-
tested search code. This code handles a lot of extremely-complex
details. Realizing that isearch had to be use this code was the Aha
that makes the new isearch code reliable.
Please let me know how the new isearch commands work for you. It
should be easy to add features, but the commands work pretty much as
in Emacs.
In general, it is easier to add a feature to Leo than to explain why
Leo doesn't have it :-)
> Re: leo fulfilling Robin's dream (a dream which I share)
> the tutorials just now]
People who haven't used Leo typically misjudge what is important in
Leo. That's because Leo changes how people work. More about this in
the next section.
> It seems to me that Leo kind of oversteps the bounds, going from being
> an editor to being a different way to work. More like a text file
> IDE. That's fine but I think (for better or worse) what most people
> want something that is essentially just an editor.
essential statement of my first post:
To displace Emacs, an editor must offer much *more* than Emacs.
To say this another way, Robin's post makes no sense if all we want
is:
a) an Editor and
b) an Editor with all and only Emacs's features!
Do you see? Nobody in their right mind is going to spend years *just*
duplicating Emacs. Emacs is *already* an open source project.
> It seems Leo wants me to turn every little editing task into some kind of
> hierarchy-building exercise.
I. Leo provides a set of new tools, not available anywhere else, and
not even "conceivable" in Emacs. What you do with Leo is up to do.
You certainly do not have to create hierarchies if you don't want
them.
> I have to admit I've never liked any of the "code folding" or "outline view" modes in any product I've ever used. I don't find them even remotely compelling.
that they have no memory, so the outline gets in the way rather than
helps. Leo outlines have "state" in two senses. The first (small)
sense is that it remembers where you left off before. Even this
trivial memory is a big advance over typical class browsers.
The second (large) sense in which Leo has a memory is that Leo
remembers how *you* organized your data. And there is no single
"right way" for *you* to organize your data. You can embed
arbitrarily many of *your* views of the data into a single outline.
I think you will find that what you can do with Leo outlines goes way
beyond any kind of outline mode you have ever used. In particular,
you will find that nothing in Emacs comes close to matching what you
can do with Leo outlines.
So *of course* you don't see the value of Leo outlines. Yet.
> I'd rather just have things presented simply, with a good way to navigate around
> (read, powerful search).
rich dom (document object model). From a theoretical point of view,
Leo's dom is the essential difference between Leo and any other
editor.
> It's kind of the same philosophy as you see in Sherlock and other desktop search
> paradigms these days. I don't want to spend time managing or navigating hierarchies.
> I just want to be able to jump directly to what I need by typing a few letters.
> I'm sure there are great benefits to the Leo approach but, not being a fan
> of outlines, these things don't jump out at me.
> I also really don't like the idea of my directories becoming littered
> with .leo files all over the place.
directory as the files they manage, and a single .leo file can manage
arbitrarily many files.
> Or the idea of my files themselves becoming littered with funky comments that only Leo
> understands. I think that just won't fly in an environment where you
> work on code with other people.
sentinels (aka funky comments) are optional. There are many ways to
avoid sentinels, the two most interesting being @shadow and @auto
files.
@shadow is the brilliant creation of Bernhard Mulder, who, alas, died
before he saw his work come to full fruition. @shadow gives you *all*
of Leo's features, at the cost of creating duplicate "private" files
that do contain sentinels in an out-of-the-way .leo_shadow directory
(you can name it whatever you like).
@auto is another alternative. It allows you to "auto-import" any file
whatever into Leo, without the need for shadow files and directories.
There are some limitations with @auto, but they are not severe. @auto
was *specifically* designed to handle the typical concerns about Leo
being a "good citizen" in environments in which *no* change to source
code is tolerated.
> Looking forward to your response.
use Leo for more than a few minutes :-)
Edward
Edward K. Ream
> I would have to agree. I simply wouldn't use any tool that did either of
> those things.
designed specifically for you.
> Can't all the .leo files live in one place per project project?
Edward
Ali Afshar
Ali
Kent Tenney
I'm in the middle, sometimes I want 'chunking', sometimes 'slurping'
(slurp = @auto node where the body holds the entire file, no auto
hierarchalization.
I think Leo needs 3 things to minimize dissonance in the newcomer experience:
- @auto <file>
in place
- rock solid vim.py
I'm still having trouble
- chunk / slurp toggling in the core
'click here' to toggle between flat file and hierarchal experience.
Moving from vim* to Leo is then seamless, Leo manages your source files,
you drop into vim and back effortlessly, Leo doesn't impose chunking files,
but offers it.
Then a 5 minute screencast demoing this setup and showing the creation
of a few buttons ... the world will be Leo's oyster.
*your editor's name here
Thanks,
Kent
Edward K. Ream
On Feb 10, 8:44 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> It seems Leo wants me to turn every little editing task into some kind of
> hierarchy-building exercise.
the first-time ever, using Leo's nodes just like people typically use
Emacs buffers: one buffer per file.
Previously, the slow syntax coloring "encouraged" people to split
files into nodes. Now, there is less need to do that. If you like,
the outline would just be a list of open nodes. You could even hide
the outline completely. You could always do that before, but now
there is a plausible use case for doing so.
Edward
Josiah Carlson
[snip]
> I'm glad you said this, because it gives me a chance to repeat the
> essential statement of my first post:
>
> To displace Emacs, an editor must offer much *more* than Emacs.
>
> To say this another way, Robin's post makes no sense if all we want
> is:
>
> a) an Editor and
> b) an Editor with all and only Emacs's features!
>
> Do you see? Nobody in their right mind is going to spend years *just*
> duplicating Emacs. Emacs is *already* an open source project.
Over the years (and in particular since Scintilla was made available
in various programming languages via wrappers), I've seen a lot of
editors spring up with different features, designs, goals, etc. More
than a few of them state that one of their goals is to "replace X",
where X = Emacs, Vim, Eclipse, and any one of a number of other
editors, tools, etc.
Every editor has their unique features and designs that gives each one
of them an edge in one way or another. But not all of them can
replace Emacs ;) . Then again...I'm not sure that it really makes
sense to replace Emacs or Vim (WRT major functionalities); the
console-centric nature of both of them has invaded even their "GUI"
variants, and the various clones suffer (IMO) from the same
limitations that the original Emacs and Vim.
To really change programming, and really start replacing the "old
standards" without cloning them, I think, requires thinking
substantially different from what the mainstream has thought "right"
before. The browser in "Code Browser"
(http://code-browser.sourceforge.net/images/code-browser-pane.png) is
awesome, as is the general source navigation demo
(http://code-browser.sourceforge.net/demo.html). The multi-editing
capabilities of SubEthaEdit
(http://www.codingmonkeys.de/subethaedit/collaborate.html) blow me
away every time (I've been waiting for wxPython to wrap the
multi-indicator build of Scintilla for over a year so that I can
implement it myself :P ).
I do think that Leo does things differently from other editors that
came before and exist currently, so in that sense, *I* think that
Edward's doing a great job. The real question is whether Edward can
get people who write and love their own editors to drop them in favor
of Leo ;) .
Just my 2 cents.
- Josiah
Edward K. Ream
I do think that Leo does things differently from other editors that
came before and exist currently, so in that sense, *I* think that
Edward's doing a great job.
Thanks.
The real question is whether Edward can get people who write and love their own editors to drop them in favor of Leo ;)
I don't want people to drop their beloved tools. My "mission" is to have them add one more...
Edward
Bill Baxter
>
> On Feb 2, 8:11 pm, Bill Baxter <wbax...@gmail.com> wrote:
> Please let me know how the new isearch commands work for you. It
> should be easy to add features, but the commands work pretty much as
> in Emacs.
I'm not sure how to get a working copy of Leo's trunk. Do you put
snapshots anywhere?
> People who haven't used Leo typically misjudge what is important in
> Leo. That's because Leo changes how people work. More about this in
> the next section.
All these answers are encouraging. I think the issue I have now might
be like the one the poster below suggests. You have various tutorials
about the many advanced and unique features of Leo, but do you have a
basic tutorial anywhere explaining how you just open edit a file?
Like what M-x help-with-tutorial does in Emacs. I just fired up Leo
and got stuck on how to open a source file, when Open... seems to only
open .leo files.
>> It seems to me that Leo kind of oversteps the bounds, going from being
>> an editor to being a different way to work. More like a text file
>> IDE. That's fine but I think (for better or worse) what most people
>> want something that is essentially just an editor.
>
> I'm glad you said this, because it gives me a chance to repeat the
> essential statement of my first post:
>
> To displace Emacs, an editor must offer much *more* than Emacs.
>
> To say this another way, Robin's post makes no sense if all we want
> is:
>
> a) an Editor and
> b) an Editor with all and only Emacs's features!
>
> Do you see? Nobody in their right mind is going to spend years *just*
> duplicating Emacs. Emacs is *already* an open source project.
Well, there's Cody Precord, working on Editra. For some people,
having an Emacs-like editor that's not tied to Lisp is motivation
enough.
>> It seems Leo wants me to turn every little editing task into some kind of
>> hierarchy-building exercise.
>
> Leo doesn't "want" you to do anything in particular, and neither do
> I. Leo provides a set of new tools, not available anywhere else, and
> not even "conceivable" in Emacs. What you do with Leo is up to do.
> You certainly do not have to create hierarchies if you don't want
> them.
Sounds good, but some tutorials on how to use Leo to just go about
your business as usual would be helpful.
>> I have to admit I've never liked any of the "code folding" or "outline view" modes in any product I've ever used. I don't find them even remotely compelling.
>
> Again, I'm glad you said this. The problem with all other outliners is
> that they have no memory, so the outline gets in the way rather than
> helps. Leo outlines have "state" in two senses. The first (small)
> sense is that it remembers where you left off before. Even this
> trivial memory is a big advance over typical class browsers.
>
> The second (large) sense in which Leo has a memory is that Leo
> remembers how *you* organized your data. And there is no single
> "right way" for *you* to organize your data. You can embed
> arbitrarily many of *your* views of the data into a single outline.
>
> I think you will find that what you can do with Leo outlines goes way
> beyond any kind of outline mode you have ever used. In particular,
> you will find that nothing in Emacs comes close to matching what you
> can do with Leo outlines.
>
> So *of course* you don't see the value of Leo outlines. Yet.
>
>> I'd rather just have things presented simply, with a good way to navigate around
>> (read, powerful search).
>
> Leo has powerful search, but searching flat text does not give you a
> rich dom (document object model). From a theoretical point of view,
> Leo's dom is the essential difference between Leo and any other
> editor.
Ok, but it should degrade gracefully to a 1-node dom being equivalent
to "plain old text file", right? I think making this kind of thing
work transparently is pretty important to getting newbies to not
uninstall Leo the minute they find they can't open a text file. There
are dozens of editors out there that are happy to open a text file
with Ctrl-O and let you edit it. Leo seems to require something else
non-obvious for this simple task, so it makes the road unnecessarily
bumpy.
>> It's kind of the same philosophy as you see in Sherlock and other desktop search
>> paradigms these days. I don't want to spend time managing or navigating hierarchies.
>
> You might change your mind after you have tried Leo.
I think both can be useful. iTunes has both hierarchical organization
and fast search.
>> Looking forward to your response.
>
> And now you have it. I'm looking forward to your comments after you
> use Leo for more than a few minutes :-)
I'm now looking for the "Using leo as an editor" section of the
beginner's guide. There's a section on "using leo as an outliner"
right near the beginning, but no section about using leo as an editor.
What's the minimal number of steps required for an absolute newbie to
open up grocery-list.txt and add "milk"?
I think if you can soften the transition a bit from regular editor to
the leo way, you can probably convince a few more people. I think
this is probably what Kent Tenny is talking about with his slurping
@autos comment below, but I don't know what it means to slurp an @auto
well enough to be sure.
--bb
Kent Tenney
There are several ways Leo can be used to edit files.
they are nodes with headlines like:
@shadow myfile.txt
@nosent /etc/hosts
@thin leoCode.py
...
Each offers a compelling combination of features.
an @auto node
@auto launchpad/project/dvcscode.py
does not add any Leo 'sentinels' (comments which are Leo organizers)
to the file dvcscode.py
When Leo is opened it reads dvcscode.py and, by default, 'chunks' it
into nodes, a hierarchy of declarations, classes, methods, functions.
The term 'slurp' describes behaviour which would place the entire dvcscode.py
file into one node, thus presenting a traditional view of the file.
So, a slurped @auto is most like the editing experience folks are used to.
If the vim plugin is enabled, double clicking the node icon loads the contents
into vim: edit, save, exit, the node contents are changed.
So, slurped @auto with the vim plugin, very unobtrusively adds convenience
to the editing experience if you're a vimmer. (there's an iceberg
below this tip)
Thanks,
Kent
>
> --bb
>
Edward K. Ream
I'm not sure how to get a working copy of Leo's trunk. Do you put
snapshots anywhere?
Yes. http://www.greygreen.org/leo/
Your question illustrates why newbies are so important to Leo. I hadn't realized that there is no obvious link to this page. I'll put a link to it on Leo's home page and in Leo's FAQ.
However, if at all possible, I recommend using bzr to get the latest version of Leo. In the long run, this is much more convenient than getting snapshots. Furthermore, bzr is a superb tool, well worth learning in its own right. Leo has benefited greatly from bzr branches created by developers. And you will need to use bzr if you intend to extend Leo.
For instructions about bzr, see the first entry in Leo's FAQ:
http://webpages.charter.net/edreamleo/FAQ.html#how-do-i-use-bzr-to-get-the-latest-sources-from-leo-s-launchpad-site
All these answers are encouraging. I think the issue I have now might
be like the one the poster below suggests. You have various tutorials
about the many advanced and unique features of Leo, but do you have a
basic tutorial anywhere explaining how you just open edit a file?
Good point. Improving Leo's tutorial is becoming urgent.
I'd like to rewrite all of Leo's introductory docs using a "story-based" approach inspired by the book "Ideas that stick". Using Leo to "just open and edit a file" would be one of the very first stories.
> From a theoretical point of view, Leo's dom is the essential difference between Leo and any other editor.Ok, but it should degrade gracefully to a 1-node dom being equivalent
to "plain old text file", right? I think making this kind of thing
work transparently is pretty important to getting newbies to not
uninstall Leo the minute they find they can't open a text file. There
are dozens of editors out there that are happy to open a text file
with Ctrl-O and let you edit it. Leo seems to require something else
non-obvious for this simple task, so it makes the road unnecessarily
bumpy.
Thanks for this comment. Until you made it, I had a blind spot regarding this.
There is actually a way to get Leo to open a plain file in a wrapper .leo file, but I don't remember what it is and there is no way a newbie is going to stumble upon it.
This is more than a mere doc bug. As you say, ctrl-o on a plain file should work.
So we have a good collaboration going already. You've highlighted several things that will confuse newbies.
I think if you can soften the transition a bit from regular editor to
the leo way, you can probably convince a few more people.
I agree completely. I'll see what I can do in the next three days...
Edward
Bill Baxter
>
>
> On Tue, Feb 10, 2009 at 3:33 PM, Bill Baxter <wba...@gmail.com> wrote:
>>
>> I'm not sure how to get a working copy of Leo's trunk. Do you put
>> snapshots anywhere?
>
> Yes. http://www.greygreen.org/leo/
Thanks. That's only so much help, though, when I'm still stuck on how
to open a file. :-)
> Your question illustrates why newbies are so important to Leo. I hadn't
> realized that there is no obvious link to this page. I'll put a link to it
> on Leo's home page and in Leo's FAQ.
>
> However, if at all possible, I recommend using bzr to get the latest version
> of Leo. In the long run, this is much more convenient than getting
> snapshots. Furthermore, bzr is a superb tool, well worth learning in its
> own right. Leo has benefited greatly from bzr branches created by
> developers. And you will need to use bzr if you intend to extend Leo.
>
> For instructions about bzr, see the first entry in Leo's FAQ:
>
> http://webpages.charter.net/edreamleo/FAQ.html#how-do-i-use-bzr-to-get-the-latest-sources-from-leo-s-launchpad-site
Thanks for the link. I'm using mercurial regularly and I hear it's
pretty much the same thing as bzr. And since there seems to be no
clear winner in the fight to become the world's dominant dvcs, I might
as well have bzr handy too.
>> All these answers are encouraging. I think the issue I have now might
>> be like the one the poster below suggests. You have various tutorials
>> about the many advanced and unique features of Leo, but do you have a
>> basic tutorial anywhere explaining how you just open edit a file?
>
> Good point. Improving Leo's tutorial is becoming urgent.
>
> I'd like to rewrite all of Leo's introductory docs using a "story-based"
> approach inspired by the book "Ideas that stick". Using Leo to "just open
> and edit a file" would be one of the very first stories.
Don't know that book, but the idea sounds good.
> So we have a good collaboration going already. You've highlighted several
> things that will confuse newbies.
I'm glad that you're taking these comments as constructive criticisms
rather than getting defensive about it.
>> I think if you can soften the transition a bit from regular editor to
>> the leo way, you can probably convince a few more people.
>
> I agree completely. I'll see what I can do in the next three days...
Great. I have some old code (that I wrote once upon a time) that I'll
be going through soon, and it seems like an ideal chance to put leo's
annotation skills to the test.
--bb
Edward K. Ream
On Feb 10, 8:02 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
>> I'm not sure how to get a working copy of Leo's trunk. Do you put
>> snapshots anywhere?
> Your question illustrates why newbies are so important to Leo. I hadn't
> realized that there is no obvious link to this page. I'll put a link to it
> on Leo's home page and in Leo's FAQ.
http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-get-recent-bzr-snapshots-of-leo
That's one "3-day bug" fixed.
At present I am working on several other such 3-day bugs:
- There are some problems with the qt colorizer for large files.
Yesterdays work fixed some storage allocation problems that could
bring down the gc. Today's work will get Leo's @killcolor and @nocolor
directives working again. This will allow you to bypass colorizing
completely, say for large log files.
- Despite what recent journal entries say, Leo doesn't have support
for opening plain (non-.leo) files in a node using ctrl-o. I'd like to
do this today.
- I shall soon add an "experimental" documentation section to Leo's
wiki. This will get the "new documentation" project started without
harming the existing docs.
At present, these seem like the biggest issues for Leo's newbies. Let
me know if there are any other urgent bugs that need attending to.
Edward
Edward K. Ream
> At present I am working on several other such 3-day bugs:
> for opening plain (non-.leo) files in a node using ctrl-o. I'd like to
> do this today.
remained invisible for so long. Naturally, the first thing many
people would do is try to use Leo like a normal editor. Now they can.
Various people have already suggested some "Leonine" improvements:
http://groups.google.com/group/leo-editor/browse_thread/thread/573d0a4311c7daaf
The work was completed several hours ago. I had hoped to be able to
report that all coloring issues had been fixed, but more work
remains. Still the present colorizing is easily 100 times faster than
previous versions for moderately-sized files. For now, I'd limit
files that get "slurped" into Leo to 5,000 lines or less.
Edward
Christopher Barker
First:
It mostly works, which is a real testament to Python and tkInter
--pretty cool!
>> OS-X support?
>> - native-ish key bindings (for the biggies, anyway - cut, copy,
>
> You can choose bindings as you wish in myLeoSettings.leo.
I'll have to mess with that, but out of the box, only ctrl works. Even
though there are bindings listed in the menus for alt and alt+shift,
they don't work.
I'm surprised that TK didn't make more of of them work by default -- oh
well.
>> - Set up to run as a *.app -- drag and drop file son it, etc.
>
> OS-X support isn't the best.
It wouldn't be too hard to add that if I (or someone else with a Mac )
choose to -- and there are also some layout issues it would be nice to
fix -- buttons too close together, etc.
>> Language support: what kinds of text files are supported out of the box?
> Leo supports syntax coloring for all languages supported by jEdit,
Good start -- but syntax coloring is only a start. Is there any other
support?
>> Why so long with the interactive search --
You've go that now, but it either is broken, or there was a
misunderstanding of what it means -- it seems to just search one letter
-- that's not what we (or at least, I) want. We want to be able to type
s many letters as we need to get to what we're looking for:
type a "t" get the first "t", then type an "h", get the first "th", type
an "e", get the first "the", etc...
In the middle of that, you should be able to type <enter> or the
I-search keystroke and get the next occurrence of that string.
Firefox has a pretty good one, if you want an example.
Other notes:
I could easily just open a file -- no problem there any more.
Indenting:
Almost no editors get this right. It's critical for Python, but good to
have for any programming language. (X)Emacs gets it right, and Peppy
gets it right -- those are the only two I know of. Here's what I mean by
"right"
* The <tab> key means "indent this line as it should be"
- if you are at the beginning of a blank the line, it puts the cursor
at the right indent level, whatever that is.
- if you are in the middle of the line, it indents that line to where
it should be
* if the <backspace> key is pressed in the indentation space, it means:
reduce the indentation level by one.
Whether an indentation level is a tab or n spaces should be set-able
depending on the type of file and/or personal preference.
There is one trick for Python: there are often multiple indentation
levels that are "right", depending on what the programmer wants:
if something:
some code
if SomethingElse:
some more code
so, what is the "right" indentation level for the next line? Peppy, and
I'm pretty sure emacs, would put it two levels in. If you don't want
that, you hit <backspace> once or twice as need be.
I find this method works very well, and I'm amazed by how much I miss it
when I use any other editor.
Edward K. Ream
I got the latest Leo from bzr, and tried it out on OS-X
Excellent. Does the qt gui work?
I'll have to mess with that, but out of the box, only ctrl works. Even though there are bindings listed in the menus for alt and alt+shift, they don't work.
The bindings work on Ubuntu and Windows, but not necessarily on MacOS because of different key names and usages. Have you tried setting:
@bool swap_mac_keys = True
The comment in the node says:
True (legacy): Translate control-only keys to command keys on the Mac.
False (recommended): No translation.
I'm surprised that TK didn't make more of of them work by default -- oh well.
This is only indirectly a Tk problem. Leo can not determine, from the key event itself, what key caused the event(!) This is a giant hole in the Tk api, but nobody in the Tk world seems to care.
As a result, Leo must create a separate binding for *all* keys that have a entry in an @settings node. So any bindings issues are due to settings in @shortcuts nodes.
I'll be happy to add a node/tree for Mac-centric bindings if you contribute it.
syntax coloring is only a start. Is there any other support?
What support would you like?
You've go [isearch] now, but it either is broken, or there was a misunderstanding of what it means
It works using the qt gui. There are focus problems with the tk gui that cause the minibuffer to reset to a single character. I had forgotten about this in the recent flurry of activity. I'll declare this a 3-day bug.
Almost no editors get [indenting] right.
Debatable. I prefer the present way with auto-indent following a colon.
We never argue about preferences in Leo, so I'll add the operation you describe as option. Another 3-day bug.
Whether an indentation level is a tab or n spaces should be set-able depending on the type of file and/or personal preference.
It is.
@tabwidth 8 # hard tabs, 8 characters wide.
@tabwidth -4 # tab with 4 spaces.
There doesn't seem to be a setting that sets default tab width. It appears hard-code at -4. It would be trivial to add such a setting if its lack bothers you.
Edward
Christopher Barker
> Excellent. Does the qt gui work?
I have no idea -- I've never used PyQT.
> The bindings work on Ubuntu and Windows, but not necessarily on MacOS
> because of different key names and usages. Have you tried setting:
>
> @bool swap_mac_keys = True
OK I've tried this, and it works OK.
However, to do it, I went to the help menu, and selected "Open
LeoSetting.leo"
which gave me a nice tree of settings, but I couldn't find
"swap_mac_keys". I poked around, and didn't find it, I did a search for
"swap" and didn't find it. In fact, what I did do is open the file in
another editor, search for "swap", change it save it and re-start leo.
I don't know if that's 'cause i just don't know how to use leo -- but
it's really making think that this is a major leap from plain old text
file editing!
> I'll be happy to add a node/tree for Mac-centric bindings if you
> contribute it.
we'll see -- I need to convince my self that this outlining way of
working is worth it...But it's nice to know that Mac support is probably
only as far away as a Mac user willing to help a bit.
> syntax coloring is only a start. Is there any other support?
>
> What support would you like?
well, at least good indenting, etc, and hopefully a way to runt eh code,
or built it or whatever. Also assorted shortcuts, I write LaTeX a fair
bit, and it's nice to have help with that.
> It works using the qt gui. There are focus problems with the tk gui
> that cause the minibuffer to reset to a single character. I had
> forgotten about this in the recent flurry of activity. I'll declare
> this a 3-day bug.
fair enough.
> Almost no editors get [indenting] right.
>
>
> Debatable. I prefer the present way with auto-indent following a colon.
Have you ever tried it the way I suggest? Probably not -- not many
editors do it.
> We never argue about preferences in Leo, so I'll add the operation you
> describe as option. Another 3-day bug.
Give it a try then, I think you'll be surprised at how much nicer it is!
> Whether an indentation level is a tab or n spaces should be set-able
> depending on the type of file and/or personal preference.
>
>
> It is.
>
> @tabwidth 8 # hard tabs, 8 characters wide.
> @tabwidth -4 # tab with 4 spaces.
that looks to be leo-wide -- what if you want different setting for
different kinds of files? That's another emacs-ism I really like -- the
idea of major-modes and minor modes. Major modes, in particular make it
easy to have the editor behave quite differently depending on what kind
of file you are editing.
> There doesn't seem to be a setting that sets default tab width. It
> appears hard-code at -4.
So what does @tabwidth set?
By the way, a couple TK on OS_C notes:
moving the sashes between windows is really "flashy" -- a bit hard to
describe.
The tree is all messed up while scrolling.
Also, some weirdnesses with line numbers. I'm editing a python file.
There is a syntax error on a line.
In the editing window, it's line 21
when I run it from leo, the error is reported as being at line 24
when I run it from the command line, it's reported as line 19
This is all quite confusing.
One other thing, for a newbie:
I opened a python file, edited it, saved it, and now I have no idea how
to get the edited version! It saved a workbook.leo file, but didn't
touch the python file.
It seems you can't quite use leo as "just a text editor" out of the box.
Still on the fence here.....
Bill Baxter
<Chris....@noaa.gov> wrote:
> It seems you can't quite use leo as "just a text editor" out of the box.
>
> Still on the fence here.....
Just out of curiosity -- Edward and any other Leo users out there. Do
you actually use Leo for small editing tasks like Christopher
described? Say you need to edit your bazaar.conf file, a simple .ini
file with two lines in it. Is Leo the tool you reach for in that
case? Or do you keep another more basic editor on hand for those
things. Emacs is generally my first choice, even for tiny edits like
that.
--bb
Kent Tenney
>
> On Sat, Feb 14, 2009 at 9:24 AM, Christopher Barker
> <Chris....@noaa.gov> wrote:
>> It seems you can't quite use leo as "just a text editor" out of the box.
>>
>> Still on the fence here.....
>
> Just out of curiosity -- Edward and any other Leo users out there. Do
> you actually use Leo for small editing tasks like Christopher
> described? Say you need to edit your bazaar.conf file, a simple .ini
> file with two lines in it. Is Leo the tool you reach for in that
> case?
I don't 'reach for' Leo, I 'work from' Leo
I open a Leo file which organizes my stuff
~/work/project/start.leo
(the Leo standard is a file named ~/.leo/workbook.leo)
bazaar.conf is available as
@auto ~/.bazaar/bazaar.conf
which is a child of a top level node named 'configure'
which aggregates configuration files::
configure
@auto ~/bazaar/.bazaar.conf
@auto conf.py
@auto ~/.bashrc
@auto ~/.bzrignore
...
editing the contents of an @auto node and saving the .leo file
changes the file on the filesystem.
> Or do you keep another more basic editor on hand for those
> things.
I'll sometimes double click the @auto node and edit in Vim,
for a small file I'll edit in Leo, but to
do any extensive search/replace stuff I prefer Vim.
Thanks,
Kent
Edward K. Ream
On Feb 13, 6:24 pm, Christopher Barker <Chris.Bar...@noaa.gov> wrote:
My apologies for the delay in replying. Somehow I thought that this
group was unavailable yesterday.
Before I start with detailed responses, I'd like to ask that further
discussion happen on the leo-editor group. That way all of Leo's
users will get the benefits of our discussion. They often have ideas
and techniques that never occurred to me.
> ...I couldn't find "swap_mac_keys".
I just checked that this works in the tk gui. My guess is that you
did a word-only search, or a search that did not include headlines.
Here is the typical search sequence:
1. [Optional, when using wrap-around search] Select the tree at which
you want to commence your search. This would have been the @settings
node.
2. Ctrl-f brings up the find panel. Look at the settings. The Alt-
Ctrl bindings correspond to the accelerators (underlines) on the
panel:
Alt-Ctrl-w toggles the whole word setting
Alt-Ctrl-S toggle the wrap around setting, etc.
3. Type the search string in the minibuffer, and hit <return> to start
the search or Shift-Ctrl-R to enter a replacement string, then
<return>
In particular, you want to be sure to search headlines, because
settings are specified in headlines.
> it's nice to know that Mac support is probably
> only as far away as a Mac user willing to help a bit.
> well, at least good indenting
Indenting python has been good for a long time. More below.
> Also assorted shortcuts, I write LaTeX a fair
like bindings if you like. And you can bind any shortcut to any of
*your own* commands using @button or @command nodes.
For example, try this:
@button Print Hi @key = Alt-6 (the headline)
print 'hi' (the body pane)
You can click the script-button button (or do alt-x
script<tab><return>) to create the script button. (This will be done
automatically for you the next time you load the .leo file) The
@button nodes creates a command called print-hi. So alt-x print-hi
will execute the code.
> a way to run the code, or built it or whatever.
I discussed @command and @button in detail above because they show how
you can create your own special-purpose mechanisms to do *anything you
want*. These scripts can be in one place or scattered over
several .leo files, and they can have whatever key bindings you like.
Ctrl-b runs the Python code in any node. There are many ways to run
code in other processes. If you like, we can start a discussion of
this on the leo-editor site. It should be possible to write a 10-line
Python script that runs just about anything, and putting that script
in a common @command node in myLeoSettings.leo make that script (and
its key binding)
available everywhere.
> Almost no editors get [indenting] right.
when hard tabs are used. That's now been fixed.
> > Here's what I mean by "right"
> > * The <tab> key means "indent this line as it should be"
> > - if you are at the beginning of a blank the line,
I added this feature yesterday. In practice, this case almost never
happens, because Leo auto-indents python properly, increasing the
indentation when a line ends in a colon.
> > if you are in the middle of the line, it indents that line to where
I would hate this feature, and with the present indenting scheme it
never seems necessary. I want tabs to produce indentation everywhere.
However, this feature could be supported as a user option. We would
then need (say) an insert-tab command (with binding, of course) to
override the auto-indentation of the entire line.
> > * if the <backspace> key is pressed in the indentation space, it means:
reduce the indentation level by one.
There are several Leo settings that control indentation. A case could
be made for Leo *directives* that control fine details of
indentation. Certainly, this is not needed for Python.
> > Whether an indentation level is a tab or n spaces should be set-able
depending on the type of file and/or personal preference.
> > @tabwidth 8 # hard tabs, 8 characters wide.
> > @tabwidth -4 # tab with 4 spaces.
No. These are Leo *directives* that go in body text (or headlines).
It's good style to put them in the root @file or @thin or @auto or
@shadow node that corresponds to the external file.
Yesterday I added the @int tab_width = -4 *setting*. Nobody noticed
its lack, I think, but there is no harm in adding it.
> what if you want different setting for different kinds of files?
extensions. I suppose there could be, but it hardly matters.
> idea of major-modes and minor modes. Major modes, in particular make it
> easy to have the editor behave quite differently depending on what kind
> of file you are editing.
> > There doesn't seem to be a setting that sets default tab width. It
> > appears hard-code at -4.
@int tab_width = 8 # Use tabs for spacing (shown as 8 spaces)
@int tab_width = -4 # Use four spaces for spacing.
> So what does @tabwidth set?
ridden by another @tabwidth in a descendant node.
This doesn't appear to be clearly explained in the introductory
material. I'll fix this soon.
> In the editing window, it's line 21
> when I run it from leo, the error is reported as being at line 24
> when I run it from the command line, it's reported as line 19
the actual value is. Do alt-g <Leo's line number> return to go to the
proper line.
> I opened a python file, edited it, saved it, and now I have no idea how
> to get the edited version! It saved a workbook.leo file, but didn't
> touch the python file.
the file system. Otherwise, your work is in notebook.leo.
> It seems you can't quite use leo as "just a text editor" out of the box.
Maybe there should be a command that writes the nodes contents back to
the file from which it came.
We might need a new directive, say @open-path. Ctrl-O would insert
this directive, write-node-to-file would use this directive to write
the file back. But I'm uneasy about this. It's more of a hack than a
feature, and it could cause nasty surprises when moving the .leo file
to another machine.
In short, for quick editing a more typical editor might be more
suitable. I often use scite in such cases.
But Kent's suggestion is really best. For files that you want to edit
more than once (and isn't that really *every* file?), using @auto does
the job more easily than emacs. You can organize your @auto nodes to
make them easily accessible. You could even write a script to create
an @auto node from the node created by Ctrl-O. Etc.
> Still on the fence here.....
Again, I hope we'll continue this discussion on leo-editor. It
continues to be fruitful and enjoyable.
Edward
Edward K. Ream
A short status report. It's been 12 days since my last report, and
several of the "3-day bugs" remain. I've declared a "quiet time" for
myself so I can dedicate myself to fixing these bugs. I had to declare
a quiet time because I have been overwhelmed by interesting
discussions about extending Leo's capabilities :-)
Some progress:
- Leo's File:Open (open-file) command now generates @edit nodes. This
plugs a huge, previously-unseen, hole that made it much harder than it
should have been to work with non-Leo files, which for most people is
all their files :-) Preliminary docs at:
http://groups.google.com/group/leo-editor/browse_thread/thread/813947381aaee2bb
- A revised introduction to Leo is at http://leo.zwiki.org/LeoStories
I plan to finish the intro this week. This can be finished now that
@edit is in place.
Nothing has happened on the following bugs. I plan to fix them all
within one week.
- Incremental search when using the tk plugin.
- Problems with syntax coloring when using the qt plugin.
- Several other problems with the qt plugin. Most rare, but some
serious.
To repeat, if you are interested in using Leo and are having troubles,
please ask for help on leo-editor,
http://groups.google.com/group/leo-editor
Edward
Edward K. Ream
file. From then on, opening the .leo file containing the @edit node
will automatically read the file.
Also, the latest Leo trunk now contains a fully functional incremental
search. By default, Alt-S starts the incremental search, Alt-R starts
a backward incremental search. To repeat the search, do Alt-S or Alt-
R again. isearch now works with both tk and qt gui plugins.
Edward
P.S. A bit more progress has been made on the new intro at:
http://leo.zwiki.org/IntroductionToLeo
EKR