jfjr@MITRE-BEDFORD.ARPA (Freedman) (10/15/87)
I am using a vt100 on Ultrix running Emacs 18.49. We have just been moved to a new location with a whole new networking system. I find I get "Failing-isearch: ^Q" often enough to tempt me into encouraging my terminal to go airborne. I looked around in the installation notes and "PROBLEMS" in particular and my problem was described along with several possible solutions. The one I tried and which seems to work is to evalutate (set-input-mode nil t). I did it, it seems to work and I put it in my .emacs. Now here's my question(s). The author of problems describes this solution as drastic and enough to get emacs "semi" working. Well gee, it seems to work fine. Am I missing something? Will my terminal blow up or all my files go to the bitbucket?. What dangers am I skirting? Next question. I looked in site-init.el and saw where the construction of the keyboard-translate-table. It maps ^S to ^S and ^Q to ^Q (as well as ^\ to ^S and ^^ to ^Q). Can I get into trouble if I override this in my .emacs - which is loaded first? site-init.el or .emacs? By overriding I mean map ^S to something harmless but still mapping ^\ to ^S. This type of thing is also referred to as drastic too by the way - How drastic is it? Jerry Freedman, Jr "As you wander through life jfjr@mitre-bedford.arpa Whatever be your goal (617)271-6248 or 7555 Keep your eye upon the doughnut and not on the hole"
dph@beta.UUCP (David P Huelsbeck) (10/16/87)
In article <8710151837.AA10134@mitre-bedford.ARPA> jfjr@MITRE-BEDFORD.ARPA (Freedman) writes: > > I am using a vt100 on Ultrix running Emacs 18.49. We have just been >moved to a new location with a whole new networking system. I find >I get "Failing-isearch: ^Q" often enough to tempt me into encouraging >my terminal to go airborne. [...] >with several possible solutions. The one I tried and which seems to >work is to evalutate (set-input-mode nil t). I did it, it seems to >work and I put it in my .emacs. Now here's my question(s). The >author of problems describes this solution as drastic and enough >to get emacs "semi" working. Well gee, it seems to work fine. Am I >missing something? Will my terminal blow up or all my files go to >the bitbucket?. What dangers am I skirting? [...] > >Jerry Freedman, Jr "As you wander through life >jfjr@mitre-bedford.arpa Whatever be your goal >(617)271-6248 or 7555 Keep your eye upon the doughnut > and not on the hole" I'm following up only because I think this problem is much more wide spread than the folks at FSF think. (not a flame, I love GNU) I had the same problem. I tried shutting of Xon/Xoff on my vt100. No dice. My vt100 has one of the optional printer ports. It seems that when one of these is put into a vt100 it locks it into Xon/Xoff mode to deal with the local printer. I could have replaced my vt100 with another sans printer port (have one sitting in my office) but I wasn't willing to give up local printing. I tried adding the extra buffering that rms suggests, that didn't work to well either. So I eventually found a solution while trying to do something else. The solution is "screen". The virtual terminals package allows you to work in Xon/Xoff mode and still send ^S & ^Q to any applications running directly under it. (I say directly because I suppose you'd run into the same problem if you logged in, fired up screen, and the rlogged and fired up emacs.) I've also found that I like the virtual terminals better than the GNU shell mode or terminal emulator. (Just my personal preference, sorry if you don't agree.) "screen" was just posted to one of the sources groups not to long ago. I'm sure you can find someone to mail you a copy. David Huelsbeck dph@lanl.gov.arpa {cmcl2,ihnp4}!lanl!dph #include <std/disclaimers.h>
olsen@XN.LL.MIT.EDU (Jim Olsen) (10/16/87)
In a recent article, jfjr@MITRE-BEDFORD.ARPA (Freedman) writes: >I am using a vt100 on Ultrix running Emacs 18.49. I find I get >"Failing-isearch: ^Q" often enough to tempt me into encouraging my >terminal to go airborne. [The solution] which seems to work is to >evaluate (set-input-mode nil t). >Now here's my question(s). The author of problems describes this solution >as drastic and enough to get emacs "semi" working. Well gee, it seems to >work fine. Am I missing something? What dangers am I skirting? There are no hidden dangers in using (set-input-mode nil t). However, it does mean that ^S and ^Q are no longer available, so you may want to rebind their functions to other keys. I have bound isearch-forward, quoted-insert, and save-buffer to keypad keys on my VT100. I have also redefined some of the search control characters, using: (setq search-repeat-char ?\C-z) (setq search-exit-char ?\C-x) (setq search-quote-char ?\C-c) to make searching more convenient. Emacs works fully and completely for me. Apparently, the author of 'problems' thinks systems using XON/XOFF flow-control are "brain-damaged" and should go away. Fortunately, one needn't accept all of the GNU philosophy in order to use GNU software.
lamy@utegc.UUCP (10/19/87)
Seems to me that so much traffic on this list is generated by ^H and ^S fixes that an "official" solution ought to be available in a future release. Why not a) have whatever character stty specifies as the delete character act as the delete character. b) Consider the behaviour where help prints messages ignoring the keyboard translation to be a bug instead of a feature? Ordinary mortals don't want to know... c) Provide a trivial function call to replace ^S and ^Q (xon-xoff-braindamage-workaround control-S-repl control-Q-repl) Ordinary mortals should not have to worry about translation tables... I don't care myself, as the terminals I use have nice big delete and meta key and are well behaved wrt flow control, but I'm getting sick of having to tell people to rewire their brains and use DEL or include 10 lines of incantations in their .emacs ('cause I'm the one they come to see to get them). Jean-Francois Lamy lamy@ai.toronto.edu, lamy@ai.toronto.cdn AI Group, Dept of Computer Science lamy%ai.toronto.edu@relay.cs.net University of Toronto, Canada M5S 1A4 {uunet,watmath}!ai.toronto.edu!lamy