In the last several days something very good has happened: the SciTe
text editor has become a model for a particular mode of Leo's
operation, namely::
leo x.y
where y is not ".leo". This post explores the implications for further
designs.
The goals of Leo and SciTe overlap in significant ways. But that's
not the point.
Rather, I want to discuss here how having this model *instantly*
resolves many design questions. Terry's recent post pointed out that
leo x.y did not work like scite x.y works, and that was *almost*
enough to discover how leo x.y *should* work.
Yesterday, I made leo x.y work like scite x.y, *provided* that x.y
exists. Today, I realized that leo x.y *doesn't* work like scite x.y
when x.y doesn't exist. So part of this evening's work will be to
make sure that leo x.y *does* work like scite x.y when x.y doesn't
exist :-)
It's as simple as that. And *that* is the value of having SciTe be a
model for Leo.
To be clear: the goal is not to have Leo do everything can be done in
Blender, or Mathematica, or whatever. Instead, the first goal is to
make **what Leo already does** work as well or better than in any
other program. Some examples:
- Leo's autocompleter should work as well as IPython's, when possible.
- Leo's shell (external process, bridge code) should work as well as
in emacs or IPython.
- Leo's rst3 command should support section references at least as
well as the old rst2 plugin did.
A second goal will be to *extend* what Leo does into areas **naturally
related to Leo** in ways that emulate other programs.
Recent "blue sky" discussions are, imo, primarily aimed in this
direction.
As an example, it appears to me that a client/server model might
liberate Leo in certain ways. One could imagine, for example, a
**clone server** that might, just might, allow cross-file clones. See
the Post Script for a few more details.
As another example, I am starting to chafe under the qttabs gui.
That is, suppose a single outline pane contained:
- @leo leoPy.leo
- @leo leoPlugins.leo
- @leo LeoDocs.leo
etc.
Cross-file searches instantly become easier. This format invites
cross-file clones.
True, there are some big internal complications, but I suspect they
can be handled...
There are also user interface considerations. There would be no
"containing" .leo file, so presumably only @leo nodes would be legal
at the top. But perhaps a client/server model could fudge an
anonymous, *persistent* container...
Just some thoughts.
Edward
P.S. A client/server model *might* create a breakthrough in
*persistent*, *reliable* bookmarks that somehow would allow cross-file
clones or, equivalently, clones attached to @auto nodes.
Everything is vague, but one idea is that we don't care, in this
context, how long gnx's are: they can contain sha hashes of files,
timestamps, other descriptions, whatever, so long as they can
associate a unique place in a unique *version* of some file.
P.P.S. Not everything interesting is text, but enough interesting
things *are* text that Leo's unique text organization capabilities
invite us to invent more general, powerful ways of using text and
templating. This is why projects such as CWEB, LaTeX, rst3, templates
engines, wikis, web site managers, etc, etc. are within Leo's purview.
In other words, we have not yet begun to explore the possibilities of
the Leonine world.
EKR
--
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.
