Keybinding : Scope of Operation : Search Result Pane - Binding does NOT work

[PurdueEEGrad]

Use Case : Keyboard selection of search results text - and moving that text to some file/buffer

Note I do not want to use a mouse in the situation described herein. I
just use the keyboard. 

I often take Slickedit Search results - copy the text - and put it
somewhere to do something else with it. 

My custom keymap bindings - that I use to navigate the cursor - do not
work in the SE search result window - because of the following keybinding.

def  'C-M'= bottom_of_buffer

The above keymap fragment - works great in the edit buffer windows.

When I try to use the keybinding above - in the search result pane -
it does not work correctly (ie; Cursor does NOT move to the bottom
of the search result window).

Since the search results are just text : And SE is a 'text editor' : Would
it be possible to ensure a consistent SE behavior - relative to key
bindings - across any window that contains text - that can be edited,
copied or moved? 

My other key bindings, however, DO WORK just fine in the search result
pane.  For example - the key bindings below work OK. 

def  'C-N'= top_of_buffer

def  'C-K'= cursor_up
def  'C-L'= cursor_down
def  'C-H'= cursor_left
def  'C-J'= cursor_right

def  'C-I'= cbacktab
def  'C-O'= ctab

def  'C-U'= page_down
def  'C-Y'= page_up

For some reason - ['C-M'= bottom_of_buffer] - does not work in the search
result pane (I am using beta 6). 

The best thing about Slickedit is the speed - of fingers never leaving the
keyboard. 

Would it be possible to fix this in the next beta release?

.... Or am I missing something?

[Lee]

Search results window has a custom keybinding mode called grep.  If you sort the key bindings (Options > Keyboard and Mouse > Keybindings) by Mode you can see which ones are overriden from default.  You can unbind them there if you wish.  Or you can write your own defeventtab for grep_keys to be used via batch macro:

Code: [Select]

defeventtab grep_keys;
def   'ESC'=;
def   'ENTER'=                grep_enter;
def   'LBUTTON-DOUBLE-CLICK'= grep_lbutton_double_click;
def   'DEL'=                  grep_delete;
def   'S-UP'=                 grep_prev_file;
def   'S-DOWN'=               grep_next_file;
def   'LBUTTON-DOWN'=         grep_cursor;
def   'UP'=                   grep_cursor;
def   'DOWN'=                 grep_cursor;
def   'PGUP'=                 grep_cursor;
def   'PGDN'=                 grep_cursor;
def   'C-UP'=                 preview_cursor_up;
def   'C-DOWN'=               preview_cursor_down;
def   'C_PGUP'=               preview_page_up;
def   'C_PGDN'=               preview_page_down;

Those are default keybindings for grep mode.  You should be careful which ones you override or you may lose existing functionality for search results.

[PurdueEEGrad]

I'll test this out on the new release candidate - and post the results when done.

[PurdueEEGrad]

Lee, I tested out your approach - and it did not work.

I tested the newest version (release candidate - October 28, 2014).

I have attached a keymap test (Test_16 - *.e) - that shows the attempts
and results (of trying out your suggestion).
 
I also attached screen shots of the keymap options - to show that the
testcase loads OK - but the keymap simply does not work in Grep mode
(as defined in Test_16 attached).

In a nutshell - the Grep mode (search pane) edit behaviour - can NOT be
configured to behave like the main edit window (as per the attached
testcase Test_16).

The differences were spotty - in the sense that

[1] [Grep mode - search pane] keybindings - that are unmapped - should simply default to [Default mode - main edit window pane] behavior.

[2] [Grep mode - search pane] unmapped keys - do NOT conform to ALL default behavior (but SOME do).

You can see some examples - at the bottom of the attached testcase
(..Test_16..). 

If I could just get my : 'C-M'= bottom_of_buffer : behavior going - I
would be a happy camper :-)

For now, however, I'll just leave it to the SE dev team - so they are
aware of the issue - regarding keymap conformance between - (1) main edit
windows and (2) search results windows. 

Final note - There is the Left Click - Context Menu - Open as editor
window - alternative to this issue. 

Even so, SE is the fastest editor on the planet - because its focused on
minimal effort to get something done. 

As always, I hope I have not missed something simple or fundamental - in
the attached testcase code. 

It would be nice, long term - to have (A) search pane results - adopt
default edit window behavor - as well as (B) - the ability to remap
default Grep mode behavior - to match SE user keymaps for the main edit
windows. 

Lee : Thanks so much for your advice, however, since I learned more about
SE keymap modality and keybinding behavior in the various SE window
groups :-)

PS. I just loaded the testcase via Macros -> Load Module.

I don't think it matters - relative to a command line load
of a module (SE Batch file) - or a normal SE module load
- using the GUI module load method.