From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29396 invoked from network); 8 Jul 2006 17:56:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) 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 autolearn=ham version=3.1.3 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Jul 2006 17:56:40 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 14906 invoked from network); 8 Jul 2006 17:56:31 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Jul 2006 17:56:30 -0000 Received: (qmail 19807 invoked by alias); 8 Jul 2006 17:56:23 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10497 Received: (qmail 19797 invoked from network); 8 Jul 2006 17:56:23 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 8 Jul 2006 17:56:23 -0000 Received: (qmail 13943 invoked from network); 8 Jul 2006 17:56:22 -0000 Received: from vms042pub.verizon.net (206.46.252.42) by a.mx.sunsite.dk with SMTP; 8 Jul 2006 17:56:22 -0000 Received: from torch.brasslantern.com ([71.116.74.94]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J23006DIJ5QQ6V5@vms042.mailsrvcs.net> for zsh-users@sunsite.dk; Sat, 08 Jul 2006 12:56:15 -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 k68HuDqh008720 for ; Sat, 08 Jul 2006 10:56:13 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id k68HuCkS008719 for zsh-users@sunsite.dk; Sat, 08 Jul 2006 10:56:12 -0700 Date: Sat, 08 Jul 2006 10:56:11 -0700 From: Bart Schaefer Subject: Re: Redirection Symbol After Completion In-reply-to: <200607081145.k68BiwEY023823@pwslaptop.csr.com> To: zsh-users@sunsite.dk Message-id: <060708105612.ZM8718@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <200607081145.k68BiwEY023823@pwslaptop.csr.com> Comments: In reply to Peter Stephenson "Re: Redirection Symbol After Completion" (Jul 8, 12:44pm) On Jul 8, 12:44pm, Peter Stephenson wrote: } Subject: Re: Redirection Symbol After Completion } } Chris Johnson wrote: } > I personally find commands easier to parse with my eye when the space } > remains before the redirection symbol: } > } > cat file.txt | } > } > Is there any way to force this space to persist even if I type a } > redirection operator? } } It's a perfectly reasonable thing to want to configure, but } unfortunately I don't think it's possible to do this without some } tweaking of the completion system. Skipping ahead a bit ... } echo testdir/ } } and now type "|". The slash isn't removed, as it usually would be. } That's because the same mechanism controls the characters removed when } you have a suffix, including an automatically added /, and when you } don't, i.e. you get the space in your original question. Presumably he wants the slash replaced by a space in that instance. I think you're going about this the wrong way -- rather than revamping how autoremoval occurs in the general case, adjust the way redirection ops are inserted. self-insert-redir() { integer l=$#LBUFFER zle self-insert (( $l >= $#LBUFFER )) && LBUFFER[-1]=" $LBUFFER[-1]" } zle -N self-insert-redir for op in \| \< \> \& do bindkey "$op" self-insert-redir done I like that so much I might even keep it. It'd be nice if it were possible to test whether a suffix removal is pending rather than checking the length of LBUFFER before and after the self-insert, but I think this suffices (no pun intended). One could go so far as to actually replace self-insert and also check with a style for what constitutes a redirection operator, but that gets a bit uglier. I believe there was a discussion several months ago about the problems caused by not being able to instruct zsh when to use the ZLE_KEEPSUFFIX internal flag on a user-defined widget. (Hmm, maybe that problem doesn't apply here anyway.) --