Loading ...
Sorry, an error occurred while loading the content.

RE: [jasspa] Console ME over slow network

Expand Messages
  • Phillips, Steven
    I believe so and changing this one value should change the time used for all (when the time is not explicitly given) although I have not tested this, Steve
    Message 1 of 5 , May 27, 2008
    • 0 Attachment
      I believe so and changing this one value should change the time used for all (when the time is not explicitly given) although I have not tested this,

      From: jasspa@yahoogroups.com [mailto:jasspa@yahoogroups.com] On Behalf Of Bryan Schofield
      Sent: 27 May 2008 13:53
      To: jasspa@yahoogroups.com
      Subject: Re: [jasspa] Console ME over slow network

      Is this meTRANSKEY 250ms value the default time used when creating new
      translate-key bindings?

      On Sat, May 24, 2008 at 10:18 AM, Steven Phillips <bill@jasspa. com> wrote:
      > The quick fix, if you have a compiler, which should solve the problem is
      > to change the default. In termio.c look for the following line:
      > meTRANSKEY TTtransKey={ 0,250,0,ME_ INVALID_KEY, NULL} ;
      > the 250 is the default timer in msec (i.e. quarter of a second. Simply
      > change this to 500 and all keys should wait for half a second as the
      > default is based off this one value. Let us know if this works and we'll
      > look into making this configurable.
      > Steve
      > Jon Green wrote:
      >> Bryan Schofield wrote:
      >> > I'm having to do some work remotely over a painfully slow network. ME
      >> > works great in console mode -- I'm rlogin'ed to a Solaris server.
      >> > However, over the slow connection, sometimes complex key sequences are
      >> > mis-interpreted. For example, pressing F8 sends ^[[19~. Sometimes it
      >> > is properly handled, sometimes it seems be handled as ^[[1 followed by
      >> > a 9~. So what I'm wondering is there something I can do to globally
      >> > increase the threshold for which key sequences are interpreted. I know
      >> > I could redefine every key using
      >> >
      >> > n translate-key
      >> >
      >> > specifying a delay, but I'd rather not.
      >> >
      >> > Thanks in advance.
      >> > -- bryan
      >> Hi Bryan,
      >> We have never seen this (and certainly used to use termcap mode a lot
      >> before we had X-Windows support on SGI platforms in the dim and distant
      >> past).
      >> The key timer variable is not exported or globally accessible, but like
      >> you have determined it is specifiable by over-riding each binding. From
      >> what you said it may be worth our while providing a global 'offset'
      >> parameter to the key timer in the future to allow just such a tweak as
      >> you describe.
      >> I would suggest that your best bet is the n translate-key at the moment
      >> (I assume that X-window mode is out of the question - this would hold
      >> the keys together better). I suggest that you start with the F8 and see
      >> if this makes a difference. The termcap keys are built in but are
      >> defined in eskeys.def in the source files if you want to quickly find
      >> out what the key sequences are - or use this as a basis to hack together
      >> a macro file to extend the times.
      >> Let us know how you get on with this. If there is a case to add a offest
      >> then can do this quite easily after looking at the termcap code - this
      >> might be sufficient to solve your problem. Experiment with the above
      >> first and then we will be able to access whether it will be worth while.
      >> Regards
      >> Jon.

    Your message has been successfully submitted and would be delivered to recipients shortly.