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

Re: [jasspa] Console ME over slow network

Expand Messages
  • Steven Phillips
    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
    Message 1 of 5 , May 24, 2008
    • 0 Attachment
      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.
      >
      >
    • Bryan Schofield
      Is this meTRANSKEY 250ms value the default time used when creating new translate-key bindings?
      Message 2 of 5 , May 27, 2008
      • 0 Attachment
        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@...> 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.
        >>
        >>
        >
        >
      • 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 3 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,
           
          Steve


          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.