I was away after this thread: https://groups.google.com/forum/#!searchin/leo-editor/F.S./leo-editor/2XqXrh_2a0c/c-m5t4CxD1IJ
and I came back to this post (also for reporting the same scroll jump issue). It seems the clock didn't move (for me:-) I read your post about M-H in the stc group. Didn't know that you are (were?) a closet Prolog user. A crazy thought: how about a Prolog port for Leo? A rule based approach would fit the principled philosophy of Leo very well. And Python performance is rather wanting. I don't know if you have ever checked out SWI's pce-emacs editor. It has more advanced IDE features than anything I've seen even though the GUI may be aged. Of course the fact that all your programs are part of a clause base makes querying them rather a breeze. Querying Leo nodes should be just as natural a fit. In case if you think this is too far fetched there is a recent port of the Prolog editor to Qt: https://github.com/CapelliC/pqConsole which may help pave the way. On Monday, March 24, 2014 9:37:05 AM UTC-7, Edward K. Ream wrote: > > As some of you know, I recently restarted work on type-related programming > tools: > > https://groups.google.com/forum/#!topic/python-static-type-checking/Vhy_w5bCH8I > > The purpose of this project has always been to create new tools **for > Leo**, so this is (broadly speaking) still part of the Leo project. > > In important ways, the existing pylint project already does everything > that one could want, but I have a great interest in discovering *exactly* > how it works. I suspect very few people besides the pylint developers > themselves know much about that, which is too bad. > > pylint is a fascinating and fantastic tool. Mastering all it's techniques > promises lead to other tools. The code is way too complex to understand > just by reading the sources. One must actually execute the code to see > what it is doing and how. > > I am using the g.SherlockTracing class to do the executing. This is, in > essence, and alternate version of pdb, with many cool features. See the > docstring for an overview. The --tt option to pylint-leo.py runs pylint on > a test .py file, with Sherlock traces enabled as specified in pylint-leo.py. > > ArmageDOOM asked on #leo why one should use Sherlock instead of g.trace. > The answer is that one can enable and disable traces *without* changing the > source code in any way. For example, I am presently investigating the code > using these two tracing strings:: > > '+PyLinter::add_message', > '+:.*typecheck.py', > > The first string enables only the add_message method of the PyLinter > class. The second enables *all* defs in typecheck.py. > > I have been tweaking the SherlockTracing class all morning to make it > better suited to the task at hand. I also changed one of the __repr__ > methods in pylint itself. The output of __repr__ is now less verbose, > making the Sherlock traces easier to understand. > > Edward > > P.S. The same general remarks apply to the Rope refactoring tool. It's > worth studying in it's own right, and that study might allow Rope to be > incorporated into Leo in some way. > > EKR > -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
