On Wed, Feb 11, 2009 at 3:33 PM, Bill Baxter <[email protected]> wrote: > > On Tue, Feb 10, 2009 at 11:44 PM, Edward K. Ream <[email protected]> wrote: >> >> On Feb 2, 8:11 pm, Bill Baxter <[email protected]> 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.
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 >
