Re: Readability and formatting of Plugins information
Thanks - Leo users will benefit from the 'polish' Lewis On Jun 21, 3:29 am, "Edward K. Ream" wrote: > On Jun 17, 12:17 am, lewis wrote: > > > Can I suggest the documentation be updated > > athttp://webpages.charter.net/edreamleo/plugins.html > > to say that docutils is recommended/requirement if viewrendered is > > active? > > Also update the about viewrendered text with the same information. > > Both done on the web and in the trunk. > > Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
About the find panel
Recently, perhaps it was today, there was a remark made about Leo's Find panel being confusing for newbies. I have some sympathy for the remarks. 1. Looking at Leo's Edit:Find menu, there is no obvious way of doing a search/replace operation. I'll fix this soon after 4.9 final. 2. The Find tab should make it clearer that it is a summary/status tab only--not a way of actually initiating or continuing searches. Perhaps using QLabel widgets instead of (disabled) QTextEdit widgets for the find/change patterns would help a bit. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Jun 20, 7:51 am, "Ville M. Vainio" wrote: > I would hesitate to put emacs and vim to same line w/ visual studio > and eclipse. The expectations from users are entirely different. True, but the cure for their disease is the same :-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Readability and formatting of Plugins information
On Jun 17, 12:17 am, lewis wrote: > Can I suggest the documentation be updated > athttp://webpages.charter.net/edreamleo/plugins.html > to say that docutils is recommended/requirement if viewrendered is > active? > Also update the about viewrendered text with the same information. Both done on the web and in the trunk. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Mon, Jun 20, 2011 at 9:43 AM, Gregory Crosswhite wrote: >> You're right! This was a blind spot. The fix is on the trunk at rev >> 4406. Tested on MacOS and Windows 7. The new code contains only one >> special case for MacOS: the gui defaults to qt instead of qttabs. > Great, everything seems to work now! :-) Glad to hear it. Thanks for the confirmation. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On 6/20/11 6:54 AM, Edward K. Ream wrote: On Mon, Jun 20, 2011 at 8:05 AM, Ville M. Vainio wrote: I don't think this is a good idea. If a user says --gui=qttabs, he should get the qttabs ui, no matter whether it's broken or not. It may be fixed in next mac platform or Qt release, for example. You're right! This was a blind spot. The fix is on the trunk at rev 4406. Tested on MacOS and Windows 7. The new code contains only one special case for MacOS: the gui defaults to qt instead of qttabs. Edward Great, everything seems to work now! :-) Cheers, Greg -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Mon, Jun 20, 2011 at 8:05 AM, Ville M. Vainio wrote: > I don't think this is a good idea. If a user says --gui=qttabs, he > should get the qttabs ui, no matter whether it's broken or not. It may > be fixed in next mac platform or Qt release, for example. You're right! This was a blind spot. The fix is on the trunk at rev 4406. Tested on MacOS and Windows 7. The new code contains only one special case for MacOS: the gui defaults to qt instead of qttabs. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Leo 4.9 code base now on the trunk. Pls test. Official release coming tomorrow
The trunk now contains the code base for Leo 4.9. No further changes are planned to the code itself, except for version and build numbers in leoVersion.py. There will, of course, be changes to the docs and to distribution-related files such as readme.txt, leoDist.leo, etc. Please test the trunk and report any problems immediately. I will make no further changes to the code base unless something truly new and significant turns up. I don't see how that can happen :-) There are now three or four minor bugs on the to-do list. None of these bugs require another release this year--my present plan is to release 4.9.1 early in 2012. I'll release 4.9.1 next month if significant bugs do appear in 4.9 final. I do plan to continue work on Leo; to get that work people will have to use bzr. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Mon, Jun 20, 2011 at 4:03 PM, Edward K. Ream wrote: > Done at rev 4405 of the trunk. I tested all the obvious ways of > starting Leo on MacOs, and they all now result in the qt gui being in > effect. If you specify --gui=qttabs, you will get a message saying > that qttabs is not supported on MacOs. I don't think this is a good idea. If a user says --gui=qttabs, he should get the qttabs ui, no matter whether it's broken or not. It may be fixed in next mac platform or Qt release, for example. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Jun 20, 6:41 am, "Edward K. Ream" wrote: > wrote: > > On OSX the default GUI is still qttabs and not qt. > > Thanks for this. For MacOS, Leo translates --gui=qttabs to qt, but > does not translate the default if no --gui argument appears. > > I'll fix this immediately. Done at rev 4405 of the trunk. I tested all the obvious ways of starting Leo on MacOs, and they all now result in the qt gui being in effect. If you specify --gui=qttabs, you will get a message saying that qttabs is not supported on MacOs. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Readability and formatting of Plugins information
On Fri, Jun 17, 2011 at 12:17 AM, lewis wrote: > Can I suggest the documentation be updated at > http://webpages.charter.net/edreamleo/plugins.html > to say that docutils is recommended/requirement if viewrendered is > active? > Also update the about viewrendered text with the same information. I'll do this today. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Mon, Jun 20, 2011 at 3:12 PM, Edward K. Ream wrote: > For me, the target audience are the users of Emacs, Vim, Eclipse, > Visual Studio and the rest of the heavy-duty editors/IDE's that > programmers typically use. I see the "easiest to lure" target audience to be users of Freemind, emacs org mode, etc. (or people that are wondering whether they should start using such a tool) I would hesitate to put emacs and vim to same line w/ visual studio and eclipse. The expectations from users are entirely different. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Sun, Jun 19, 2011 at 2:46 PM, aeromorrison wrote: > We use leo quite a lot here at our company. I would say we are > moderately technical users, but still have a lot to learn about leo! > This is the key problem, however. We do a fair amount of Python coding > in our business, but don't have time to constantly dig through the > source code of every tool we use. It seems quite difficult to get up > to speed on all of the capabilities of leo. Hmm. My intention is that it should *not* be necessary to understand all the intricacies of Leo in order to be able to use it. There are many features of Leo that I use seldom, if ever. This reminds me about the most important Aha I ever had about Emacs, namely that one does not have to pay attention to all of Emacs's alt-x commands in order to use Emacs effectively. The situation is similar, I think, because I modeled Leo's minibuffer of the Emacs minibuffer (and all the Emacs alt-x commands). True, there has been a lot of development on Leo over the past several years, but my own work flow has remained almost completely unchanged. For me, the biggest improvement has been the qttabs gui. At first I was unimpressed; now, I don't know how I ever lived without it. > Even by frequent, careful > reading of the online help and a couple of years of everyday work with > leo, we come away feeling like there is so much more there that we > can't readily access. We monitor these forums and occasionally post > questions and comments, but it feels like to really have an awareness > of leo's feature set, you have to spend significant time reading the > code and understanding it and continuously keep track of this forum. To repeat, you should absolutely feel free to ignore the vast majority of Leo's features, as long as you have a work flow that suites you. > Much of capability discussions on this forum address really > interesting items which don't seem to be addressed in documentation > anywhere. This leaves the moderately technical to pure users wanting. What you are really seeing, I think, is that this forum mostly gets developer-level discussions. There is a separate help forum, but it has low traffic. > It would be fantastic if all the great things about leo could be > documented thoroughly so that potential new users could readily > "access" these capabilities. It seems that the code and features > within leo develop pretty rapidly, but much of it gets left > undocumented. It's documented in the what's new section: http://webpages.charter.net/edreamleo/what-is-new.html But your point is well taken. There may well be important features that aren't very well documented. Feel free to file bug reports about such sections, or just ask about them here: I typically use my responses here as pre-writing for more documentation. > The only 'documentation' seems to be snippets of > discussion threads on this forum. Much of the documentation is > probably adequate for professional computer scientists, but leaves a > significant gap for people like me (an engineer who uses code to get > other work done). Thus, it seems that each time I want to explore a > new feature of leo, I spend a bunch of time in trial and error trying > to figure out how it works. This could be an opportunity for us both. When this happens again, please do ask question here, and remind me of this conversation. That way you can get your answers more quickly, and I will be encouraged to add the missing documentation. I thinks this is the only real way to improve the documentation. It can't be done in general; it can only be done step by specific step. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Sun, Jun 19, 2011 at 2:53 PM, taa, Leo Newbie wrote: >> 1. The goal is to increase the number of Leo's users. > > PLEASE, before too much time and energy is put into Leo 5.0, PLEASE define > what kind of new users you want? Who exactly is the target audience? What do > you want/expect their technical skills to be? What problems can Leo help > with that these users would appreciate? For me, the target audience are the users of Emacs, Vim, Eclipse, Visual Studio and the rest of the heavy-duty editors/IDE's that programmers typically use. Others, like Kent, I suspect, see a somewhat different audience, with more web-oriented interests. > If you could make one of the goals for Leo 5.0 to be that it has less > emphasis on its Python underpinnings and less emphasis on users needing to > know something about Python to use it effectively, I think new users will > get excited. Interesting point of view :-) Leo's users can already completely ignore Leo's Python underpinnings if they choose. We developers, however, live in the world of Python code, Python plugins and Python scripts, so it's natural that Python comes up a lot in our discussions. But users really need to know almost nothing about Python to use Leo. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: tabbed interface, tab to front
On Sat, Jun 18, 2011 at 11:24 AM, Terry Brown wrote: > Here's a problem that's come up before, but I was reminded because it > interferes with cross file links, whether they be UNLs or whatever. > Below is a patch which fixes the > problem, but in the path I put the required call to the new > g.app.gui.ensure_commander_visible(c) in handleUrlInUrlNode, I think it > should really go at the end of openWithFilename. Thanks for this. I'll take a look at this issue after 4.9 final. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Does move-lines-up mess up syntax colouring?
On Jun 20, 6:57 am, "Edward K. Ream" wrote: > Yes, this is indeed a bug in the colorizer. I've just created a bug tracker item: https://bugs.launchpad.net/leo-editor/+bug/799695 EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Does move-lines-up mess up syntax colouring?
2011/6/19 Niklas Hambüchen : > Hi! > I just discovered Leo, am amazed and already started hacking on it for the > last 8 hours. Welcome aboard :-) > The first thing I found out is that when I use move-lines-up on a python > line to move it into a docstring, the syntax colouring does not end properly > after the closing quotes of the docstring anymore (everything below gets > green). > Can anyone confirm this? Yes, this is indeed a bug in the colorizer. I'm not sure what the fix is, but it will have to wait until after 4.9 final. The workaround is to move out of the node, then back in, at which time the entire node will be colorized completely. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Fri, Jun 17, 2011 at 2:46 PM, Edward K. Ream wrote: > Both the trunk and SourceForge now contains Leo 4.9 rc1-a. .. > I'll wait until tomorrow to announce this release widely. I am going to skip the wider announcement for rc1 and release 4.9 final tomorrow. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo 4.9 rc1-a on trunk/SourceForge: public announcements coming tomorrow
On Sat, Jun 18, 2011 at 9:39 PM, Gregory Crosswhite wrote: > On OSX the default GUI is still qttabs and not qt. Thanks for this. For MacOS, Leo translates --gui=qttabs to qt, but does not translate the default if no --gui argument appears. I'll fix this immediately. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
Sorry for not analyzing the whole thread. Still busy time in my life ;-) More than anything else, Leo would benefit from polish, polish, polish: - Get the completion story in shape (perhaps something I can code in july/august) - Simplifications / clarifications. Rename @nosent to @write, wider @url support (for local files)... - Improve quickstart.leo - UI polish where needed (not much, perhaps more mainstream colors, better icon bar etc) large data model changes are probably not needed. @auto-rst, @nosent, @file, @edit, @path, @url get you a long way, On Mon, Jun 20, 2011 at 1:22 AM, Terry Brown wrote: > On Sun, 19 Jun 2011 12:53:49 -0700 > "taa, Leo Newbie" wrote: > >> >Being able to run your data through a script is not a selling point >> >for people who have no idea what a script is, so maybe one click >> >install isn't critical. >> >> I respectfully disagree. One-click install IS critical for more >> widespread use of Leo. >> >> I don't understand why a user's knowledge (or lack thereof) of the >> concept of scripts would have any bearing on whether there should be a >> one-click installer. > > I was probably over-generalizing. A one-click install would be good > for its own sake. Even for hardcore Leo users / coders it would sure > be nice to be able to get it running on other machines that easily. > > And a one-click install would definitely increase the number of people > who try Leo, which is obviously essential if we're going to increase > user base, so yes, one-click install IS critical for more widespread > use of Leo. > > My comment came from thinking that almost all the uses I make of Leo > depend on at least simple scripts to glue stuff together. In a way > that's not really true, seeing a lot of the time I'm just using it to > write code, which doesn't require any scripting. If all you do is use > Leo for writing code, I guess I don't really know how it stacks up > against other environments, since the only other one I've used is > Emacs, which I gave up for Leo. For me, the ability to script Leo, > the python access to nodes, and the possibilities for non-coding uses > etc. would make me choose Leo over other systems even if they were > stronger on the coding aspect. But that's just me. > > I agree with aeromorrison that a period of user experience refinement > would be good for Leo, it's just a question of people wanting to work > on that. I'd like to work on the free layout stuff, the icon bar could > probably be spiffed up, an installer would be nice, and a simple > interface to the @auto / @nosent / @shadow / @file / @edit / @auto-rst > would probably help a lot of people. Plugin management could also be > refined. > > The documentation has improved, although to be fair I think it was > always better than the average open source projects. But it could be > improved more, particularly with respect to plugins and how users > access the documentation (What's this? kind of tools). Perhaps we > could have a little animated character which pops up and asks you what > you're trying to do :-) Kidding. > > Maybe some bug-report / wish list items would be a place to start on > some of this? > > Cheers -Terry > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to leo-editor@googlegroups.com. > To unsubscribe from this group, send email to > leo-editor+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
