Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
Nice meaty discussion on this topic! As Paul mentioned, cellular data can be considered high-latency for most purposes, so this one probably isn't going out of style any time soon. On Sep 14, 2007, at 16:13, Ben Scott wrote: PuTTY does appear to support this, more-or-less, by going to Settings - Terminal - Line discipline, and setting Local echo and Local line editing both to Force on. The line editing appears to be fairly primitive (backspace only), but it does appear to work. (I think. It is hard to test without an actual high-latency link.) Somebody stop me before I try running PuTTY under WINE on Linux. :) I guess a good ancillary question is where's the development action on 'terminal emulators' these days? The last big news I heard was ctrl-shift-t in Gnome's terminal. On Sep 14, 2007, at 16:41, Bill Freeman wrote: (alt-x or esc followed by x, then it prompts you at the bottom of emacs's window, and you type shell and hit enter) oh, wow, alt-x works now? I wonder how many years I've been using esc-x since that started working... come to think of it I might have learned esc-x on an ULTRIX terminal and never tried it on linux. thanks, Bill, one can never be too pedagogical here! The tougher thing is if you want to send an incomplete line sometime. Say, to request the remote shell to do filename completeion. I'm not sure how to do that (if there's a send what you've got without a trailing carriage return character command, I haven't found it in the docs). I poked around the elisp once a few years ago, but didn't find anything easy. A few times a year I decide to write a local-editing terminal/shell that will bulk-transfer completion data in the background, but then something shiny distracts me from it. Somebody (Ben probably) recently pointed out ssh's stream multiplexing feature which should make this easier. Usually if I just wait long enough somebody else does it. ;) I may just be impatient on this one (and definitely lazy). On Sep 14, 2007, at 17:19, Ben Scott wrote: For editing files, I often resorted to SCP'ing to local, editing locally, and then SCP'ing back. sshfs might be a slightly lower overhead (human) way of accomplishing this since your editor will likely load the file into buffer for editing. n.b., emacs seems to have a problem with sshfs via fuse on some OS's (MacFUSE being one currently-borked implementation with insufficient signal handling). -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
On 9/16/07, Bill McGonigle [EMAIL PROTECTED] wrote: Somebody stop me before I try running PuTTY under WINE on Linux. :) PuTTY has been ported to *nix/X11. :) http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-unix I guess a good ancillary question is where's the development action on 'terminal emulators' these days? I suspect a lot of people think this is a solved-problem and have lost interest. The only reason anything has happened at all is that KDE and GNOME are both intent on re-inventing every wheel they can find. Multiple times. :) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
On 9/14/07, Bill McGonigle [EMAIL PROTECTED] wrote: I've attempted this on a satellite link ... Heh heh heh. Me too(TM). It's a different experience when you can measure ping RTT using a hand-held stop watch. :) Has anybody seen a line-mode-oriented shell? Stephen Bourne. (According to Wikipedia, he's the Bourne in Bourne shell.) In other words, Unix was built to be friendly to such environments. Our problems arise because we're used to everything being modern and faster. For example, to get the tty subsystem to stop echoing characters, just use stty -echo. To tell Bash not to try doing anything fancy, invoke it with the --noediting option. At that point, the hard part is finding a *terminal* that supports a local line editing mode. I think there might be an xterm or rxvt option somewhere for this. Maybe on one of the [CTRL]+click menus? (I'm not at an xterm right now.) PuTTY does appear to support this, more-or-less, by going to Settings - Terminal - Line discipline, and setting Local echo and Local line editing both to Force on. The line editing appears to be fairly primitive (backspace only), but it does appear to work. (I think. It is hard to test without an actual high-latency link.) Then the hardest part is trying to figure out how to use ed to edit text files. Or maybe one of the TECO fans in the group can give lessons on that. ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
I have not used FreeNX but I did use their commercial product NX. It made a huge improvement. Don ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
On 9/14/07, Bill Freeman [EMAIL PROTECTED] wrote: The tougher thing is if you want to send an incomplete line sometime. Say, to request the remote shell to do filename completeion. I suspect file name completion might be one of those advanced features one has to give up when you go back to the bad-old-days of high-latency links and local editing. Another issue is (or was) applications using curses ... The answer to that problem is Don't do that anyway. As Bill McG said, they don't work well over truly high latency links, and I can confirm. Running even vi over such is painful. For editing files, I often resorted to SCP'ing to local, editing locally, and then SCP'ing back. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
On Fri, Sep 14, 2007 at 04:13:27PM -0400, Ben Scott wrote: At that point, the hard part is finding a *terminal* that supports a local line editing mode. I think there might be an xterm or rxvt option somewhere for this. Maybe on one of the [CTRL]+click menus? (I'm not at an xterm right now.) Maybe something that supports 3270 mode (or 5250)? google finds a few hits, like this one that looks interesting (tho I know absolutely nothing about this site): http://x3270.bgp.nu/ Then the hardest part is trying to figure out how to use ed to edit text files. Or maybe one of the TECO fans in the group can give lessons on that. ;-) Oh sure, from one write-only-language thread to another.. But really, there have been some line-oriented editors that were designed for block mode transmissions even though the actual connections had evolved to character mode. One that I used presented one line at a time. You would indicate where you wanted to edit the line by sending '/' characters that skipped over the part you wanted to keep. Like (not exactly like, since my memory is fuzzy): * this is a line of text from the file i//new and then you hit return to have the change take effect, i.e., to insert the word new before line. It was quite a trip and I only put up with it for so long before writing a new editor there :) -mm-. kj/n ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
I suspect file name completion might be one of those advanced features one has to give up when you go back to the bad-old-days of high-latency links and local editing. Yeesh! D'ya think? ;- Much of coolness offered by bash (completions, editing modes, etc) is a direct result of bash's ability to micro-manage your session - each keystroke is monitored. (long dormant neurons rouse sluggishly to action...) I was part of the team working on porting IN/IX to the Wang VS, which normally communicated via Z80 powered terminals that handled much of the front end processing when Wang's OS was running. It was necessary to commit many unnatural acts to get those terminals to hand each character over to the kernel as it was typed so that stuff like vi could even have a chance of working properly when IN/IX was running. This got particularly interesting when WangVM (circa 1984 - VMWare is definitely *not* new technology...) was running, since the [EMAIL PROTECTED]@ workstations had to change behaviors depending on which virtualized OS they were talking to. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: High Latency Survival Tactics (Was: Re: Thunderbird stupid about X traffic?)
Date: Fri, 14 Sep 2007 17:19:19 -0400 From: Ben Scott [EMAIL PROTECTED] On 9/14/07, Bill Freeman [EMAIL PROTECTED] wrote: The tougher thing is if you want to send an incomplete line sometime. Say, to request the remote shell to do filename completeion. I suspect file name completion might be one of those advanced features one has to give up when you go back to the bad-old-days of high-latency links and local editing. Again, tractable within Emacs: make sure the filename you want to complete appears somewhere in the buffer and type: M-x hippie-expand. Alternatively, you could write a hippie function to complete on remote filenames... but that would require writing elisp. Ewww. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
