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. 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
