From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1837 invoked from network); 6 May 2008 15:49:10 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 May 2008 15:49:10 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 79117 invoked from network); 6 May 2008 15:49:06 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 May 2008 15:49:06 -0000 Received: (qmail 23866 invoked by alias); 6 May 2008 15:49:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24950 Received: (qmail 23846 invoked from network); 6 May 2008 15:49:01 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 May 2008 15:49:01 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [85.115.41.190]) by bifrost.dotsrc.org (Postfix) with ESMTP id D702680ED173 for ; Tue, 6 May 2008 17:48:56 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly04g.srv.mailcontrol.com (MailControl) with ESMTP id m46Fmr4X029779 for ; Tue, 6 May 2008 16:48:54 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 16:48:52 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m46Fmqtr013527 for ; Tue, 6 May 2008 16:48:52 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m46Fmq2X013524 for ; Tue, 6 May 2008 16:48:52 +0100 Message-Id: <200805061548.m46Fmq2X013524@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: random attribute stuff In-reply-to: <080506083802.ZM1323@torch.brasslantern.com> References: <200805060915.m469FeJP017551@news01.csr.com> <080506073442.ZM22499@torch.brasslantern.com> <200805061442.m46Eg7bN000588@news01.csr.com> <080506075838.ZM1161@torch.brasslantern.com> <200805061510.m46FA71C001035@news01.csr.com> <080506083802.ZM1323@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Tue, 06 May 2008 08:38:02 -0700." Date: Tue, 06 May 2008 16:48:52 +0100 From: Peter Stephenson X-OriginalArrivalTime: 06 May 2008 15:48:52.0686 (UTC) FILETIME=[AF09B6E0:01C8AF90] X-Scanned-By: MailControl A-08-00-05 (www.mailcontrol.com) on 10.71.0.114 X-Virus-Scanned: ClamAV 0.91.2/7040/Tue May 6 03:52:15 2008 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > } It ought to be (but might turn out not to be) fairly easy to add a > } "default" element to zle_highlight that causes the given attributes to > } be used as the default set for the command line, which would probably > } work a lot better, and then deprecate any reliance on what the prompt > } happened to produce. > > Sounds reasonable to me, but could get ugly if a widget were to change > it on the fly -- do you trap that and reprint the entire buffer, or do > you allow blotches of different attributes as areas are selectively > repainted, or do you make that setting read-only in widgets? It's likely to be implement in zle_refresh.c, so the answer is probably that it changes at the next refresh, which I think ought to work OK. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070