Disable incremental search in Find Symbols?

[ahodsdon]

Is there a way to disable incremental search in the "Find Symbols" dialog? I ask because if I type "Foo::" and pause ever-so-slightly before continuing, SlickEdit will go off into la-la land for 10 seconds or so while it populates the search results field with everything under the sun. :-( Pressing Esc during this time period unfortunately does nothing.

I guess if anyone had any tips for making incremental search work fast, that would work, too :-)

BTW: For those keeping track: Yes, Qualified search (e.g. CFoo::Bar) suddenly started working for me. Dunno what I did, but I just tried it after upgrading to 12.0.0.2 and it worked.

--Anthony

[Ding Zhaojie]

1. you can adjust the typing delay a little longer:
tagfind.e L:30:

Code: [Select]

#define FIND_SYMBOL_TIMER_DELAY_MS 100the default value is 100ms, you can try to change it to 500ms, so SE will search for tags after you stopped typing over 0.5s.

2. just disable the incremental search:
(1). find ctl_search_for.on_change function (tagfind.e, L478), comment the whole function;
(2). change ctl_search_for.enter() like this (tagfind.e, L493):

Code: [Select]

void ctl_search_for.enter()
{
   updateSearchResultsNoDelay();

   if (ctl_symbols._TreeGetFirstChildIndex(TREE_ROOT_INDEX) < 0) {
      //updateSearchResultsNoDelay();
   } else if (ctl_symbols._TreeGetNumChildren(TREE_ROOT_INDEX) == 1) {
      call_event(ctl_goto_symbol.p_window_id, LBUTTON_UP);
      maybeHideFindSymbol();
   } else {
      ctl_symbols._set_focus();
   }
}
Now it will do search only after you pressed the enter key.

Have fun

[ahodsdon]

Thanks! Option 2 worked great.

It would still be very useful to have this be an option in the UI... :-)

--Anthony

[hs2]

@Ding Cool patch again !
@ahodsdon: It's not always a good idea to add everything which can be configured to the UI b/c there is already a huge number of config items. But there is already a number of special/rarely used settings which can be changed on cmdline.
Just as an example see the configurable version of Ding's patch below offering the choice to disable inc. symbol search for e.g. huge projects and to re-enable it for smaller ones.

Code: [Select]

// use 'set-var def_find_symbol_incremental 0' or '1' on cmdline to disbale or enable
boolean def_find_symbol_incremental = true;
/**
 * Reset timer to do search if text changes.
 */
void ctl_search_for.on_change(int reason)
{
   if ( def_find_symbol_incremental ) updateSearchResultsDelayed();
}

and

Code: [Select]

void ctl_search_for.enter()
{
   if ( !def_find_symbol_incremental || (ctl_symbols._TreeGetFirstChildIndex(TREE_ROOT_INDEX) < 0) ) {
      updateSearchResultsNoDelay();
   }

   if (ctl_symbols._TreeGetNumChildren(TREE_ROOT_INDEX) == 1) {
      call_event(ctl_goto_symbol.p_window_id, LBUTTON_UP);
      maybeHideFindSymbol();
   } else {
      ctl_symbols._set_focus();
   }
}

Edit: Small change ctl_search_for.enter (splitted 'if - else if')

HS2

[ahodsdon]

That's true... A checkbox for everything under the sun can quickly get unwieldy. I guess my main concern is updating SE and losing all the accumulated patches I've been making. If the SE team could add a global along the lines of what you describe that would get me 90% of the way there.

Thanks!

--Anthony

[jbhurst]

This discussion is interesting.

For what it's worth, I frequently blow away my config directory and start from clean. But I am careful to have virtually all of my customizations automated in Slick-C source, so I can recreate my preferences easily. I've been using SlickEdit many years and on many different machines, so it's important for me to be able to do that.

I tend to avoid customizations where I have to change supplied macro sources. I am more than happy to code settings for macro variables in a Slick-C file, or calls to _default_option() or whatever. But I don't like to change the supplied sources, because of the forking issue.

An example of a change to the supplied source that I do make (occasionally) is amending the list of allowed commands in DIFFzilla. I'd really like it if this list were somehow externalized so I could change it programatically in my config code.

So I would argue that adding a global for this kind of thing is a good idea, much better than having to patch sources.

Regards

John Hurst
Wellington, New Zealand

[assafb]

Agree with John here.

With >40K files in my proj, find-symbol feature is unusable for me due to the incremental search.

We should have this configurable either from UI or by setting a macro.

Thanks,
Assaf

[hs2]

I fully agree that it's a good idea that the 'configurability' should be added to the product to avoid the need of merging in this customization everytime upgrades or hotfixes are installed.
BTW I'm following the same strategy as John to keep the number of product source patches as low as possible.
But this is not always possible (e.g. the DiffZilla command support - which has been improved in v12.02).

I only tried to say that not everything should be added to the config UI.
Regarding the 'Find Symbol' I'm sure the default behaviour is ok for most or quite a lot users out there. But as already mentioned for huge projects the 'find on demand' is surely better.
So I think the agreed feature request is an implementation similar to the patch or an add. checkbox in the 'Search options' of the toolbar (IMHO not the best solution).
However, it's a simple change and could be added to the next official hotfix pack.

Regards,
HS2