Date: Tue, 30 Apr 1996 13:37:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tony@odin.sunquest.com Cc: hackers@freebsd.org Subject: Re: ksh93/bsdi emulation question Message-ID: <199604302037.NAA07771@phaeton.artisoft.com> In-Reply-To: <199604301719.KAA08037@ermintrude.sunquest.com> from "Tony Jones" at Apr 30, 96 10:19:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
> It works really well, except in one odd regard. > > Using the KEYBD trap (for keymappings) isn't working correctly for > multicharacter inputs. > > Assuming I'm trying to map '\E[A' (up arrow key) to 'k' (vi up line), > the problem is that three seperate calls to the KEYBD trap occur, one for > (escape), one for '[' and one for 'A', rather than just one call. > > Since the table is loaded as: keytable[$'\E[A']='k' and referenced > in the trap handler by looking up the keystroke in keytable, this > isn't working too well. > > The ksh manual makes note of the fact that the arguments to escape > must follow within 1/2 sec, but I'd have expected this to be > so since they are generated by a keysrtoke. > > Anyone have any ideas ? Yes. The 1/2 sec is a vtime value. But the vmin is one. The keys are generates as if they were seperate key events. Consider that a pipe can tell the difference between multiple writes to the slave end vs. one write ofr all of the data. This is the same thing. LAT on DECServers have the same problem. Basically, the buffer should be stuffed as a single operation to prevent it acting like three seperate events. If the events are seperable as operations, no matter how quickly they occur, they will be seen seperately. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604302037.NAA07771>