From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20360 invoked by alias); 26 Sep 2013 17:13:06 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18002 Received: (qmail 24281 invoked from network); 26 Sep 2013 17:13:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130926101254.ZM23201@torch.brasslantern.com> Date: Thu, 26 Sep 2013 10:12:54 -0700 In-reply-to: Comments: In reply to Raghavendra Prabhu "Re: Issue with histreduceblanks" (Sep 26, 12:52am) References: <20130918185058.GA19235@Archie> <20130918211227.51cdbd0f@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Raghavendra Prabhu Subject: Re: Issue with histreduceblanks Cc: Zsh Users MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 26, 12:52am, Raghavendra Prabhu wrote: } } On Thu, Sep 19, 2013 at 1:42 AM, Peter Stephenson } wrote: } > } > Are there any non-ASCII characters on the line that might be confusing } > the algorithm (the option pre-dates handling of multibyte characters)? } } Sorry for the delay in replying (it had ended in my Junk due to } Precedence headers). You didn't really answer Peter's question. Also I think something is being lost in the cut-and-paste-and-email process, because this ... } Archie% Only two kinds of witnesses exist. The first live in a } neighborhood where } zsh: command not found: Only ... obviously has a newline where there must not have been one in your original string. To have much hope of debugging this, we need a copy of EXACTLY what you typed, including what might be characters that "look like" spaces but really are not. } b) Also tested with print as requested Did you see/try this? > If that were the case, I would expect history ops that reference words by > position would also be confused. E.g., something like > > zsh% print Only two kinds of witnesses exist. The first live in a neighborhood where !#:7 !#:8 !#:9 > > would likely substitute the wrong substrings for !#:7 etc., because the > same array of word positions is used to condense blanks.