From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6523 invoked by alias); 6 Mar 2014 04:54:02 -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: 18569 Received: (qmail 7723 invoked from network); 6 Mar 2014 04:53:55 -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 From: Bart Schaefer Message-id: <140305205344.ZM5782@torch.brasslantern.com> Date: Wed, 05 Mar 2014 20:53:44 -0800 In-reply-to: Comments: In reply to Jan Larres "Re: Local/global history with pattern isearch" (Mar 4, 12:44pm) References: <140302214400.ZM1868@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Local/global history with pattern isearch MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 4, 12:44pm, Jan Larres wrote: } } Okay, the good news first: I found the culprit! The issue was caused by } the zsh-syntax-highlighting script Hmm. I don't use that, but looking at it, it should be the case that if you define your widget first then it will skip trying to redefine it, and if you define yours second then yours will replace the highlighting one. (This is all because your widget has the same name as a builtin.) That explains why } ... a quick swapping of order doesn't seem to make any } difference. Moving on: } During my tests I also found a way to make zsh segfault. While I still } had the above script enabled Users of zsh-syntax-highlighting have reported segfaults before. There must be a subtle mistake somewhere in the zsh_highlight internals. I'm not going to try to run this one down, so if any other zsh-workers are listening and inclined ... } I occasionally encountered some strange } behaviour, described in this sequence: } } 1. Press ^r and enter something common like 'ls', the first result } gets displayed } 2. Press ^r again, a "failing bck-i-search" message gets displayed } 3. Press ^r again, another result from the history gets displayed (huh?) This is almost certainly related to what I said in my previous message on this thread, about the $LASTWIDGET test being wrong. So it probably (but not definitely) is not related to the segfault. } 4. Press ^r again, "failing" message again and/or segfault