On Wed, Feb 11, 2009 at 8:44 AM, Edward K. Ream <[email protected]> wrote: > > On Feb 2, 8:11 pm, Bill Baxter <[email protected]> wrote: > >> 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) >> [Disclaimer: my knowledge of Leo come only from going through a few of >> 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. > > 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. > >> 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. > >> 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'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 > > 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. > >> 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 just want to be able to jump directly to what I need by typing a few >> letters. > > And now you can. > >> 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. > > Of course not. How could they "jump out at you" until you use Leo? > >> I also really don't like the idea of my directories becoming littered >> with .leo files all over the place. > > There's no need for that: .leo files don't have to be in the same > 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. > > Leo does not require you to change you source files in any way. Leo's > 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. > > And now you have it. I'm looking forward to your comments after you > use Leo for more than a few minutes :-) > > Edward
