From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28718 invoked from network); 9 Nov 1998 16:47:49 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Nov 1998 16:47:49 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id LAA22618; Mon, 9 Nov 1998 11:44:12 -0500 (EST) Resent-Date: Mon, 9 Nov 1998 11:44:12 -0500 (EST) From: "Bart Schaefer" Message-Id: <981109084237.ZM17914@candle.brasslantern.com> Date: Mon, 9 Nov 1998 08:42:37 -0800 In-Reply-To: <9811091500.AA15026@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "PATCH: 3.1.5: Re: New-line in prompt" (Nov 9, 4:00pm) References: <9811091500.AA15026@ibmth.df.unipi.it> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: PATCH: 3.1.5: Re: New-line in prompt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"tMfeU1.0.IX5.SlnHs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4592 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 9, 4:00pm, Peter Stephenson wrote: } Subject: PATCH: 3.1.5: Re: New-line in prompt } } However, the other bit, adding a newline if the current line is too } long, is a different kettle of fish. It's possible to add a test flag } so you can put in arbitrary text if the line has reached a certain } length. With the patch to 3.1.5 at the end, you can do e.g. } } PS1='any old stuff%(30l. } .)some more stuff' This is certainly interesting. My first thought was to approach this problem with truncation behavior, which turned out to be a lot more painful than I expected. For one thing, the documentation for $<...< and %>...> don't explain that the truncation AND the computation of the length of the string apply only to *one* immediately following prompt component. Once that's understood, it becomes apparent that the conditional syntax is the only way to group other prompt components (except for %{...%} which isn't desirable here). So I end up with something silly like (warning, this doesn't work): PS1='%78> %m[%h] >%(0_.%/ %m[%h] .)' At which point I discover (which perhaps should have been obvious, but wasn't) that the string inside the %>...> is not itself prompt-expanded; and further that %>...> "reaches inside" the %(...) construct to only truncate the %/ in spite of my effort to group it. (Oh, and, BTW, that there's no way to escape '>' or '<' inside %>...> or %<...<.) At the very least, this all ought to be documented. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com