From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19326 invoked from network); 1 Jun 1998 16:35:15 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 1 Jun 1998 16:35:15 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id MAA05425; Mon, 1 Jun 1998 12:29:30 -0400 (EDT) Resent-Date: Mon, 1 Jun 1998 12:29:30 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980601092932.ZM26540@candle.brasslantern.com> Date: Mon, 1 Jun 1998 09:29:32 -0700 In-Reply-To: <19980601081357.58829@actor.cs.vt.edu> Comments: In reply to Andy Wick "up-line-or-search" (Jun 1, 8:13am) References: <19980601081357.58829@actor.cs.vt.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: Andy Wick , zsh-workers@math.gatech.edu Subject: Re: up-line-or-search MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"rwc6X2.0.iK1.fRjSr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4020 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 1, 8:13am, Andy Wick wrote: } Subject: up-line-or-search } } If you comment out line 376 of Zle/zle_hist.c } iblank(s[histmpos] == Meta ? s[histmpos+1]^32 : s[histmpos]) && } up-line-or-search will kind of work, which is better then not I just downloaded and unpacked the 3.1.4 tarfile, and I have that code on line 390, not 376. So you may want to check the state of your sources. (This does not appear to be the reason for the problem.) } What it still does with that line commented out is forget } the orginal string typed in, and uses the last string found each } time you hit up arrow. This is all the result of the change in history-search-backward, which causes it not to match word prefixes. In my freshly-built copy of 3.1.4, I can't even perform the search you describe here: } Example: } (Previous Commands) } %lss -d } %ls -l } %lss } %ls } } Now if I do } l } it finds "ls" When I do that, I get a beep, because there is no previous command where `l' is the entire first word. If I do "ls" I get "ls -l", having entirely skipped "lss". Repeated correctly finds other uses of ls, skipping lss. Now, I've never been terribly happy with the change to require full word matching in history-search-backward, and the fact that it has rippled through to change the way other commands behave makes it even more of an annoyance. However, I can't decide if this is actually a bug. The doc says: `up-line-or-search' Move up a line in the buffer, or if already at the top line, search backward in the history for a line beginning with the first word in the buffer. Neither there nor under history-search-backward does it say "a line whose first word is the same as the first word in the buffer" but I suppose the reference to "the first word" is supposed to imply that. So perhaps the command is working correctly but the doc is unclear. } I'll buy someone a pizza if they just fix this for me, I really } want to upgrade to 3.1.x, but can't without my favorite feature. In zle_hist.c, in uplineorsearch(), call historybeginningsearchbackward() instead of historysearchbackward() and I believe you'll get what you want. How or whether Zefram intends to deal with this is another matter. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com