On Mon, Jun 9, 2014 at 3:38 PM, 'Terry Brown' via leo-editor <[email protected]> wrote: > On Mon, 9 Jun 2014 11:36:06 -0700 (PDT) > [email protected] wrote: > >> Although I am not one of the developers, I think it's not out of >> place if I suggest that it's about time we start focusing on planning >> the next release, which as I understand would be v5.0. >> In fact, it would be nice to start laying down a tentative roadmap >> for the 5.x series of releases, so the developers can discuss the >> priorities, and better focus on them. > > Great idea and thanks for taking the initiative. > > One item to consider - supporting PyQt5. Not really sure how much work > or benefit is involved, but eventually PyQt4 will be a legacy thing, > even though I'm sure it will be around for many years to come.
In my mind, the 5.x label refers to a release containing fundamentally important new capabilities for Leo: 1. The now-abandoned @auto improvements, had they been successful, would have qualified. That was intended to eliminate the need for sentinels in most external files. 2. Perhaps really good "instant" introspection features, of which leoSTC.py might be a prototype, would also qualify. Such features would provide a framework for rapid-navigation features as in PyCharm. 3. Better vim-like emulation might also qualify. Looking over the (huge) to-do list, nothing else seems to qualify. The following seem like the most important items on a 4.12 list: - A reload-settings command, so that one doesn't have to reload Leo in order to test changes to settings. This involves major behind-the-scenes complications. - Supporting PyQt5. My guess is that this is a relatively easy project. - Better support for viewrendered plugins and more/simpler(!) options for the rst3 command will *always* be important. These are the main ways in which people can use Leo to create html and other output. Finally, there is gnawing feeling that I am missing ways to simplify/improve/re-imagine clones, Leo's defining (and most problematic) feature. Two, no three, examples: 1. I recently realized that clones often clutter searches. True, the clone-find-all/-flattened commands ignore duplicates, but duplicates are annoying otherwise. (And yes, there are easy workarounds.) 2. PyCharm has laid down an excellent challenge. Is it really true that having outline structure always visible is a good thing? Is it really true that being able to define the *exact* contents of nodes really necessary? I think the answers to both questions is "yes", and yet, I can't help thinking I am missing something. 3. The organization of documents using clones seems like it should suffice, but in practice it doesn't. That is, the *same* (cloned) content must, in practice, be treated differently depending on context, say in code context versus documentation context. The @doc options for the rst3 command were supposed to be a cool solution, but actually, they just create almost impossible-to-understand complications. Let me clear. If we are to have true control over the content of nodes, then sentinels are *inevitable* Otoh, the workflow associated with nodes could conceivably change. Fundamentally, imo, clones are about workflow, and secondarily about alternative views of data. But we must make sure that any change retains the ability for scripts to access all outline data using Leo's profoundly simple api. In short, it is a tall order to make fundamental changes to Leo while retaining *all* of its strengths. This kind of grand challenge is what I am primarily thinking about for Leo 5.0 Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
