On Sun, Nov 17, 2013 at 10:53 AM, Edward K. Ream <edream...@gmail.com>wrote:
>
The gui work is mostly complete.
You can see the new look at rev
26
23. The new buttons in the Find Pane don't do anything at present.
Despite being the results of about 24 hours of actual work over the last 36
hours, Leo should work *exactly* the same as before, because g.new_find is
False. All unit tests pass, and I am happily eating my own dog food.
Still, problems could be lurking. Please report any such immediately.
I expect to have Leo fully functional today with g.new_find = True. At
that point, I'll turn my attention to a grand revision of the actual search
code. See the Post Script for details.
Edward
P.S. The present code searches using widgets. This is just a terrible
idea. It's a legacy from the days of C and Tk. Clearly, the searches
should be done on the unicode strings themselves.
More importantly, the present code tries keep track of state. That's
completely hopeless. It's horribly complex, and it doesn't work. It's
partly responsible for the various find-related bugs that Segundo Bob has
reported.
The new way will use a stateless find. The search will always just resume
in the present position. It's still far from trivial to get everything
right, but I don't expect the really hard code to change at all.
To handle wrapped searches, each vnode will have a find_generation count,
so it will always be clear which nodes need to be visited. A wrapped search
terminates when all vnodes have a generation could equal to the present
find generation. The find generation gets incremented whenever that search
text changes.
Leo's search code will always be surprisingly tricky, but these changes
will go a long way to eliminating the myriad edge cases that presently
exist.
P.P.S. When g.new_find is True, the code has been completely reorganized.
This is relatively straightforward with Leo because the old organization is
enabled with:
if not g.new_find:
@others
And the new organization is enable with:
if g.new_find:
@others
This could only be approximated (with difficulty!) in other editors.
I have been constantly using the technique of dragging clones to the top
level, as illustrated in the first screencast. There are dozens of nodes
involved, and I've reorganized them in a series of folders, themselves
filed in a single organizer node.
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/groups/opt_out.
