SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2014 v19 beta => Topic started by: PurdueEEGrad on October 29, 2014, 05:53:56 PM
-
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?
-
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:
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.
-
I'll test this out on the new release candidate - and post the results when done.
-
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.