* Cameron Simpson <c...@zip.com.au> [120611 07:20]:
> On 10Jun2012 17:41, John Magolske <listm...@b79.net> wrote:
> | [...] when I accidentally press & hold down the <right> key
> | instead of the <Down> key and go flying through a bunch of
> | messages at a rate somewhat related to the keyboard repeat rate
> | (which I have set very high). What I would find ideal is if there
> | were some way to set <right> to go to the next entry and wait, so
> | that for example cycling through five entries would require five
> | distinct key presses.

> It does occur to me that you could do something cunning with your
> terminfo definitions. IIRC, curses watches the timing of incoming bytes
> to distinguish certain things. Since curses delivers a bare ESC if you
> just tap escape, and the other keys send ESC-blah-blah, curses
> distinguishes them by the delay after a "real" ESC. In principle you
> could make your terminfo entry describe some unused keystroke as having
> the escape sequence send by two <right>s in succession. In this way
> curses might present your autorepeated <right>s as the other key, and
> only send a real <right> when you tap it once.

Interesting idea...if it did work, would it not mess up autorepeated
<right>s across the board? For example, when positioning the text
cursor in ELinks I'd still like to be able to hold down <right> and
have the cursor zip along at the keyboard repeat rate. Losing the
ability to do that would be a big drawback.

I'm still wondering if there might be a way to construct a macro that
would call <next-entry> then maybe an external script that "stalls"
until another keypress is issued. The showkey command shows this when
pressing & releasing the <right> key:

    keycode 106 press
    keycode 106 release

I'm wondering if there's a way to differentiate the "press" and
"release" events here in a script that gets called by a macro...

> Following this, "man terminfo" tells us:
> 
>   key_right    kcuf1      kr     right-arrow key
> 
> and on a terminal here, this command:
> 
>   infocmp $TERM | grep kcuf1
> 
> says:
> 
>   kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
> 
> So maybe you could add:
> 
>   kMSG=\EOC\EOC,
> 
> to your terminfo (supplanting "shifted message key").

Thanks for writing this up, may play around with terminfo some & see
what I can do with it.

Regards,

John

-- 
John Magolske
http://B79.net/contact

Reply via email to