Ilya Zakharevich on Tue, 26 Nov 2002 12:51:38 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PATCH CVS] Readline improvements

On Tue, Nov 26, 2002 at 06:41:56PM +0100, Karim BELABAS wrote:
> >   a) Restores the historic behaviour of TAB (insert the template for
> >      function arguments), if one wants help, press F1 or M-h;
> I had removed it after receiving some complaints:
> 1) it is all too common to hit TAB once to many and get arguments inserted
> without wanting it.

??? Just do what you do with any other key: press Alt-Backspace.

> 2) with default keymaps and common keyboard layouts, undoing is awkward
> ( Control + Shift + - ). The people who complained did not even know undoing
> was possible (and they erased templates character by character).

So fix the default keymap; what is the problem?  Anyway, with the new
default(readline) it is easy to make this behaviour conditional...

> 3) what is the purpose of inserting templates, when actual parameters will
> have in 99.99% of cases a different name ?

I find it indispensable to have the info about the order of arguments
without a need to look at a different part of the screen.

> Actually, I just noticed that <F1> works fine on my home machines (Linux + PC
> US keyboard), but not in my office environment (Solaris + generic X terminal
> keyboard). I need to add something like
>   KSbind("24z", rl_short_help,  emacs_standard_keymap); /* F1, xterm */
> to gp_rl.c to make it work out of the box.

I'm waiting for my patches to be included to insert the next batch of
readline improvements; including sane bindings for all the normal keys
(End, Prior, Meta-Left, Control-Right etc).  BTW, anybody having a
snippet of code how not to overwrite keys in .inputrc?

> >   b) make default(readline,4) and default(readline,2) etc. switch the
> >      electric TAB (as above) and electric-parens settings;
> Hum. The idea was that all readline-specific settings go to .inputrc

This "idea" is absolutely broken.  I see no reason why we should
support a broken API when we have something much better...

> >   e) Beginning of support for Mouse-Editing in xterm (see
> >
> >
> >      Currently we support the 2004 setting by interpreting F200/F201
> >      as signals to switch off/back electric parens.  In particular,
> >      one can have default(readline,2) *and* cut-and-paste in new xterm
> >      without bad interactions (if one enables 2004 before entering gp).
> I do not understand how this is used. I just downloaded Dickey's xterm-170,
> compiled with the -DOPT_READLINE flag, but nothing happens when I click
> around.

To have *full* support, a little bit of tweaking for xterm and GP is
needed.  But to have 95% of it, just emit the sequences mentioned in
my post (e.g., before starting gp):


To switch it back, emit


`s' stores the old setting, `h' enables, `r' restores the old setting.
I do not remember whether 2006 is needed with GNU readline - but
anyway, we do not have a full support of readline input with embedded
newlines now.  [*]

[I got this idea when observing Don Zagier using both keyboard and
mouse in one of sun tools (do not remember which).  It took more than
a year to propagate the code to all the source trees...]

I repeat here the definitions:

#define SET_BUTTON1_MOVE_POINT      2001 /* click1 emit Esc seq to move point*/
#define SET_BUTTON2_MOVE_POINT      2002 /* press2 emit Esc seq to move point*/
#define SET_DBUTTON3_DELETE         2003 /* Double click-3 deletes */
#define SET_PASTE_IN_BRACKET        2004 /* Surround paste by escapes */
#define SET_PASTE_QUOTE             2005 /* Quote each char during paste */
#define SET_PASTE_LITERAL_NL        2006 /* Paste "\n" as C-j */

2001 on:        click-1 "moves point"
2002 on:        click-2 "moves point" before doing paste
2003 on:        double-click-3 "moves point" to the end of selection, then
                emits enough BackSpace characters to erase the selection
2004 on:        Emits escape sequences for F200/F201 before/after doing paste
2005 on:        When pasting, emit quote-char before any pasted char.
2006 on:        When pasting, emit "\n" as C-j (usually emits C-m)

[*] How to treat it?  Is it sane to implicitly inclose it in {} ?