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

Console ME over slow network

Expand Messages
  • Bryan Schofield
    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
    Message 1 of 5 , May 23 12:27 PM
    • 0 Attachment
      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
    • Jon Green
      ... 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
      Message 2 of 5 , May 23 2:45 PM
      • 0 Attachment
        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.
      • 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 3 of 5 , May 24 7:18 AM
        • 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 4 of 5 , May 27 5:52 AM
          • 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 5 of 5 , May 27 6:24 AM
            • 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.