On Feb 2, 8:41 am, "Edward K. Ream" <[email protected]> wrote:
> This thread will discuss Robin Dunn's post, "Your mission, should you > choose to accept it". I'll be discussion how Leo complies with > Robin's checklist, and how Leo goes beyond it. In this "reply" I'd like to discuss some issues that aren't covered in Robin's post. You could call these the dogs that aren't barking. I'll link to this post from pyxides as a kind of progress report for Robin. 1. First, and most importantly, for an editor to displace Emacs, it is not *nearly* good enough simply to meet all the conditions of Robin's checklist. If all you want is the checklist, then why not just use Emacs? No. If Leo (or any other editor) is to displace Emacs, it must be much *better* than Emacs at one or more essential tasks. Without any doubt whatever, Leo meets this requirement. Leo's dom (document object model) is something that Emacs lacks. Leo's nodes have rich, true structure. Emacs buffers have no inherently relationship with other buffers. This is a crucial, *huge* difference between Emacs and Leo. Furthermore, Leo is easily scriptable (in Python) in ways that Emacs users can only dream about. You want the currently selected node? It's c.p. You want the body text of that node? It's c.p.b. Want to set the headline text of a node p? p.h = s. Etc. etc. etc. @button and @test are two features that in essence can not even be "thought" in Emacs. These features depend on the intimate connection between nodes (outline structure) and scripting. These features are not conceivable in Emacs. Oh sure, one could create some kind of kludgy simulation in Emacs, but that would be like simulating Python in machine language. It isn't going to be a good foundation for breakthroughs in programming. Leo is that foundation. 2. Second, Leo already has very good integration with both Emacs (XEmacs) and vim. So *even if* Leo lacks some esoteric Emacs feature, it is easy to drop into Emacs to do something, and come right back to Leo. 3. Third, the reason some of the items on Robin's list are week in Leo is because nobody uses them in Leo :-) For example, nobody cares about typing completion for file names in Leo's minibuffer because @thin or @button are far easier ways to open files. For more than seven years how I have been responding to requests from Leo's users. What has gotten done are what people have actually wanted, and almost nothing else. I plan to continue this strategy. OTOH, if Robin started using Leo and made requests, I would certainly listen very carefully :-) 4. There *are* a few features on Robin's list that need some more work. These include incremental search and a few emacs-like commands that only work when using the tk gui. I plan to work on these this week. Also, more work is planned on auto-completion later this year. 5. There are at least two other areas in which Leo is moving far beyond Emacs. - Leo's core can support multiple gui's. Leo started out being tk- centric. Leo now can choose between either tk and Qt for its look and feel. A swing (jython) version of Leo may happen this year. - Leo can support either Emacs-style key bindings or vim-like key bindings. Several of Leo's users are "native" vim users, and they have improved Leo's vim-like capabilities immensely. More work is planned in this area later this year. In short, a case can be made that Leo already meets Robin's essential requirements. I'll be working on a few loose ends this week, but they are nits. For several years now, Leo has moved far beyond Emacs in essential capabilities. Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
