Re: need feedback in hashcache branch when loading files
On Tue, Jun 9, 2009 at 10:12 PM, Edward K. Reamedream...@gmail.com wrote: It sets the whole content every time: contents = w.toHtml() w.setHtml(contents + '\n') Yes. Iirc, I could see no faster way to do the write. Faster way is to use what we use in body editor, i.e. QTextCursor / insertHtml. I implemented it that way back in the day, but I think it was reverted to current behaviour for some reason (I left putnl unimplemented back then). But I don't remember the details. Various commands accumulate output so as to do a single g.es, but that's not so easy if you don't know in advance what the complete output will be. Yeah, and this would be a bad hack anyway. If we can't fix g.es to be fast (due to having to support something special?), we should probably add g.es_fast or somesuch (I don't care how this works, as long as it's fast!). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Tk vs Qt again
On Jun 10, 3:13 am, Ville M. Vainio vivai...@gmail.com wrote: Perhaps porting it all would be a bit too big for a starter project. You could start by providing the essence of what the plugin does (it is reasonably documented) by adding a rclick_qt.py. I don't think 100% compatibily is as important as the possibility of having a node specific context menu in the first place. OK, sounds good. I'll have a look - was meaning to ask about the status of rclick.py anyway... One thing I wanted to ask in the context of some of the recent discussions about documentation and workflow, is about the actual workflow of editing the .py files which make up Leo. The trunk contains (eg) rclick.py, which IIUC is a 'derived' file. In order to read this into Leo and navigate the outline structure etc. I have been using File | New, then File | Import | Import Derived File. This gives me an @thin node with the file present as subnodes etc. Presumably I should edit this and then ... export as a derived file in some way, to create a new rclick.py? I wasn't clear if this was the expected method, or whether there was, perhaps, a corresponding 'rclick.leo' which I should be generating or using. Thanks for answering these newbie questions. I do think the documentation suffers a bit from (as Edward puts it) the 'curse of knowledge', and I hope to chip in with some suggestions for improvement when I can. Cheers Jon N --~--~-~--~~~---~--~~ 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: Tk vs Qt again
On Wed, Jun 10, 2009 at 11:00 AM, jknjkn...@nicorp.f9.co.uk wrote: The trunk contains (eg) rclick.py, which IIUC is a 'derived' file. In order to read this into Leo and navigate the outline structure etc. I have been using File | New, then File | Import | Import Derived File. This gives me an @thin node with the file present as subnodes etc. You are doing it wrong. This is probably an example story that needs to be mentioned in the docs (unless it is already). File - Open - leo/plugins/leoPluginsRef.leo Find node Plugins--Body pane--rClick plugin--@thin rClick.py ctrl+shift+c (copy-node) ctrl+shift+v (paste-node) - this makes a new copy next to the old one edit the file names in @thin nodes (to, say, @thin rclick_qt.py) Save. Start editing. This is one area where leo really shines, once you get the hang of it :-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: A conversation about calioPY
On Wed, Jun 10, 2009 at 1:05 PM, rhhrod.h.holl...@gmail.com wrote: The program is at version 0.72. Program changes are shown in the Notes section of www.caliopywork.org. The program can be downloaded from the Files section. Have you looked at incorporating Sphinx to the caliopy workflow? It seems Sphinx could serve as the last part of caliopy chain (where you currently have reportlab pypdf). Sphinx is probably less freeform than reportlab, but it has a nice momentum right now and some of the work you might do could be applicable in non-caliopy context as well. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Tk vs Qt again
Hi Ville On Jun 10, 9:07 am, Ville M. Vainio vivai...@gmail.com wrote: [...] You are doing it wrong. This is probably an example story that needs to be mentioned in the docs (unless it is already). File - Open - leo/plugins/leoPluginsRef.leo [...] Ah, excellent - so leoPluginsRef.leo is the 'parent' file for all the derived .py files etc. I hadn't seen this 'use case' (story ;-) in the docs. There's a definite gap between Chapter 2 and Chapter 4 I think. Info on this sort of workflow would IMO be a *big* help up on the learning curve. Thanks again jon N --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
small but annoying Qt observation when editing headlines
When a node headline is selected, the selection is in grey and looks fine. But when I *edit* a headline (selected text is dark blue), the height of this selection rectangle is too small by a pixel or two - it looks as if it's the 'inside' of the previous grey selection area. So you lose sight of the node headline you're changing, and descenders and underlines etc. in the node headline are not visible. Not the greatest problem in the world, but it would be nice if it were cleaned up ;-) Regards Jon N --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
curiosity seen in qtGui.py
def killGui(self,exitFlag=True): Destroy a gui and terminate Leo if exitFlag is True. def killPopupMenu(self): pass I would have thought that there is a missing 'pass' here, although having experimented, I find that: def dummy(): dummy statement is valid python, as is def dummy(): '''dummy docstring''' but not def dummy(): #dummy comment I thought they all needed a 'pass'. You live and learn. Still think a 'pass' would be nice though... Jon N --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
B2 slippage. Enjoying the journey :-)
As the release date for Leo 4.6 beta 2 slips at the rate of approximately one day/day, it's good to remind myself that the slippage is a symptom of happy times. We are all engaged in creating something interesting and worthwhile. New ideas appear daily. Even the bug reports are a clear indication that a lot of people care. So. I may be impatient, as presumably many of you are, but truly, it doesn't get any better than this. Edward P.S. There are only two or three bugs that *must* be fixed by b2. When they are fixed I'll probably declare that b2 will go out the door in two more days. I'm dithering about whether to merge the hashcashe stuff before b2. I suspect it will happen. It should be worth any slight additional delay. 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 4:13 PM, Edward K. Reamedream...@gmail.com wrote: in two more days. I'm dithering about whether to merge the hashcashe stuff before b2. I suspect it will happen. It should be worth any slight additional delay. As far as I'm concerned, hashcache is ready for merge once I solve the redraw_after_icons_changed problem (it gets called too much, which slows it down). Now, hashcache branch just ignores those events, but it can't probably stay that way. Basically *all* redraw stuff should be disabled during file loading. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Tk vs Qt again
On Wed, Jun 10, 2009 at 3:59 PM, Edward K. Reamedream...@gmail.com wrote: Newbies don't want to spend much time learning. We are all so inundated with possible new tools and projects that we typically give ourselves just a minute or two to judge whether a project is worth the effort to learn. An enterprising soul may want to create leoDemo.leo, and add help - Open leoDemo.leo. It could have some @thin and @auto nodes, perhaps an @auto-rst node, some @buttons and ctrl+b scripts, and snippets from the docs. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Tk vs Qt again
On Wed, Jun 10, 2009 at 4:22 PM, Ville M. Vainiovivai...@gmail.com wrote: Newbies don't want to spend much time learning. We are all so inundated with possible new tools and projects that we typically give ourselves just a minute or two to judge whether a project is worth the effort to learn. An enterprising soul may want to create leoDemo.leo, and add help - Open leoDemo.leo. I take that back. We should create a template workbook.leo on first run, and add the demo stuff there. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Tk vs Qt again
On Wed, Jun 10, 2009 at 8:29 AM, Ville M. Vainio vivai...@gmail.com wrote: I take that back. We should create a template workbook.leo on first run, and add the demo stuff there. Excellent idea! 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 8:16 AM, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jun 10, 2009 at 4:13 PM, Edward K. Reamedream...@gmail.com wrote: in two more days. I'm dithering about whether to merge the hashcashe stuff before b2. I suspect it will happen. It should be worth any slight additional delay. As far as I'm concerned, hashcache is ready for merge. I'm getting bad archived position messages after doing the following: - Create hashcache branch. - Delete ~/.leo/db - copy LeoPyRef.leo to leoPy.leo - open leoPy.leo Don't know whether this is serious or not, but it is disconcerting. Do you see this? Edward P.S. Here is the output. (Aside: it looks like a space is needed in the writeCachedTree message after to). C:\leo.repo\hashcacherem ipython leo\core\runLeo.py --gui qt leo\core\leoPy.leo C:\leo.repo\hashcachec:\python25\python.exe leo\core\runLeo.py --gui=qt --gui qt leo\core\leoPy.leo reading settings in C:\leo.repo\hashcache\leo\config\leoSettings.leo Using menus from leoSettings.leo reading settings in C:\Documents and Settings\HP_Administrator\My Documents\Edward\.leo\myLeoSettings.leo reading settings in C:\leo.repo\hashcache\leo\core\leoPy.leo reading C:\Documents and Settings\HP_Administrator\My Documents\Edward\.leo\.leoRecentFiles.txt loaded plugin: qtGui @enabled-plugins found in leoSettings.leo can not load enabled plugin: hoist can not load enabled plugin: image reading: @thin ../doc/leoNotes.txt writeCachedTree: write cache tofcache/557a26c917270493dcfc46436c5a6090 reading: @thin leoProjects.txt writeCachedTree: write cache tofcache/c69bb36814e608303288f96556446545 reading: @thin ../doc/leoToDo.txt writeCachedTree: write cache tofcache/a905a23fdc1f018bafb046d9666d787c reading: @thin ../doc/leoToDoLater.txt writeCachedTree: write cache tofcache/dd93ffebf1526a476b02a409e9ac3b1f reading: @thin test_core.txt writeCachedTree: write cache tofcache/c4340bb7197c20dbae94252628cc50b6 reading: @thin leoApp.py writeCachedTree: write cache tofcache/20dd29e1c1529baae5134f4495007274 reading: @thin leoAtFile.py writeCachedTree: write cache tofcache/b0aba0ba48559d364166afc9fdefaad5 reading: @thin leoBridge.py writeCachedTree: write cache tofcache/d390341acb9ccda29a0c2d527d80b5f0 reading: @thin leoChapters.py writeCachedTree: write cache tofcache/c5b7a2a18c6d567f6eef3a5ae5b92892 reading: @thin leoColor.py writeCachedTree: write cache tofcache/37074b8308b7e93b0c8bf89d4cd15bec reading: @thin leoCommands.py writeCachedTree: write cache tofcache/3b7ffbd5072e2a425690791a3f242b31 reading: @thin leoConfig.py writeCachedTree: write cache tofcache/d02ea293ac3dcf57430df0c8062750a9 reading: @thin leoEditCommands.py writeCachedTree: write cache tofcache/c59fefa99a9847a2f8ba5318faa3c913 reading: @thin leoFileCommands.py writeCachedTree: write cache tofcache/1f58b74642e79856de01f520585e1dec reading: @thin leoGlobals.py writeCachedTree: write cache tofcache/7582698698cefc0508b4ff386d692b03 reading: @thin leoImport.py writeCachedTree: write cache tofcache/fbc09d8eb28f7222c3d408c528696a58 reading: @thin leoNodes.py writeCachedTree: write cache tofcache/fe24ed02b4fbd062b149102a4c6a63fd reading: @thin leoPlugins.py writeCachedTree: write cache tofcache/143380c2438dd0e67bff1bd8a6d9006d reading: @thin leoPymacs.py writeCachedTree: write cache tofcache/c3e1d25ee16d7322fddd004c4d1cc9f3 reading: @thin leoRst.py writeCachedTree: write cache tofcache/6140f53f8875045d1430351a0670287b reading: @thin leoShadow.py writeCachedTree: write cache tofcache/e7fb70fd84f053b7254136effdfd reading: @thin leoTangle.py writeCachedTree: write cache tofcache/419fcb178496844cfda512d8dbdeddfd reading: @thin leoUndo.py writeCachedTree: write cache tofcache/fededaa844c15197ab90870a1fe41af8 reading: @thin runLeo.py writeCachedTree: write cache tofcache/ef1eb412cce66bdaae4c209e0763bc14 reading: @thin leoCompare.py writeCachedTree: write cache tofcache/4d1837e222e176dcb43a1b31e226eb73 reading: @thin leoFind.py writeCachedTree: write cache tofcache/4e9ccd5a477d5da8248cbfb9148c49e2 reading: @thin leoFrame.py writeCachedTree: write cache tofcache/0d36e9b5f7debdc66bc5dfc8400249b2 reading: @thin leoGui.py writeCachedTree: write cache tofcache/043c3c5a64036e2e725342808c394663 reading: @thin leoKeys.py writeCachedTree: write cache tofcache/3ed094121e1f1c900f447c50f050ada3 reading: @thin leoMenu.py writeCachedTree: write cache tofcache/0451996d2af5bbd3f6d680df9ffcb81e reading: @thin leoBridgeTest.py writeCachedTree: write cache tofcache/29f8ab6e0fd6631125102e8cc6d0ca9c reading: @thin leoDynamicTest.py writeCachedTree: write cache tofcache/cd03effd6fa4437f8ffcd899f2dceb25 reading: @thin leoTest.py writeCachedTree: write cache tofcache/a27b470151afe7cfbe11a389b6497273 bad archived position: bad index=1, len(children)=0 restoreDescendentAttributes: can not find vnode (duA): archivedPosition: 0.1.8.0.1.1, root_v: vnode 40471152:'@thin test_core.txt' bad archived position: bad index=0, len(children)=0 restoreDescendentAttributes:
Re: objtrees - simplification of unit/regression testing
On Tue, Jun 9, 2009 at 11:57 PM, Ville M. Vainio vivai...@gmail.com wrote: I already explained what objtrees are: http://bazaar.launchpad.net/~villemvainio/leo-editor/hashcache/annotate/head%3A/leo/doc/treecaching.txthttp://bazaar.launchpad.net/%7Evillemvainio/leo-editor/hashcache/annotate/head%3A/leo/doc/treecaching.txt Now, these could be used to improve unit testing quite a bit - basically, to ensure that subtrees (and bodies!) are exactly as they should be without writing any code. I'm not sure what I think of this. There already is straightforward code to compare outlines at: Code--Test classes--@thin leoTest.py-- class testUtils--compareOutlines It's not clear to me that golden_run mechanism is easier than the present way. For instance, see unitTest.leo: Scripts--@ignore--Scripts that make unit tests 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: need feedback in hashcache branch when loading files
On Wed, Jun 10, 2009 at 2:46 AM, Ville M. Vainio vivai...@gmail.com wrote: On Tue, Jun 9, 2009 at 10:12 PM, Edward K. Reamedream...@gmail.com wrote: It sets the whole content every time: contents = w.toHtml() w.setHtml(contents + '\n') Yes. Iirc, I could see no faster way to do the write. Faster way is to use what we use in body editor, i.e. QTextCursor / insertHtml. I implemented it that way back in the day, but I think it was reverted to current behaviour for some reason (I left putnl unimplemented back then). But I don't remember the details. Ok. I'll look at this again. If I run into problems I'll ask for help before concluding that the QTextCursor approach won't work. Various commands accumulate output so as to do a single g.es, but that's not so easy if you don't know in advance what the complete output will be. Yeah, and this would be a bad hack anyway. If we can't fix g.es to be fast (due to having to support something special?), we should probably add g.es_fast or somesuch (I don't care how this works, as long as it's fast!). :-) I would much prefer just to make g.es fast. 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: hashcache (fast!) branch testers needed
On Wed, 10 Jun 2009 04:57:15 +0300 Ville M. Vainio vivai...@gmail.com wrote: Before running that code, do rm -Rf ~/.leo/db. This is needed because I chanced the pickle file format to a compressed one. So does this mean switching back and forth between your branch and the trunk is potentially messy? Not really. This tweak (rm -Rf) was needed when upgrading from old version of hashcache branch to new one. Ok, shouldn't be a problem, I wasn't sure if it would impact c.db. 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 -~--~~~~--~~--~--~---
Re: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 5:05 PM, Edward K. Reamedream...@gmail.com wrote: As far as I'm concerned, hashcache is ready for merge. I'm getting bad archived position messages after doing the following: - Create hashcache branch. - Delete ~/.leo/db - copy LeoPyRef.leo to leoPy.leo - open leoPy.leo I also get the same messages with current trunk (don't you?), so I didn't think much of it. Basically, as I've said before, I don't trust archivedPosition at all ;-). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: hashcache (fast!) branch testers needed
On Wed, Jun 10, 2009 at 5:29 PM, Terry Brownterry_n_br...@yahoo.com wrote: Ok, shouldn't be a problem, I wasn't sure if it would impact c.db. Actually, it did - however, c.db is not so widely used yet as to warrant big concerns about it. To get rid of just the caches, you could oo find ~/.leo/db -name fcache -type d | xargs rm -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 9:40 AM, Ville M. Vainio vivai...@gmail.com wrote: I also get the same messages with current trunk (don't you?), No, but this is a history-dependent matter. so I didn't think much of it. Basically, as I've said before, I don't trust archivedPosition at all ;-). Ok. I'd like to revisit the archivedPosition issue soon. For now, though, please merge the hashcache branch into the trunk. We'll can deal with any glitches before b2. 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: small but annoying Qt observation when editing headlines
On Wed, Jun 10, 2009 at 7:00 AM, jkn jkn...@nicorp.f9.co.uk wrote: When a node headline is selected, the selection is in grey and looks fine. But when I *edit* a headline (selected text is dark blue), the height of this selection rectangle is too small by a pixel or two - it looks as if it's the 'inside' of the previous grey selection area. So you lose sight of the node headline you're changing, and descenders and underlines etc. in the node headline are not visible. What gui are you talking about? 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: curiosity seen in qtGui.py
On Wed, Jun 10, 2009 at 7:20 AM, jkn jkn...@nicorp.f9.co.uk wrote: def killGui(self,exitFlag=True): Destroy a gui and terminate Leo if exitFlag is True. def killPopupMenu(self): pass I would have thought that there is a missing 'pass' here The docstring suffices. But not comments. 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: objtrees - simplification of unit/regression testing
On Wed, Jun 10, 2009 at 9:53 AM, Ville M. Vainio vivai...@gmail.com wrote: Yeah, but this requires that the outline is out there in the tree. If you have a test that checks outline structure in 5 different stages, you will need 5 trees to compare against (as opposed to 5 lines of code intermingled with the test code). My main concern is what happens when a unit test fails. Is it possible, with your scheme, to see the before, after and expected versions of the tree? 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 6:18 PM, Edward K. Reamedream...@gmail.com wrote: For now, though, please merge the hashcache branch into the trunk. We'll can deal with any glitches before b2. Thank you. Please bzr pull and refrain from committing until I've pushed the merge. We don't want this changeset to sink inside merge after commit log entry ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 6:29 PM, Ville M. Vainiovivai...@gmail.com wrote: Thank you. Please bzr pull and refrain from committing until I've I mean bzr push whatever changes you have pending, so you can just bzr pull after I've pushed and the tree will keep clean. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Hashcache on trunk
I have now merged hashcache to trunk. Please pull immediately. Do *not* do bzr merge, it screws up the history (big merges should always be shown on the main trunk). If you have unpushed changes, do that via different branch (if in doubt, ask me how). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 6:18 PM, Edward K. Reamedream...@gmail.com wrote: so I didn't think much of it. Basically, as I've said before, I don't trust archivedPosition at all ;-). Ok. I'd like to revisit the archivedPosition issue soon. In summary, the safe way to recreate vnode uAs is storing both gnx and archivedposition. If archivedposition fails, it can still look up the node by gnx, provided that it has only one node with that gnx. If it has several, then it's ok to fail. But, the only safe uA is the tnode uA... -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: small but annoying Qt observation when editing headlines
On Wed, Jun 10, 2009 at 7:04 PM, jknjkn...@nicorp.f9.co.uk wrote: Qt, sorry. I rarely/never look at Tk, but you weren't to know that ... It's the difference between: http://www.nicorp.co.uk/download/clipped_headline.png # grey selection OK and http://www.nicorp.co.uk/download/clipped_headline1.png # blue selection vertically clipped It probably depends on the font, but I haven't knowingly altered that. What OS is that? This looks better on my Ubuntu Jaunty (and your font seems worse in general). Screenshot attached. Try installing qt4-qtconfig (or whatever it is for you) and playing with fonts. I changed my font on Debian Lenny at least, because the default sucked. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- attachment: nonclipped_headline.png
Re: small but annoying Qt observation when editing headlines
Hi Ville It's on Gentoo Linux. The font was (I learn from qtconfig) Deja Vu Sans. I'll have a play with fonts etc. and report back. J^n --~--~-~--~~~---~--~~ 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 10:57 AM, Ville M. Vainio vivai...@gmail.comwrote: Ok. I'd like to revisit the archivedPosition issue soon. In summary, the safe way to recreate vnode uAs is storing both gnx and archivedposition. If archivedposition fails, it can still look up the node by gnx, provided that it has only one node with that gnx. If it has several, then it's ok to fail. But, the only safe uA is the tnode uA... Can we do this for b2? (Might as well make b2 truly memorable :-) Iirc, the code is already somewhere in Leo. Do have a link to the discussion? 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: bookmarks.py default leo file / list of leo files
On Wed, Jun 10, 2009 at 11:59 AM, Terry Brown terry_n_br...@yahoo.comwrote: Just a random post to promote the bookmarks.py plugin I'm glad you did. This looks really useful. 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: bookmarks.py default leo file / list of leo files
On Wed, Jun 10, 2009 at 11:59 AM, Terry Brownterry_n_br...@yahoo.com wrote: Just a random post to promote the bookmarks.py plugin My default (~/.leo/workbook.leo) looks like the attached. The bookmarks.py plugin (detecting the @bookmarks directive) opens the leo file listed in the first line of the body of those nodes when I double click the node. Nice! Intuitive and useful. The plugin also makes links to web urls look better, same mechanism, but they open in your browser of course. Not new, but thanks Edward for fixing the c.frame.bringToFront() bug, as the system works much better when double clicking the link to an already open file brings it to the front. 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 -~--~~~~--~~--~--~---
Re: Hashcache on trunk
On Wed, Jun 10, 2009 at 10:41 AM, Ville M. Vainio vivai...@gmail.comwrote: I have now merged hashcache to trunk. Please pull immediately. Do *not* do bzr merge, it screws up the history (big merges should always be shown on the main trunk). If you have unpushed changes, do that via different branch (if in doubt, ask me how). I'm happily using the new trunk. It looks good. Many thanks for this great work. 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 1:20 PM, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jun 10, 2009 at 8:37 PM, Edward K. Reamedream...@gmail.com wrote: In summary, the safe way to recreate vnode uAs is storing both gnx and archivedposition. If archivedposition fails, it can still look up the node by gnx, provided that it has only one node with that gnx. If it has several, then it's ok to fail. But, the only safe uA is the tnode uA... Can we do this for b2? (Might as well make b2 truly memorable :-) Iirc, the code is already somewhere in Leo. Do have a link to the discussion? There is a proto for one version: Scripts--@thin leoScripts.txt--Prototypes--pos_to_archive, archive_to_pos But, this causes more lengthy archived positions than what would be usable in xml files (gnx1.gnx2.gnx3...) Why do we care about the length? currently p.archivedPosition gives 1.2.4. Perhaps it should be changed to give 1.2.4:gnx. That way, resolveArchivedPosition could remain compatible with old archived positions. Couldn't resolveArchivedPosition be made compatible in either case? Shouldn't be too risky - and improving data integrity is worth it. I agree. We can still fail if the gnx can't be found in the subtree being scanned (like we fail now when the position can't be found). Sure. Representation can't make up for truly missing data. 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: B2 slippage. Enjoying the journey :-)
On Wed, Jun 10, 2009 at 9:24 PM, Edward K. Reamedream...@gmail.com wrote: But, this causes more lengthy archived positions than what would be usable in xml files (gnx1.gnx2.gnx3...) Why do we care about the length? You have to stare at them in xml files (e.g. when reading diffs). currently p.archivedPosition gives 1.2.4. Perhaps it should be changed to give 1.2.4:gnx. That way, resolveArchivedPosition could remain compatible with old archived positions. Couldn't resolveArchivedPosition be made compatible in either case? Yes. I was speaking too fast. can still fail if the gnx can't be found in the subtree being scanned (like we fail now when the position can't be found). Sure. Representation can't make up for truly missing data. Again, speaking too fast. I meant we should fail if we have 2+ nodes with same gnx (in face of ambiguity, resolve the temptation to guess). Still - tnode uA's should remain the preferred uA approach. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Hashcache on trunk
On Jun 10, 1:19 pm, Edward K. Ream edream...@gmail.com wrote: I'm happily using the new trunk. It looks good. Many thanks for this great work. Houston. We have a problem. The at-file read logic is never using the cache on my xp machine. I inserted the line: g.trace(cachefile in c.db,cachefile) before the line: if cachefile in c.db: in leoAtFile.read. The trace is always printing False. Which isn't surprising since the line: g.pr(Generate from cache:, root.h) was never printing anything. There are indeed cached files in the leoPy.leo cache. No wonder I didn't notice much of a speedup. I wanted to alert everyone about this. I'll be investigating... 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: Hashcache on trunk
Houston. We have a problem. The at-file read logic is never using the cache on my xp machine. Interesting, it seems to work on people's Linux computers (just tested it on my 1ghz eee - I was able to open leoPyRef with almost zero read time :-). Run this script: print c.db.keys(fcache/*) then, print cachefile in read() and see why it's not found -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Hashcache on trunk
On Wed, Jun 10, 2009 at 9:46 PM, Ville M. Vainiovivai...@gmail.com wrote: Run this script: print c.db.keys(fcache/*) then, print cachefile in read() and see why it's not found You may also try bzr pull right now - I made a small tweak that may help with case-insensitive file system. Also try different ways of opening a file - from recent files, file-open, command line. They all work for me. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Hashcache on trunk
On Jun 10, 1:46 pm, Ville M. Vainio vivai...@gmail.com wrote: Houston. We have a problem. The at-file read logic is never using the cache on my xp machine. Interesting, it seems to work on people's Linux computers (just tested it on my 1ghz eee - I was able to open leoPyRef with almost zero read time :-). Run this script: print c.db.keys(fcache/*) then, print cachefile in read() and see why it's not found I took a similar approach. g.trace(cachefile in c.db,repr(cachefile)) for z in c.db.keys(): print repr(cachefile)==repr(z),cachefile==z,repr (cachefile),repr(z) It shows that repr(cachefile) == repr(z) (and cachefile==z for) exactly one key (as expected), but still cachefile is not in c.db (!!) Furthermore, having _contentHashFile return str(fcache/ + m.hexdigest ()) has no effect. This is a puzzle. Why is cachefile not in c.db if it matches one of the keys??? 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: Hashcache on trunk
On Wed, Jun 10, 2009 at 2:25 PM, Edward K. Ream edream...@gmail.com wrote: I'll never be happy without instant loads :-) Stepping back for a moment, this is a lesson in optimization that I'm not likely ever to forget. Rather than make code run faster, this could be considered an entirely new algorithm, but that doesn't get at the heart of the matter. Instead, it shows that compression techniques comprise an entirely new (for me) realm for optimization. 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: need feedback in hashcache branch when loading files
On Wed, Jun 10, 2009 at 9:18 PM, Edward K. Reamedream...@gmail.com wrote: suffices to end the line. Who would have thunk it? To my eyes the log is zippier now. What do you think? It's much faster now. run this script in old new code: for i in range(1000): g.es(i) You'll see it used to get slower and slower as stuff piles up, in linear fashion (for obvious reasons). In essence, leo got slower and slower as time passed. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: small but annoying Qt observation when editing headlines
On Wed, Jun 10, 2009 at 10:45 PM, jknjkn...@nicorp.f9.co.uk wrote: Actually, fonts selected via qtconfig don't seem to change the body or tree font - just eg. the menu entries. I haven't yet looked for any font settings in the various leoconfig files, are there likely to be some? No idea. I think font sizes are configurable? I have some fairly old intel graphics on this machine, the X driver for which has caused a lot of problems recently. I doubt that's the issue, though it might account for other differences between mine and the Ubuntu screengrabs. More likely cause is Ubuntu putting extra care for stuff like this (fonts). You may be able to fiddle with them in your kde system settings... -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Cutting old-style gnx support?
I noted an interesting anomaly (with hashcache): @thin detect_urls.py (plugins). Check it out. The problem probably is the old style gnx it uses? I will investigate it tomorrow. However, we would all be better off if gnx's like this were not a special case. It never occured for me why gnx's are not always just strings, instead of the tuple it is now - it probably was just for compatibility wild old leo's, but strings with no special meaning are compatible everywhere. scanGnx friends really should not be necessary for anything. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: small but annoying Qt observation when editing headlines
looks like the settings are held as Qt stylesheet elements within
leoSettings.leo, eg:
/* Headline edit widgets */
QTreeWidget QLineEdit {
background-color: cornsilk;
selection-color: white;
selection-background-color: blue;
font-family: DejaVu Sans Mono;
font-size: 12px;
font-weight: normal; /* normal,bold,100,..,900 */
font-style: normal; /* normal, italic,oblique */
}
More likely cause is Ubuntu putting extra care for stuff like this
(fonts). You may be able to fiddle with them in your kde system
settings...
I'm running kde 4.2 (spit...) which doesn't seem to allow much font
configuration via menus etc. I'll have a look around for other ways to
do things. I don't think Ubuntu does things much differently to Gentoo
though.
J^n
--~--~-~--~~~---~--~~
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: small but annoying Qt observation when editing headlines
Also, I'm running PyQt version 4.4.4-r2, when the latest seems to be 4.5. Might this be the problem? (looks like fun trying to upgrade on this system...) Thanks Jon --~--~-~--~~~---~--~~ 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: hashcache (fast!) branch testers needed
The cache stuff really does rock - at the moment when I open a file with a bunch of @files and no cache I can't resist closing it and opening it again just to see how quick it will be 'next time' :-) 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 -~--~~~~--~~--~--~---
Error, unable to start leo
Hi, after using Leo for a few days on my ubuntu linux box, I get the following error which kills the editor: p...@dell-desktop:~$ leo [1] 6537 p...@dell-desktop:~$ reading settings in /home/paul/bin/Leo-4-6-b1/leo/ config/leoSettings.leo /home/paul/bin/Leo-4-6-b1/leo/external/pickleshare.py:43: DeprecationWarning: the sets module is deprecated from sets import Set as set Using menus from leoSettings.leo reading settings in /home/paul/.leo/myLeoSettings.leo Using menus from myLeoSettings.leo reading /home/paul/.leo/.leoRecentFiles.txt @enabled-plugins found in myLeoSettings.leo loaded plugin: tkGui opening default_leo_file: /home/paul/.leo/workbook.leo Traceback (most recent call last): File /home/paul/bin/Leo-4-6-b1/launchLeo.py, line 8, in module leo.core.runLeo.run() File /home/paul/bin/Leo-4-6-b1/leo/core/runLeo.py, line 110, in run c,frame = createFrame(fileName,relativeFileName,script) File /home/paul/bin/Leo-4-6-b1/leo/core/runLeo.py, line 158, in createFrame ok, frame = g.openWithFileName(relativeFileName or fileName,None) File /home/paul/bin/Leo-4-6-b1/leo/core/leoGlobals.py, line 2292, in openWithFileName c.chapterController.finishCreate() File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 64, in finishCreate cc.chaptersDict[tabName] = chapter (c=c,chapterController=cc,name=tabName,root=p) File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 873, in __init__ cc.tt.createTab(name) File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8922, in createTab tt.setNames() File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8962, in setNames tt.chapterMenu.setitems(names) File /usr/lib/python2.6/dist-packages/Pmw/Pmw_1_3/lib/ PmwOptionMenu.py, line 67, in setitems self._menu.delete(0, 'end') File /usr/lib/python2.6/lib-tk/Tkinter.py, line 2678, in delete self.deletecommand(c) File /usr/lib/python2.6/lib-tk/Tkinter.py, line 361, in deletecommand self.tk.deletecommand(name) _tkinter.TclError: can't delete Tcl command Can anyone suggest how to fix this? Thanks, Paul --~--~-~--~~~---~--~~ 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: Error, unable to start leo
I fixed it by renaming the file so that it doesn't try to load at startup. Then I was able to open it via the open command. Then I removed two nodes that were under the @chapters outline. I saved it, then renamed the file back to workbook.leo and the errors are gone. It seems I made something inconsistent when I created a chapter. I'm not sure what exactly. Request: Where can I find more information about @chapters? It seems odd that it is shown as a default node in every outline yet such an 'important' feature does not have much documentation. I suppose it is just a handy way to save various 'hoisted' views so that you can easily find it in the drop down menu? I'm not clear on how it works. When I try to create a chapter, my cursor goes to the minibuffer, but I'm not told what to do. Whatever I type, I get errors when I hit return. Error: 1 class '_tkinter.TclError' Exception in Tk callback Function: function bindCallback at 0xad3717c (type: type 'function') Args: (Tkinter.Event instance at 0xa38ce0c,) Event type: KeyPress (type num: 2) Traceback (innermost last): File /usr/lib/python2.6/dist-packages/Pmw/Pmw_1_3/lib/PmwBase.py, line 1747, in __call__ return apply(self.func, args) File /home/paul/bin/Leo-4-6-b1/leo/core/leoCommands.py, line 6190, in bindCallback val = func(event) File /home/paul/bin/Leo-4-6-b1/leo/core/leoKeys.py, line 2408, in masterBindKeyCallback return k.masterKeyHandler(event,stroke=stroke) File /home/paul/bin/Leo-4-6-b1/leo/core/leoKeys.py, line 3340, in masterKeyHandler return k.getArg(event,stroke=stroke) File /home/paul/bin/Leo-4-6-b1/leo/core/leoKeys.py, line 3129, in getArg if handler: handler(event) File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 228, in createChapter undoType='Create Chapter') File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 256, in createChapterByName cc.chaptersDict[name] = chapter (c=c,chapterController=cc,name=name,root=root) File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 873, in __init__ cc.tt.createTab(name) File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8922, in createTab tt.setNames() File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8962, in setNames tt.chapterMenu.setitems(names) File /usr/lib/python2.6/dist-packages/Pmw/Pmw_1_3/lib/ PmwOptionMenu.py, line 67, in setitems self._menu.delete(0, 'end') File /usr/lib/python2.6/lib-tk/Tkinter.py, line 2678, in delete self.deletecommand(c) File /usr/lib/python2.6/lib-tk/Tkinter.py, line 361, in deletecommand self.tk.deletecommand(name) class '_tkinter.TclError': can't delete Tcl command Event contents: char: delta: 36 height: ?? keycode: 36 keysym: Return keysym_num: 65293 num: ?? send_event: False serial: 13625 state: 0 time: 9217357 type: 2 widget: .181594892.18159.185949420.minibuffer width: ?? x: 435 x_root: 512 y: -566 y_root: 201 I'm thinking that a chapter should be created from the selected node, but that doesn't seem to happen. Thanks, Paul On Jun 10, 8:23 pm, unst...@gmail.com unst...@gmail.com wrote: Hi, after using Leo for a few days on my ubuntu linux box, I get the following error which kills the editor: p...@dell-desktop:~$ leo [1] 6537 p...@dell-desktop:~$ reading settings in /home/paul/bin/Leo-4-6-b1/leo/ config/leoSettings.leo /home/paul/bin/Leo-4-6-b1/leo/external/pickleshare.py:43: DeprecationWarning: the sets module is deprecated from sets import Set as set Using menus from leoSettings.leo reading settings in /home/paul/.leo/myLeoSettings.leo Using menus from myLeoSettings.leo reading /home/paul/.leo/.leoRecentFiles.txt @enabled-plugins found in myLeoSettings.leo loaded plugin: tkGui opening default_leo_file: /home/paul/.leo/workbook.leo Traceback (most recent call last): File /home/paul/bin/Leo-4-6-b1/launchLeo.py, line 8, in module leo.core.runLeo.run() File /home/paul/bin/Leo-4-6-b1/leo/core/runLeo.py, line 110, in run c,frame = createFrame(fileName,relativeFileName,script) File /home/paul/bin/Leo-4-6-b1/leo/core/runLeo.py, line 158, in createFrame ok, frame = g.openWithFileName(relativeFileName or fileName,None) File /home/paul/bin/Leo-4-6-b1/leo/core/leoGlobals.py, line 2292, in openWithFileName c.chapterController.finishCreate() File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 64, in finishCreate cc.chaptersDict[tabName] = chapter (c=c,chapterController=cc,name=tabName,root=p) File /home/paul/bin/Leo-4-6-b1/leo/core/leoChapters.py, line 873, in __init__ cc.tt.createTab(name) File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8922, in createTab tt.setNames() File /home/paul/bin/Leo-4-6-b1/leo/plugins/tkGui.py, line 8962, in setNames tt.chapterMenu.setitems(names) File
Re: Error, unable to start leo
On Thu, Jun 11, 2009 at 8:16 AM, unst...@gmail.comunst...@gmail.com wrote:
It seems I made something inconsistent when I created a chapter. I'm
not sure what exactly.
Chapters support on Tk is broken in new Ubuntu. Use the Qt ui instead
('leo --gui=qt').
--
Ville M. Vainio
http://tinyurl.com/vainio
--~--~-~--~~~---~--~~
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: Cutting old-style gnx support?
On Wed, Jun 10, 2009 at 11:18 PM, Ville M. Vainiovivai...@gmail.com wrote: However, we would all be better off if gnx's like this were not a special case. It never occured for me why gnx's are not always just strings, instead of the tuple it is now - it probably was just for compatibility wild old leo's, but strings with no special meaning are compatible everywhere. scanGnx friends really should not be necessary for anything. However, now it's probably too late in beta stage to change that (some plugins depend on the behaviour?). Perhaps something for post-release. I'll look at this defect this evening. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
