From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28913 invoked from network); 19 Aug 2006 18:39:39 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Aug 2006 18:39:39 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 45733 invoked from network); 19 Aug 2006 18:39:33 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Aug 2006 18:39:33 -0000 Received: (qmail 18272 invoked by alias); 19 Aug 2006 18:39:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22632 Received: (qmail 18263 invoked from network); 19 Aug 2006 18:39:30 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 19 Aug 2006 18:39:30 -0000 Received: (qmail 45377 invoked from network); 19 Aug 2006 18:39:30 -0000 Received: from vms040pub.verizon.net (206.46.252.40) by a.mx.sunsite.dk with SMTP; 19 Aug 2006 18:39:29 -0000 Received: from torch.brasslantern.com ([71.121.0.226]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J49004SDD5QJ065@vms040.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 19 Aug 2006 13:39:27 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id k7JIdQnP028551 for ; Sat, 19 Aug 2006 11:39:26 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id k7JIdPUv028550 for zsh-workers@sunsite.dk; Sat, 19 Aug 2006 11:39:25 -0700 Date: Sat, 19 Aug 2006 11:39:25 -0700 From: Bart Schaefer Subject: Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?) In-reply-to: <20060819064335.GA13552@finlandia.home.infodrom.org> To: Zsh-Workers Message-id: <060819113925.ZM28549@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20060818102602.GA24702@finlandia.home.infodrom.org> <20060818130849.GD15840@fsst.voodoo.lan> <060818110351.ZM24330@torch.brasslantern.com> <20060819064335.GA13552@finlandia.home.infodrom.org> Comments: In reply to Matthias Kopfermann "readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)" (Aug 19, 8:43am) On Aug 19, 8:43am, Matthias Kopfermann wrote: } } > Another reason I resisted this is that it leads to PS1 values that } > contain lots more %{ %} pairs than are often necessary. E.g., for a } > two-line prompt, you can often put the entire first line in a single } > pair of %{ ... %}. } } if one only uses one color , you mean? No; if you have a two-line prompt. The first line of the prompt makes no difference at all to the length of the line where zle will be editing, so you can do PS1=$'%{whole first line with all sorts of color changes\n%}nextline% ' In fact now that I think of it zle may be smart enough to ignore all the stuff before the newline, in which case you don't need the %{ %} at all on that line. } perhaps i was mistaken to think that every escape code needs } needs these %{ %} around it. } so i thought it really had to be done with any new one. Think of it in terms of cursor motion. You need %{ when the cursor stops moving and %} when it starts again, and in between you can do anything you like (including sending the cursor off to some other part of the screen, as long as you bring it back to the original spot again before closing the braces). You also need %{ and %} only as they affect the same screen line where the prompt finally finishes, because zle only cares about horizontal position, not vertical. } The biggest problem in zsh functions is readability You mean in cryptic sytax for parameter expansions and format strings. Yes, in many ways shells are a throwback to the days when the number of bytes or keystrokes used made a large difference, and interpreters could not compile and call user-defined functions for things like prompts and string manipulation. Also the requirement for using the unix stdin/stdout pipe model for text manipulation made it much more efficient to build things into the shell syntax that would have been better handled externally.