pabuhr@water.UUCP (07/07/87)
> Article 1238 of comp.emacs: > Path: water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!LF-SERVER-2.BBN.COM!jr > From: jr@LF-SERVER-2.BBN.COM (John Robinson) > Newsgroups: comp.emacs > Subject: Re: 9600 baud problems (was Re: when using termcap, get it right!) > Date: 6 Jul 87 15:22:59 GMT > Sender: daemon@ucbvax.BERKELEY.EDU > ... > I wonder if anyone has ever made an intensely interactive application > like emacs work over a half-duplex line! I am not sure if this is actually what you were are looking for, but at the University of Manitoba (Canada), they modified the rom code for a DT80 terminal to support a powerful full screen editor at half-duplex. The terminal was a line based editor, that is, you could make changes to a line on the screen and when you moved off the line it would be transmitted to the host for insertion in the file. It was not as powerful as Emacs (but not that far away either) and considering it was half-duplex and connected to an Amdahl mainframe, it was pretty impressive. As well, it had most of the operations on the number pad by being able to use the shift key with each number pad key. Each number pad key had a function (eg. next word) and shift that key usually did the reverse (eg. previous word). With fingers on the function pad and thumb on the shift key, it was possible to perform editing operations very quickly. If you would like more information I suggest you contact either: Eugene Reimer : ereimer@UOFMCC.bitnet Bill Reid : reid@UOFMCC.bitnet They have some documentation that they might be willing to send you.
jr@LF-SERVER-2.BBN.COM.UUCP (07/09/87)
>> > From: jr@LF-SERVER-2.BBN.COM (John Robinson) >> > ... >> > I wonder if anyone has ever made an intensely interactive application >> > like emacs work over a half-duplex line! >> ... >> It was >> not as powerful as Emacs (but not that far away either) and >> considering it was half-duplex and connected to an Amdahl mainframe, >> it was pretty impressive. Oops! I forgot all about the class of editors used all the time on IBM 3270 family terminals. These are half-duplex devices with local on-screen editing and the ability to encode only the changes to the screen to let the host know what's happening. Modern 3270 full-screen editors are indeed quite powerful. I will not risk religious war by rating them against Emacs. /jr
ron@topaz.rutgers.edu (Ron Natalie) (07/10/87)
I suppose IBM's XEDIT is not what you're looking for? > The terminal was a line based editor, that is, you could > make changes to a line on the screen and when you moved off the line > it would be transmitted to the host for insertion in the file. It was > not as powerful as Emacs (but not that far away either) and > considering it was half-duplex and connected to an Amdahl mainframe, > it was pretty impressive. This is the way everything works on IBM terminals. The terminal has a data entry region which you fiddle with using the editing keys on the terminal, you then hit the ENTER key (different from return) to send in the edited line. IBM's XEDIT editor is a powerful interactive editor (albeit completely different from EMACS) which allows further operations on the file. -Ron
allbery@ncoast.UUCP (Brandon Allbery) (07/14/87)
As quoted from <8707091403.AA21054@ucbvax.Berkeley.EDU> by jr@LF-SERVER-2.BBN.COM (John Robinson): +--------------- | >> > From: jr@LF-SERVER-2.BBN.COM (John Robinson) | >> > I wonder if anyone has ever made an intensely interactive application | >> > like emacs work over a half-duplex line! | >> not as powerful as Emacs (but not that far away either) and | >> considering it was half-duplex and connected to an Amdahl mainframe, | >> it was pretty impressive. | Oops! I forgot all about the class of editors used all the time on | IBM 3270 family terminals. These are half-duplex devices with local +--------------- IBM XEDIT (editor for VM/CMS) always struck me as being a sort of half-duplex Emacs. (I will, however, use full-duplex Emacs if available in preference to half-duplex XEDIT.) -- [Copyright 1987 Brandon S. Allbery, all rights reserved] \ ncoast 216 781 6201 [Redistributable only if redistribution is subsequently permitted.] \ 2400 bd. Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{ames,harvard,mit-eddie}!necntc,{well,ihnp4}!hoptoad,cbosgd}!ncoast!allbery <<The opinions herein are those of my cat, therefore they must be correct!>>
bzs@bu-cs.BU.EDU (Barry Shein) (07/18/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) Several years ago, before XEDIT, a student here at BU wrote an interesting full screen editor that worked reasonably well on H19 or equivalent terminals on an IBM half-duplex (3705) line. Basically it buffered up the keystrokes which were being edited and performed locally and just kept the edit buffers in sync. It had an escape for extended commands. It used the local edit ability of the terminal and, when enter is hit and the whole mess goes down to the machine, run down the list to figure out how things have changed. The only main problem was that there was a limit of 255 chars per "record" after which the IBM multiplexor would just truncate the line. It used an interesting terminal mode that was in there to support paper tapes transmission from ttys, I think this was to ensure that the line was flow controlled. I made some progress writing a similar editor for use within Lisp on the same system (written in lisp of course.) As I always say, animals caught in a trap will gnaw their legs off to escape :-) -Barry Shein, Boston University
daveb@geac.UUCP (Dave Brown) (07/19/87)
In article <9763@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >Several years ago, before XEDIT, a student here at BU wrote an >interesting full screen editor that worked reasonably well on H19 or >equivalent terminals on an IBM half-duplex (3705) line. Basically it >buffered up the keystrokes which were being edited and performed >locally and just kept the edit buffers in sync. I once wrote one in competition with my boss at Honeywell, and I'd like to pass on his version of the algorithm for dealing with the "buffer overfull" problem: read a line from the input if it ends in \n, it was properly terminated process all the keystrokes if it doesn't end in \n, it got truncated process all the keystrokes redraw from the last cursor position ring the terminal bell This caught about 99% of the errors, and always warned the user. That isn't to say I *recommend* half-duplex editors, though. -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.