PR for #3871: searching for definitions should not change search settings

[edreamleo]

See #3871.

Breaking change to Leo's API: This PR changes the signatures of find.find_def and find.find_var.

• Rewrite find-def and find-var commands. These commands are now synonymous.
• Aha: Don't use Leo's find commands. Search only body text, honoring @nosearch.
• As before, for unique matches, select the node that matches.
  do_find_def must honor @bool reverse-find-defs.
• Set the find text if there are multiple matches. This is convenient and should never be annoying.
• Support @bool prefer-nav-pane, with default set to True to match most Leonistas' preferences.
  • True: Show multiple search results in the Nav pane if the quicksearch plugin is enabled.
  • False: Always show multiple matches using clones as in the clone-find commands.
    Note: regardless of this setting, Leo selects unique search results by selecting the node.

Minor changes

• Init c.quicksearch_controller = None.
  QuickSearchController.__init__ sets c.quicksearch_controller = self.
• Improve unit tests.

[edreamleo]

@boltex @tbpassin This PR is ready for review.

I am thrilled with the result. Control-clicks now take noticeably longer, but the new code is much better.

[edreamleo]

@boltex This PR will probably affect both LeoInteg and LeoJS.

[boltex]

@edreamleo When reading about this, I also thought about suggesting re-using the nav pane! If you make results use the same objects-structure as nav pane clickable results, I wont even have to modify LeoInteg! :) (it mirrors those nav pane results in it's 'goto' pane)

I'll review and try it out as soon as I finish debugging and polishing 'detached body panes' in leoJS and LeoInteg, in a day or two.

[edreamleo]

@boltex Recent revs put the results in the Nav if and only if the quicksearch plugin is enabled.

Will that plan be good enough for you?

[edreamleo]

@tbpassin @boltex Recent revs contain a significant optimization. The code tries to find possible alternate spellings only if searches for the primary spelling (the string that is control-clicked) fail. This approach should double the speed of most searches.

[edreamleo]

@boltex @tbpassin Please approve this PR. Imo, @bool prefer-nav-pane is the last piece of the puzzle.

[tbpassin]

I just checked out this branch to try before reviewing. When Leo started I got this error message (Leo seems to be working all right):

  File "c:\Tom\git\leo-editor\leo\core\leoConfig.py", line 2109, in visitNode
    return f(p, kind, name, val)  # type:ignore
           ^^^^^^^^^^^^^^^^^^^^^

  File "c:\Tom\git\leo-editor\leo\core\leoConfig.py", line 404, in doMenuat
    ans = self.patchMenuTree(mlist, targetPath)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  File "c:\Tom\git\leo-editor\leo\core\leoConfig.py", line 478, in patchMenuTree
    ans = self.patchMenuTree(val, targetPath, path=path + '/' + name)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  File "c:\Tom\git\leo-editor\leo\core\leoConfig.py", line 478, in patchMenuTree
    ans = self.patchMenuTree(val, targetPath, path=path + '/' + name)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  File "c:\Tom\git\leo-editor\leo\core\leoConfig.py", line 467, in patchMenuTree
    kind, val, val2 = z
    ^^^^^^^^^^^^^^^

ValueError: not enough values to unpack (expected 3, got 1)

Some time later, I noticed this one:
createMenuFromConfigList can not happen: bad kind: @ifplatform

On the devel branch last night, the @ifplatform worked as expected - I got a different submenu on Linux than on Windows.

Leo 6.7.9-devel, ekr-3871-search-settings branch, build bfec235001
2024-05-27 05:06:16 -0500
Python 3.12.3, PyQt version 6.6.2
Windows 10 AMD64 (build 10.0.19045) SP0

[edreamleo]

@tbpassin Thanks for your testing.

The crashes you report have nothing to do with this issue. You may file a separate issue if you like.

[tbpassin]

The crashes you report have nothing to do with this issue

: ) I knew that but mentioned it in case you recognized having made a change recently.

I'm just now exercising the branch before reviewing the code.

[edreamleo]

@tbpassin I haven't touched any menu code in awhile.

My guess: your issue might be a lapse in detecting user errors.

[tbpassin]

leoFind.py

Lines 572 ff # Look for alternate matches only if there are no exact matches.

I wonder if this is worth the extra time it takes when there is no match. Of course, no-match shouldn't occur very often, so maybe it's a moot point.

Lines 627 ff -

        # The Nav pane can show only one match, so issue a warning.
        if len(unique_matches) > 1:
            g.es_print(f"Multiple matches for {word}", color='red')
            for z in unique_matches[1:]:
                g.es_print(z)
        # Put the first match in the Nav pane's edit widget and update.
        x.clear()
        e.setText(unique_matches[0])
        c.frame.log.selectTab('Nav')

I suppose this is to handle the case when more than one kind of hit happens (e.g., def vs Class), is that right? I can understand why the code is in here, but it's going to be weird to have the log pane flash the message and then the view will switch right back to the Nav pane. I don't have a solution to offer right now but I think we should keep trying to find one.

Otherwise I didn't notice anything to comment on. Very nice work! I'm elated to see the results in the Nav pane. The very first thing I tried is to CTRL-click on c.free_layout.get_top_splitter(). The two places I knew about from earlier showed up in the Nav pane as desired.

[edreamleo]

@tbpassin Thanks for your approval.

Not searching for alternates makes a noticeable difference.