root@investor.pgh.pa.us (Bob Peirce #305) (09/04/89)
I don't know if this happens with any other control characters, but when I dial in from one Telebit to another on "FAST" and run uEmacs, a ^P is not acted upon until after another key is struck. For example, a ^P does nothing. A second ^P causes the cursor to move up two lines. This does not happen if I dial in at a slow speed or if I dial in to a 1200 baud modem, just when it is Telebit to Telebit at high speed. Both dial in ports have the same stty parameters except for baud rate. The high speed port is set to 9600 and the low to 1200. The modem connected to my terminal is set to 19200. Has anybody else encountered this problem? Is there a solution?
grr@cbmvax.UUCP (George Robbins) (09/08/89)
In article <1989Sep4.162531.28089@investor.pgh.pa.us> rbp@investor.pgh.pa.us (Bob Peirce #305) writes: > I don't know if this happens with any other control characters, but > when I dial in from one Telebit to another on "FAST" and run uEmacs, > a ^P is not acted upon until after another key is struck. For example, > a ^P does nothing. A second ^P causes the cursor to move up two lines. You probably have uucp spoofing enabled, since control/p is used as a start of packet character in the uucp protocol. The modem is sniffing to see if you're really uucp and breaks down and sends the second character when it decides you aren't. Disable spoofing for user calls if this is a problem. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
karl@ddsw1.MCS.COM (Karl Denninger) (09/10/89)
In article <1989Sep4.162531.28089@investor.pgh.pa.us> rbp@investor.pgh.pa.us (Bob Peirce #305) writes: >I don't know if this happens with any other control characters, but >when I dial in from one Telebit to another on "FAST" and run uEmacs, >a ^P is not acted upon until after another key is struck. For example, >a ^P does nothing. A second ^P causes the cursor to move up two lines. Both ends are set for uucp emulation (or the originating end is set for it, and the receiving is set to "255"). UUCP protocol originates with "^PShere=xxxxxx"..... Set the receiving end to be commanded by the originating (S111=255?), and set the originating end for NO protocol enhancements. The problem should disappear. Of course when you dial out uucp your dialers script should return the register to "30" temporarially (having the modem configured to reset to NVRAM parameters on DTR drop is handy here). -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
bsa@telotech.UUCP (Brandon S. Allbery) (09/13/89)
In article <1989Sep4.162531.28089@investor.pgh.pa.us>, root@investor (Bob Peirce #305) writes: +--------------- | I don't know if this happens with any other control characters, but | when I dial in from one Telebit to another on "FAST" and run uEmacs, | a ^P is not acted upon until after another key is struck. For example, | a ^P does nothing. A second ^P causes the cursor to move up two lines. +--------------- The Telebits are running in UUCP spoofing mode. Since ^P signals a UUCP "outer protocol" packet, it's held until the incoming data can be determined to be or not be a UUCP packet. The solution I use (under HDB (BNU) UUCP) is to have a separate Dialers file for "cu", and either disable spoofing or use Xmodem spoofing; Xmodem spoofing triggers on ^X, which in Emacs *always* gets immediately followed by a character. ++Brandon -- -=> Brandon S. Allbery @ telotech, inc. (I do not speak for telotech.) <=- Any comp.sources.misc postings sent to this address will be DISCARDED -- use allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups. ** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **