Rev 6368 of the trunk contains a big refactoring and simplification of the
find code.
You could call this experimental code, but imo it's ready for wider
testing. As noted below, a possible failure mode for this code is a
non-terminating search command. I don't believe this will ever happen, but
I wouldn't bet my life on it.
Please use caution when using this rev and report any problems immediately.
As noted below, this rev purports to fix all known bugs with the Find
command. It also fixes some previously unreported problems.
More work is coming, including set of unit tests that cover all challenging
cases, of which there are surprisingly many.
Here is the checkin log. Please read the warning carefully.
QQQ
A major set of fixes and refactorings of Leo's find code. More work is
coming, including unit tests.
Warning: the worst-case failure mode for this code is a non-terminating
search command.
This is unlikely, but perhaps not impossible.
The new code likely fixes all the following bugs:
- Bug 1228458: Inconsistency between Find-forward and Find-backward
- Bug 1228312: Find tab selected in log pane disables Minibuffer
- Bug 1228457: Beginning find at the current node's body cursor when that
cursor is not displayed
- Bug 1228713: Find-backward skips headlines under some conditions
QQQ
Edward
P.S. Here are some code notes that are pre-writing for an updated theory of
operation section. Feel free to ignore.
My initial ideas for improving the code were mistaken. The code already
used a string-based widget, with a single instance, s_ctrl. This object is
convenient: it supports the high-level interface, and encapsulates the
relationships between the searched text, the insert point and the selection
range.
The big improvements to the code all involved leoFind.findNextMatch. The
code now uses several new helper methods to compute flags that appear to be
easy to compute, but in fact are not.
The infamous initInHeadline method has been tamed. Previously, this method
contained the following comment:
# Do not change this without extensive testing!
Now, this method is straightforward. Indeed, the general rules of thumb
are:
1. Never search a pane (headline text or body text) unless searching for
that pane is enabled.
2. Forward searches search the headline first, then the body.
3. Reverse searches search the body first, then the headline.
4. self.in_headline indicates what the s_ctrl widget contains, and which
pane is being searched.
Summary of the changed methods:
1. (Most important) initInHeadline no longer makes any kind of guess. It
would be hard to overstate the importance of this change.
Now, this *always* begins searching in the pane with focus if that
searching for that pane is enabled. This goes a long way to making
searches "stateless" (dependent on the minimum amount of saved state
data). Otherwise (Doh!) if searching for the other pane is enabled,
searches must start in that pane.
2. initNextText contains some exquisitely subtle code related to
insertion-point and selection range. This code ensures that searches
always make progress when progress is possible.
3. The infamous selectNextPosition helper is gone. It has been replaced by
several new methods, each handling a surprisingly-complex tiny task:
- doWrap selects the next node when a wrapped search goes "beyond" the
first or last node of an outline.
- firstSearchPane sets self.in_headline to indicate which pane should be
search first when a find command *first* starts. This is a major part of
the fix for
bug 1228458: Inconsistency between Find-forward and Find-backward.
- nextNodeAfterFail, and its helper, outsideSearchRange, replace the bulk
of selectNextPosition. Each is way simpler now that it does one thing only.
- shouldStayInNode works closely with firstSearchPane. It's another part
of the fix for bug 1228458.
That's about it. This will never be easy code, but now the pieces do
well-defined tasks.
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/groups/opt_out.
