List and search local symbols macro

[Graeme]

Hi guys

This is a great effort.  I don't think I deserve the comment about the GUI thing ... but thanks.

I don't like to report problems but I guess you'd rather know ... (they're relatively minor).

Using the 4.02 hotfix including the new tagwin.e and slick 12.0.3

The first time I tried enabling "show return type" I got a slick stack (added below)  - seems to be on the call to _TreeSetCaption in the function update_return_type().

After restarting slick, the first use of ols always comes up with "show return type" enabled  - you can turn it off ok but it always comes back when you restart slick.

After restarting slick a couple of times to test this return type thing a couple of glitches happened  - firstly the ols list showed the tags for open_local_symbol but had hotfix.e listed in its title bar and hotfix.e was the file that was actually the current buffer;  then another time the preview toolbar was stepping through the tags for hotfix.e but the ols dialog was showing me the symbols for open_local_symbol.e and had open_local_symbol.e in its title bar.  I seem to be able to reproduce these problems by turning "show return type" on and off  - let me know if you can't reproduce and maybe I could try and debug it sometime.

Anyway, I don't like to complain coz this is a great macro  - thanks for posting it.

Here's that stack dump  - probably if I'd restarted slick after loading the hotfix and before running ols it wouldn't have happened because it was just the very first time that I enabled "show return type" that it crashed.

Graeme

Code: [Select]

Slick-C STACK TRACE ******************************
 Created on 11/28/2007 at 22:5:20 (546 ms)
 SlickEdit Version 12.0.3.0 Copyright 1988-2007 SlickEdit Inc.
 Edit module and type "st -f <offset>" to get the
 run-time error position

 error code=-2073
 This property or method is not allowed on this object

open_local_symbol.ex 1406 static()   p_window_id: 122   p_object: OI_LABEL   p_name: symbol_name
open_local_symbol.ex 3072 _ols_on_key_show_return_type_toggle()
   p_window_id: 122
   p_object: OI_LABEL
   p_name: symbol_name
open_local_symbol.ex 4409 ols_menu_cmd(_ols_on_key_show_return_type_toggle)
   p_window_id: 122
   p_object: OI_LABEL
   p_name: symbol_name
dlgeditv.ex 7360 show(-modal -mdi -xy open_local_symbol)   p_window_id: 12   p_object: OI_FORM   p_name:
open_local_symbol.ex 6372 ols()   p_window_id: 12   p_object: OI_FORM   p_name:
stdcmds.ex 6462 command_execute()   p_window_id: 12   p_object: OI_FORM   p_name:
stdcmds.ex 6687 split_insert_line()   p_window_id: 4   p_object: OI_TEXT_BOX   p_name:
stdprocs.ex 6508 try_calling(1072)   p_window_id: 4   p_object: OI_TEXT_BOX   p_name:
stdprocs.ex 9409 call_root_key("

[hs2]

Thanks for the valueable feedback Graeme !
Think I found the reason of the stack-dump. In case you want to hotfix the 'hotfix' just add 'symbols.' to '_TreeSetCaption'

Code: [Select]

      symbols._TreeSetCaption( index, name );

The other problems are caused by a 'sync problem' of the current buffer <-> current context.
(Would be very helpful to have a rough idea about how the tagging engine does it's magic work e.g. maintaining the contexts...)
Thought that there is no (more) problem with that but it's obviously not stable/robust enough.
I'll take care about it a bit later today and post a v4.0.3.

BTW: I've also added that the target symbol is auto-expanded in case it's hidden. (This is useful if you use e.g. 'show-current-proc' and goto to another symbol.)

Thanks, HS2

[hs2]

Ok - I think / hope that I could solve the issues.
I'm not sure about the current buffer <-> current context fix since it didn't occur here even when I tested the ols v4.0.2...
See attached v4.0.3.
Have fun,
HS2

[hs2]

Hi, I've updated open_local_symbol.e to v4.0.6 which now supports SE v12.0.3 and SE v13.0.0.
When using this module on v12.0.3 I'd recommened to install the hotfix pack due a useful patch to 'tagwin.e' related to the Preview TB.
This is not longer neccessary when using SE >= v13.0.0 because Dennis (HP++) implemented a really nice solution for this type of Preview TB problems.
There were a few minor changes:

- dialog is now non-modal which allows e.g. to scroll/use the Preview TB even when the dialog is shown
+ along with that there is a new option: 'Dismiss on goto tag' [default: ON]
  (I should better convert the dialog to a real tool window...if I find some time)

- using an adaptive timer depending on number of visible tags/symbols for tree update
  This should provide a better user experience even with files containing a HUGE number of symbols as 'slick.sh'...

- I've added a 1 level history: the last filter text and the settings are restored on <TAB>
  If the dialog was cancelled maybe entered filter text or changed settings are not saved to this 'history'.

- minor bugfixes + using the method to retrieve tags of the current buffer recommend by Dennis (could be a bit faster)

Edit:
- goto line support (enter line number as filter text)

ToDo:
- finish 'show references' feature
- implement clipboard support (paste filter text)

Have fun,
HS2

[hs2]

Hi, I've updated open_local_symbol.e to v4.0.7.

• 'References' can now be activated for the currently selected symbol via context menu (<r-click> / <ALT-M> + 'R') or
  directly using <ALT-R> shortcut.
  The dialog is not dismissed when finding references this way so it's possible to check references of multiple symbols.
  A running reference scan is stopped by pressing any key (e.g. cursor keys).
  There is an additional shortcut <CTRL-SHIFT-ENTER> to quit the dialog, show the references of the current symbol
  and go to the first occurence. A bookmark is left at the position of the symbol in the current buffer to flip back easily.
• added 'Activate Preview TB' to the context menu along with the associated direct shortcut <ALT-W>.
  This might be useful if 'Auto-activate Preview TB' is OFF.
• added support for 'double-click' with modifiers pressed
• fixed a few minor issues with accidentally activating Preview TB

I've seen VERY RARE situations, where the tag context was not updated correctly (empty) on v12.0.3.
(When this happend also the Defs TB didn't show any symbol.)
So it's changed back to the original method which seems to ALWAYS work.

HS2

[Clark]

Just thought I would mention that there is a "gt" command but it searches more than the current file (ex.  gt /main  OR  gt/?*main/r). Also, the Find Symbol tool window searches more than just the current file but you can change it to just search the current file.

[hs2]

Thanks Clark, but I know...
It's basically a replacement for 'list-tags'. HS2

[mikesart]

Hi hs2.

I'm using your latest ols (v4.0.7 (SE >= v12.0.3)) with SE v13.0.0.0 and every so often something goes horribly wrong and I get a never ending stream of dialog boxes saying:

  Invalidate argument
  file=open_local_symbol2.ex offset=297

The single line on the callstack is:

  open_local_symbol2.ex 297 open_local_symbol2:ReInitTimerCallback(235)   p_window_id: 5   p_object: OI_FORM   p_name:

I managed to sneak a double click in there between all the dialog boxes and I believe it's complaining about the p_window_id = ols_wid line. It also starts right back up when I close and re-open SE. Not sure what the secret sauce is to get it to stop happening once it's started, but a combination of closing all the files, re-loading open_local_symbol2.e seems, and restarting SE seems to eventually work.

I'm also not sure what causes it to start happening. I've stuck a little say() command right before the assignment to see what ols_wid is for the next time this occurs. If you have any other debugging suggestions I'd love to hear em.

Thanks much!
 -Mike

Code: [Select]

static void ReInitTimerCallback ( int ols_wid )
{
   _kill_timer ( _ols_ReInitTimerId ); _ols_ReInitTimerId = -1;
   orig_wid := p_window_id;
   p_window_id = ols_wid;                                       <---------------
   init_tree ( def_ols_tag_filter, OLS_INIT_TREE_INITIAL );
   p_window_id = orig_wid;
}


[hs2]

Oops - I'll take care about it in a few minutes - stay tuned HS2

[hs2]

Hi Mike,
part 1: fix to solve the re-occuring stack dump after SE restart:
Could you please apply this patch to the module ?
change:
- moved some init's from defload() to (new) definit() entry

Code: [Select]

////////////////////////////////////////////////////////////////////////////////////////////////
definit()
{
   if (arg(1)!='L')
   {
      // better init all statics on editor invocation
      _ols_cur_buf_name    = '';
      _ols_cur_tree_index  = -1;

      _ols_num_context     = 0;
      _ols_num_tags        = 0;
      _ols_cur_context_id  = 0;

      _ols_PreviewTimerId  = -1;
      _ols_UpdateTimerId   = -1;
      _ols_ReInitTimerId   = -1;

      _ols_window_id       = -1;

      _ols_use_tagwin      = false;

      _ols_last_cfg.flags         = def_ols_flags;
      _ols_last_cfg.tag_filter    = def_ols_tag_filter;
      _ols_last_cfg.filter_text   = OLS_EOS;
      prev_ols_cfg = curr_ols_cfg = _ols_last_cfg;
   }
}

defload()
{
   // try to close dialog on re-load if it's still hanging around (not dismissed)
   // HS2-2DO: Even after closing the dialog I'm getting an 'Invalid Function pointer' stack dump ???
   //          The 'Invalid Function pointer' always occurs if the module was recompiled due to changes.
   formwid := _find_formobj(OLS_FORM_NAME);
   if ( formwid > 0 )   formwid._ols_goto_tag( true );

   // HS2-CHG: (old) proposal to avoid unintended idle update of the 'Preview TB'
   // @see tagwin.e - _UpdateTagWindow()
   #if __VERSION__<13
   // check if 'tagwin.e' patch was applied
   int index = find_index( 'maybe_add_tagwin_noupdate_form', PROC_TYPE );
   if ( index ) call_index( OLS_FORM_NAME, index );
   #endif
}

Sorry, but it'd be nice if you could tell me some more details when the 'ols' goes crazy.
Do you use mult. edit windows ? Which other dialog boxes are open ?
Did you switch/close buffers while the dialog was visible ?
And could you post the value of 'def_ols_flags' ?
Please do a 'set-var def_ols_flags' on commandline and just copy'n post it or better send me a message.

Needless to say that with the way I'm using SE the problem didn't occur until now...
But for sure there is a bug which has to be fixed !

Thanks, HS2

[mikesart]

I really wish I could give you more information about what causes this but it's extremely sporadic. I've been using ols() since it was first posted and even got the original one working with v13 before you submitted your last update. I use it a lot (love it!) and this has only happened three times. I've tried all kinds of things to repro it after it happens but it's not having any. That's the reason I didn't submit this the first two times - not much data. I was kind of hoping you'd just spot the issue :d or there might be some places in the code I could sprinkle some debug squirties to help narrow it down.

In any case, I got your changes in. I'll keep poking around and post with any new data I can come up with. Thanks HS2 - appreciate all your help yet again.
 -Mike

[hs2]

Ok - I've changed a couple of things which seemed a bit fragile to me and added an improvement in the '_switch_buffer_' callback.
I've made some tests and I didn't notice any problem.
So I hope the attached v4.0.8 solves the problems you've encountered as well.

Thanks again for your help,
HS2

[chrisant]

I upgraded from open_local_symbol.e v4.0.6 to v4.0.8.
4.0.8 seems to have introduced a problem with auto-hide toolbars:

Relevant config settings:

• def_toolbar_autohide_delay=1500;
• Bottom side auto-hide toolbars:  Search Results, Preview, References, Clipboards, Build, Message List, Output.
• Right side auto-hide toolbars:  Files, Projects, Open.

Baseline repro of proper auto-hide with v4.0.6:
1.  Open open_local_symbol.e v4.0.6.
2.  Load Module (F12 in the default config, I think).
3.  Hover mouse over the Preview toolbar's tab.
-->  Preview toolbar unhides.
4.  Move mouse over the main editing window.
-->  Preview toolbar auto-hides.
5.  Invoke the ols command.
-->  OLS dialog pops up and Preview toolbar unhides.
6.  Press Escape to dismiss the OLS dialog.
-->  OLS dialog closes and Preview toolbar auto-hides.
7.  Do steps 3 & 4 again; results are the same as before.

Repro for problem with v4.0.8:
1.  Open open_local_symbol.e v4.0.8.
2.  Load Module.
3.  Hover mouse over the Preview toolbar's tab.
-->  Preview toolbar unhides.
4.  Move mouse over the main editing window.
-->  Preview toolbar auto-hides.
5.  Invoke the ols command.
-->  OLS dialog pops up and Preview toolbar unhides.
6.  Press Escape to dismiss the OLS dialog.
-->  OLS dialog closes but Preview toolbar does not auto-hide.
7.  Do steps 3 & 4 again; do the steps 3 & 4 for the Preview toolbar, and for the Output toolbar.
-->  Pretty quickly the auto-hide toolbars get stuck in the unhidden state, and won't auto-hide.
8.  At the SE command line type "set-var def_toolbar_autohide_delay" and it reports that the value is 2147483647.

Diagnosis:
I inserted some say() lines where orig_autohide_delay gets set/restored, and the problem appears to be because both on_create and on_got_focus set orig_autohide_delay, but both of those get called when the ols window gets created, so the true orig value ends up getting overwritten with the MAXINT value.

A Possible Fix:
1.  If the condition for restoring the orig value were "if ( def_toolbar_autohide_delay != orig_autohide_delay && def_toolbar_autohide_delay == MAXINT )", then the restore wouldn't overwrite an intentional change the user might have made to the setting while the ols dialog is up.
2.  If a boolean is used to guard the orig value (e.g. "is_orig_value_saved"), it can avoid saving the def value multiple times and avoid accidentally overwriting an already-saved value.  Should then also check the boolean when determining whether to restore the saved orig value.

See attached file for possible implementation of the possible fix.

[hs2]

Argh - I knew that there are still some problems with the new non-modal behaviour...
I think the root cause problem was a missing state check in the on_got_focus handler.
I did some regression testing and it seems to work now. See attached the bug fix release v4.0.8.1

Thanks for your help chrisant !
HS2

Edit: Minor update to v4.0.8.4

[asandler]

Hi all.

I'd like to propose and discuss with you a new feature for the ols. Here's the scenario. Lets say we have C++ file with lots of methods. In it, there are several methods that start with write. For instance:

write()
write_all()
write_tomorrow()
write_before_you_leave()
just_write()
write_damn_you()
write_slowly()
write_faster()

In ols, typing write would leave these functions in search result (and filter out everything else). But lets say I'd like to have a way to refine ols search criteria to match only write(). With all other functions, I can add one more word to match the function exactly, but in case of write() I can't do it.

To tackle this issue, I propose that we add a new special syntax. We mark the word we're looking for with ! (exclamation mark). When ols sees a word with !, instead of searching for the exact word, it will search for [^a-zA-Z0-9_]word[^a-zA-Z0-9_] - i.e. it will search for the exact word and not a word as part of function name.
(in case I made a mistake in the regular expression, the regex should match word that doesn't have a-z A-Z 0-9 and _ before and after itself).

Some notes:
1. This entire thing has meaning only if you are looking for a function those name consists of one word. So, searching for something like "slowly write!" won't produce any result, but it really shouldn't produce any result, so its ok.
2. Searching for .*word.* won't work because this won't match class_name::write().
3. I am not sure about it, but ! may already have some special meaning. In case it does, we may use some other symbol. ! seems the most natural for this purpose though.