Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!CSE.OGI.EDU!schaefer From: schaefer@CSE.OGI.EDU (Barton E. Schaefer) Newsgroups: comp.mail.mush Subject: Re: Odd mush screen behavior Message-ID: <9001080625.AA11260@cse.ogi.edu> Date: 8 Jan 90 06:25:25 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 35 On Jan 3, 6:11pm, Jaye Mathisen wrote: } } I was using the :pick command to extract some messages, and after extracting } them, delete 'em. The following is the screen after mush was done } picking-writing-deleting. } } } 3 N campbell@redsox.UUCP Dec 19 11:46 (30 li) Re: What constitutes abu } 4ing cc.usu.edu!slcx9 Dec 19 3NET_P14tScripFACTS OF LIFE } 5ing uunet!ateng!chip s) Dec 20 5:21 (36tScript_map_m.maps.hdr" [ lots of messy redundancy deleted ] This is is a side-effect of mush's "minimalist" approach to using curses. Whenever output will scroll the screen, mush bypasses curses and prints directly to the screen (because many if not most curses implementations do not handle scrolling correctly, and some not at all). It then prints the ...continue... prompt to let you know that the screen has been messed up. Unfortunately, if for some reason printing that prompt causes the line to wrap, curses will decide the screen needs to be redrawn. Curses doesn't know that mush has been scribbling on the screen behind its back, so it efficiently redraws only some parts of the screen, leaving fragments of mush's other output in the gaps. This does mean that you should try to limit your $prompt setting to less than 65 characters when using curses mode, or you'll see this sort of garbage a lot. Hitting any unbound key (space bar is easiest) will cause the screen to be properly redrawn. -- Bart Schaefer "Miserable miscreant! Question MY integrity, will you?" "I have to see some *evidence* of it before I can question it." -- Calvin & Hobbes schaefer@cse.ogi.edu (used to be cse.ogc.edu)