mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (04/02/91)
> How can I make xterm not restore the previous screen when exiting > from applications such as vi and less? xterm -xrm '*titeInhibit: true' Presumably adding xterm*titeInhibit: true to your resource database would have the same effect. This works for me in less. It doesn't work in vi; this is probably because I did the test on SunOS 4.1, and in 4.1 Sun (deliberately, as far as I can tell) broke vi so it no longer listens to $TERMCAP. (I checked, and xterm set $TERMCAP correctly; vi just ignored it.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
sanders@peyote.cactus.org (Tony Sanders) (04/02/91)
In article <736@necssd.NEC.COM> harrison@necssd.NEC.COM (Mark Harrison) writes: >How can I make xterm not restore the previous screen when exiting >from applications such as vi and less? I have rtfm and the faq, >but can't find a clue. It's not xterm doing it. It's vi/less/etc looking at your termcap/terminfo doing it. You'll have to modify your termcap/terminfo to remove the offending escape sequences. terminfo: smcup/rmcup termcap: ti/te The escape sequences for the X11R4 xterm is "ESC [ ? 47 h" and "ESC [ ? 47 l" To turn it off simply remove the entry. I like to make my smcup switch screens then clear the screen, something like: smcup=\E[?47h\E[H\E[2J BTW: You should feel lucky, some people try for a long time to get those to work. All you have to do is make it stop. :-) If you decide you like them, I suggest having a little script that echo's the escape sequence to swicth you back and forth. Then you have a "virtual screen" to save data on while you type in the other one. Not very useful with X-windows, but If you're ever stuck on an ascii terminal it has it's place. later, -- sanders@peyote.cactus.org Brilliance is typically the act of an individual, but incredible stupidity can usually be traced to an organization. -- "More Programming Perls", Jon Bentley I am not an IBM representative, I speak only for myself.
datri@convex.com (Anthony A. Datri) (04/04/91)
>This works for me in less. It doesn't work in vi; this is probably >because I did the test on SunOS 4.1, and in 4.1 Sun (deliberately, as >far as I can tell) broke vi so it no longer listens to $TERMCAP. >(I checked, and xterm set $TERMCAP correctly; vi just ignored it.) 4.1 moves to the SysV version of vi, which uses terminfo instead of termcap. -- -- datri@convex.com
bush@ecs.ox.ac.uk (Mark Bush) (04/05/91)
In article <9104012143.AA05716@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes:
#> How can I make xterm not restore the previous screen when exiting
#> from applications such as vi and less?
#
#xterm -xrm '*titeInhibit: true'
#
#This works for me in less. It doesn't work in vi; this is probably
#because I did the test on SunOS 4.1, and in 4.1 Sun (deliberately, as
#far as I can tell) broke vi so it no longer listens to $TERMCAP.
#(I checked, and xterm set $TERMCAP correctly; vi just ignored it.)
This is because in SunOS4.1, vi is one of the programs that uses the
/usr/5lib libraries and terminfo database, so is likely to show some
unexpected behaviour.
Appart from the vi links (e, ex, edit...) I'm not aware of other programs
that Sun have broken in this way...
# der Mouse
Markphil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/10/91)
sanders@peyote.cactus.org (Tony Sanders) writes: >It's not xterm doing it. It's vi/less/etc looking at your >termcap/terminfo doing it. You'll have to modify your termcap/terminfo to >remove the offending escape sequences. > terminfo: smcup/rmcup > termcap: ti/te These escape sequences are in the termcap as initializers for doing curses or other screen cursor addressing. For a VT100 they are not necessary as this can be done at any time. It switches to an alternate screen. There are SOME cases where I do NOT want this switch and there are SOME cases where I *DO* want this switch. Removing the termcap entry will remove it from call cases. I am lucky that essentially my terminal use is VT100 so what I have done is hack LESS to just not do the calls to generate those sequences. This will break if some terminal type needs them (hopefully rare). The termcaps just do NOT distiguish "sequences to initialize cursor addressing" (which should be NULL on a VT100) and "sequences to switch to and from alternate screens" which should be specified for a VT100 and user selectable on a program by program basis to act upon or not ( -altscreen ). >The escape sequences for the X11R4 xterm is "ESC [ ? 47 h" and "ESC [ ? 47 l" >To turn it off simply remove the entry. I like to make my smcup >switch screens then clear the screen, something like: > smcup=\E[?47h\E[H\E[2J >BTW: You should feel lucky, some people try for a long time to get those >to work. All you have to do is make it stop. :-) I guess their work goes unappreciated? :-) >If you decide you like them, I suggest having a little script that >echo's the escape sequence to swicth you back and forth. Then you have >a "virtual screen" to save data on while you type in the other one. >Not very useful with X-windows, but If you're ever stuck on an ascii >terminal it has it's place. Sounds like a useful idea! -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks / \***************************************************************************/
rlk@think.COM (Robert L Krawitz) (04/10/91)
As has been pointed out, editing the termcap entry doesn't entirely solve the problem, since the terminfo database still contains it and some programs, such as vi on SunOS 4.1, use terminfo. It also doesn't work too well if I then rlogin or telnet somewhere else. Why doesn't titeInhibit simply make xterm ignore these control sequences? ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)234-2116
bill@polygen.uucp (Bill Poitras) (04/16/91)
In article <9104101311.AA18390@underprize.think.com> rlk@think.COM (Robert L Krawitz) writes: >Why doesn't titeInhibit simply make xterm ignore these control >sequences? It does. I use it to ignore it for more. It doesn't work for vi because, as you have pointed out (In text which I deleted) vi reads the terminfo database directly, and forces a screen save. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+
gildea@expo.lcs.mit.EDU (Stephen Gildea) (04/19/91)
>Why doesn't titeInhibit simply make xterm ignore these control >sequences? It does. I use it to ignore it for more. It doesn't work for vi because, as you have pointed out (In text which I deleted) vi reads the terminfo database directly, and forces a screen save. No, it doesn't. titeInhibit removes the ti and te entries from the termcap entry, but xterm still obeys them if they get sent anyway. That's why it doesn't work for SunOS vi; it doesn't use termcap, so still knows how to send ti and te. Now, to answer the original question, Why? Answer: it's a bug. < Stephen MIT X Consortium
dce@smsc.sony.com (David Elliott) (04/20/91)
In article <9104181754.AA00842@alex.lcs.mit.edu>, gildea@expo.lcs.mit.EDU (Stephen Gildea) writes: |> No, it doesn't. titeInhibit removes the ti and te entries from the |> termcap entry, but xterm still obeys them if they get sent anyway. |> That's why it doesn't work for SunOS vi; it doesn't use termcap, so |> still knows how to send ti and te. |> |> Now, to answer the original question, Why? Answer: it's a bug. We have the same problem (even more so) in SVR4-land, so I took a look at modifying xterm. It was easy to defeat the switching of the buffer, but it still clears the screen (because, of course, ti and te have multiple commands). I suspect that the "easy" way to fix this is to define a new pair of sequences that mean "save the current position and switch buffers" and "switch buffers and restore the last saved position". What do you think, Steve? In other words, the best way to deal with this is to use terminfo to your advantage and create a personal entry. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Once a head-crusher, always a head-crusher" - Mark M.