tcsh-like intelligent history search keybindings

tcsh-like intelligent history search keybindings

[Ed Peschko]

hey all,

I thought this would be a no-brainer, but apparently not.

I'd like gdb to behave like tcsh - I have the settings:

    bindkey -k up history-search-backward
    bindkey -k down history-search-forward

set in my .tcshrc. This makes it so that when I type:

	p<up arrow>

the command scrolls through my history, looking for commands that start with 
the letter 'p'. 'pe' == commands that begin with pe, etc.

I was assuming I could do the same thing with gdb with the ~/.inputrc file, ie:
putting the following entries in:

    "\M-OA": reverse-search-history
    "\M-OB": forward-search-history
 
    "\M-\C-OA": reverse-search-history
    "\M-\C-OB": forward-search-history

    "\M-\C-[A": reverse-search-history
    "\M-\C-[B": forward-search-history

But apparently not. So I had the following questions:

    1) what is the shortcut for the up and down arrow? ie:
       TAB: points to the tab key, RET: to return, etc. Not having a shortcut
       to the arrow keys seems a strange omission.

    2) is the above the right syntax to override the current default values
       for up arrow (which is to scroll through the history, one at a time 
       not caring whether or not the first characters match or not.

    3) is there a way to anchor 'reverse-search-history' to the beginning of 
       the search string. Ie: I want 'p<up>' to match all commands *beginning*
       with p, not commands *containing* p.

       
And finally, why isn't this the default behavior of <up> and <down> IMO its a 
lot more useful than the current behavior, which makes people hit the up arrow
scores of times to get back to an ever expanding history...

Ed

(ps - is there a way to make histories dependent on the name of the executable
being debugged, and a way to do this transparently?

ie: if I'm debugging executable_a, I want the arrow going up and down only to 
deal with executable_a history items, and executable_b to deal with executable_b
history items.

Again, this would be really helpful, IMO - if for example there was a switch
to turn this behaviour on and off when gdb is first executed, something 
like:

set executable-history on

or somesuch.
)