Hi,
El 02/08/10 12:26, Edward K. Ream escribió:
On Mon, Aug 2, 2010 at 12:09 PM, thyrsus<[email protected]> wrote:
The important information is ONLY in the Leo file.
This point of view is reasonable. For instance, you might not want
any external files at all.
Let us adopt your point of view for the moment...
Leo's compare-leo-files command compares two outlines created by the
.leo files. Diffing Leo outlines (rather than the xml that generates
them) is a snap because every node has a gnx! Thus, discovering
inserted and deleted nodes is trivial, and diffing changed nodes is
just a matter of comparing headline and body text.
However, the problem of understanding the diffs still remains. It's a
human interface problem.
The present compare-leo-files code creates nodes describing inserted,
deleted and changed nodes. The problem with this approach is that the
diffs are not presented in the full outline context. I'll be
interested in any improvements you might devise.
I have imagined a scenario where two persons work on Leo in the same
project and they want to reconcile their personal views of the project
to work together and create a shared view of it. This is the workflow I
imagine with the human interface problem represented in Leo.:
* Jose sends a Leo file to Lucia.
* Lucia opens the file in Leo and starts to change it creating new
outlines, clones and and so on and sends back to Jose (for now it
doesn't matter how is send).
* Jose reopens the Leo file or update his own and he can see marks in
the nodes that have been changed or added. This is done showing two
trees side by side: Lucia's tree and Jose's tree. The node changed are
marked by a icon and/or color convention. When there is addition he just
see the new node header in another color (the one that represents
Lucia's color), when a node has been changed a mark shows this and Jose
starts to navigate his tree jumping from changed/new nodes from his tree
and seeing the correspondent Lucia's tree nodes. A button let him to
integrate the changes proposed by Lucia to a unified tree. Each tree
shows its own body pane below them, so Jose can also zoom in into the
code besides the structure.
Details need to be thought because the previous scenario presumes
asynchronous editing on the Leo file, but having almost zero experience
on (D)VCS is my first view on how this human interface problem about
what basic feature is missing from Leo: A way to not only create
personal views of projects from Leo, but also to create shared views for
people that is using Leo to work together.
Cheers,
Offray
Ps: integration with a database that helps the Leo tree to carry-share
his non-textual files is also important, but this is another less
fundamental matter. For me Leo is a way to think/unify the computing
experience, to create discourse about it, that uses DAG for express and
build that discourse and can go beyond text.
--
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.
