🚀 go-pugleaf

Brian Fox writes:
>> Whoops.  No, there are no user-level generic keymap manipulation
>> commands.  This is an interesting situation, and I haven't yet decided
>> what to do about it.

In addition to user-level keymap manipulation commands I would also
like to see a builtin which can list the current keymap, similar to
the GNU Emacs C-h B command.  This can be a great help especially to
novice users.  It gives them a way to find out about commands they
don't know about and to find out where others they do know about are
located.

>>    also, what is the extent of the keymaps and bindings? Can one bind a key
>>    to a bash function?
>> 
>> No, although this wouldn't be to difficult to implement.  Votes please.

I would vote for both user level keymap manipulation commands and for
binding bash functions to keystrokes.  I have already had users ask me
for both.

		--Jim Dempsey--
		BBN Communications
		jjd@bbn.com (ARPA Internet)
                ..!{decvax, harvard, wjh12, linus}!bbn!jjd

1. Also, what is the extent of the keymaps and bindings? Can one bind a key to
1. a bash function?

2. No, although this wouldn't be to difficult to implement.  Votes please.

I think it would be more powerful to bind keys to any text sequence:
	bind meta-K to ^Jlogout^J
for example.

Again, I'd really love the ability to do TCSH-style "bind" commands in
BASH; having to do my edit bindings by doing "vi ~/.inputrc ; exec bash"
is a real lose.
	/r$
-- 
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.

	From:  bfox@aurel.caltech.EDU
	Date:  Fri, 4 Aug 89 11:35:35 PDT

      Also, what is the extent of the keymaps and bindings? Can one bind a key 
to
      a bash function?

   No, although this wouldn't be to difficult to implement.  Votes please.

My vote is certainly for something like this.  It is a feature I have
long looked forward to in a shell.

Other features I expect to find are the ability to do interactive key
binding, and to bind to `key sequences' - that is, to have
heirarchical keymaps like emacs (so I can bind to C-X C-A if I want).

In fact, along with a few others here, I wanted these features so much
that I decided to see what sort of effort would be required to
implement them.  A readline keymap is currently a 256-element array of
pointers to (C) functions; I've effectively made it an array of unions
with a type field and a pointer.  This allows me to bind keys to
things other than readline functions, in particular I can bind a key
to a keymap, so in my (renamed) .inputrc, I can write

bind \C-X\C-X accept-line
bind \F-ku previous-history

The latter causes `ku' to be looked up (in the TERMCAP) at startup
time and binds the function to the appropriate string of keys (I'm
rather proud of this!).  Note that I haven't actually done binding to
shell functions yet (macros would actually be much easier, and might
have better semantics), although I have lots of ideas to talk about.

I've only made this work under More/BSD on an HP300 (should of course
be OK on any BSD system) - i.e. I haven't thought about terminfo.
I've included the comment from the start of my readline.c; I'd be
pleased to see some feedback on whether people think any of my
ideas/code are interesting or useful.


/* readline.c -- a general facility for reading lines of input
   with emacs style editing and completion. */

/* 
 * This version of readline has been massively modified by rgn, Ray
 * Nickson, nickson@comp.vuw.ac.nz.  It is based on the version of
 * readline distributed with bash-1.02.  It differs from standard readline
 * in the following ways:
 *  1. I allow keymaps within keymaps; for example, the keymap entry for
 *     control-X can itself be a keymap, so the user can bind a function
 *     to control-X control-A.
 *  2. I think we should give readline complete control of  the
 *     keyboard.  To this end, I save the UNIX terminal driver special
 *     characters (the tchars, like ERASE, SUSP etc) before going into
 *     readline, remove their special meaning, and then restore tham
 *     on exit.  To achieve the old behaviour, I supply the readline
 *     functions `signal-interrupt', `signal-stop' and `signal-quit',
 *     which the user binds to the keys of her choice.
 *  3. I've massively changed the format of (and renamed) the startup
 *     file (was ~/.inputrc).  Read the comment before the
 *     `rl_read_init_file' for details.  I'll supply an
 *     emacs-lisp program to convert an inputrc to a keymaprc.
 *     Important extensions allow binding to key sequences (instead of
 *     just single keystrokes), and the use of termcap names for
 *     function keys. 
 *  4. I advertise a function to allow readline's caller to
 *     interactively change bindings, without knowing about readline's
 *     internal structure.
 *  5. It should be possible to add new facilities (`keyboard macros';
 *     binding to things that have meaning to readline's caller, but
 *     not to readline [such as shell functions] etc.) more easily
 *     than is the case with standard readline.
 *  6. I haven't done vi mode; I don't think it would be excessively
 *     hard to do.
 *  7. I haven't tried to make it work with terminfo; what I have
 *     done has been tried only on BSD.
 */

-rgn
--
Ray Nickson, Dept. Comp. Sci., Victoria University of Wellington, New Zealand.
nickson@comp.vuw.ac.nz       ...!uunet!vuwcomp!nickson      + 64 4 721000x8593