Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mandrill!nitrex!rbl
From: rbl@nitrex.UUCP ( Dr. Robin Lake )
Newsgroups: comp.os.vms
Subject: Re: reliably returning the cursor position on a vt2xx
Message-ID: <668@nitrex.UUCP>
Date: 26 Feb 88 13:57:00 GMT
References: <240@unocss.UUCP> <2124@bsu-cs.UUCP>
Reply-To: rbl@nitrex.UUCP ( Dr. Robin Lake )
Distribution: na
Organization: The Standard Oil Co., Cleveland
Lines: 31
Summary: PASSALL may fix it

In article <2124@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Sir Xetwnk) writes:
>In article <240@unocss.UUCP>, ca055@unocss.UUCP (David B. Caplinger) writes:
>
>> [background on cursor-positioning problem...]
>> 
>> The cursor never goes back to the original
>> position after the background process updates.  Sure, I used ESC 7 and ESC 8,
>> but the cursor still winds up on the beginning of the next line, after scroll-
>> ing the lower region.  Argh!  (I added a reverse-index at the end, and now it's
>> on the same /line/ at least, but the coloumn is still wrong.)
>> 
>> Is there any way to make sure the cursor position is retored /where it left
>> off/, instead of the next line?  (Perhaps it /is/, and it's getting moved
>> somehow?  Has anyone else had a problem like this?)
>
>Yes, Dave, this is a common problem under the very circumstances you describe.
>The ESC 7 and ESC 8 are doing their jobs -- the cursor position is doubtless 
>being dutifully saved and restored as you intend -- BUT, I'll bet you a 
>cookie you're writing the ESC 7 and ESC 8 to your terminal, using a language 
>and statement which is appending a carriage-return (CR) and line-feed (LF) 
>to its output; that's what's messing up your cursor position, and here's why:
>
>  [Edited for brevity.]

I believe you can also set the terminal (momentarily) to PASSALL, send the
2 bytes, then reset it with NO PASSALL.  We had the inverse problem with some
PostScript printers.

-- 
Rob Lake
{decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl