From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1814 invoked from network); 9 Jun 1998 18:45:54 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Jun 1998 18:45:54 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id OAA15726; Tue, 9 Jun 1998 14:41:32 -0400 (EDT) Resent-Date: Tue, 9 Jun 1998 14:41:32 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980609114223.ZM6613@candle.brasslantern.com> Date: Tue, 9 Jun 1998 11:42:23 -0700 In-Reply-To: Comments: In reply to Bruce Stephens "Re: up-line-or-search still 'fixed'!" (Jun 9, 4:50pm) References: <19980428143325.59341@gmp-fores1.uk.jpmorgan.com> <199804281408.PAA32237@taos.demon.co.uk> <19980609141304.41665@gmp-fores1.uk.jpmorgan.com> <980609082238.ZM5717@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Bruce Stephens , zsh-workers@math.gatech.edu Subject: Re: up-line-or-search still 'fixed'! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"tZjEp1.0.fr3.S7OVr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4066 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 9, 4:50pm, Bruce Stephens wrote: } Subject: Re: up-line-or-search still 'fixed'! } } "Bart Schaefer" writes: } } > If this were the IETF (which thank goodness it isn't, but) we'd take } > a straw poll at this point. So far I'm "hearing" a lot of protest } > about this change from actual users of the shell and support only } > from those interested in internal architecture. } } Maybe somebody could summarise the specific question? The question is, why did the behavior of up-line-or-search (and down-*) change from zsh 3.0.x to zsh 3.1.x? The answer is the same as the answer to the question, why did the behavior of history-search-backward (and *-forward) change? This isn't a "recent" change -- it took place in January 1997 -- but there are several of us who've been protesting it all along. It's come to a head now because 3.0.5 now seems to really and truly be the final 3.0 release, so soon there will be development/bugfixes only on 3.1. If we're going to continue using 3.1 and beyond, we need to resolve this issue. } Maybe if the interface that's changed was described concisely, } together with the reasons for changing it, then it would be obvious to } people that it was worth keeping, or some workaround would become } clearer? It's pretty simple, really. The 3.0 and earlier, history-search-*ward would record the length of the search pattern and remember that the command was search. When a second history-search-*ward immediately followed, the current line up to the old pattern length would be read and used as the search pattern. Otherwise, the current line up to the current cursor position -or- the end of the first word (whichever came first) was read and used as the search pattern. (Now loop back to the top of this paragraph.) When user-defined widgets were introduced, the "old pattern length" or the state of "was the last command a search" could become incorrect (that is, things could change without the zle internals finding out all the details). This meant that repeated backward searches could fail in unexpected ways. To fix this, Zefram made two changes to history-search-*ward: (1) they ignore the cursor position and the previous pattern length, and (2) they always search for an entire word matching the first entire word on the current command line. It's behavior (2) that we object to. Those of us who use *-line-or-search, which are implemented by calling history-search-*ward, were used to having a *partial* word at the beginning of the current line matched against the history. It's significantly less useful if you must type the entire first word before beginning the search. We could reimplement *-line-or-search with history-beginning-search-*ward, but there are two drawbacks to that: (A) they won't stop reading the pattern after the first word, they always read all the way to the cursor position; (B) they won't reposition the cursor to the end of the line, which history-search-*ward do (and can't, because the cursor position has to remain unchanged for the next search to work correctly). (A) is the biggest problem. It's my assertion that history-search-*ward are now broken and should be made to behave the way they used to (but not implemented the way they used to be implemented). That fixes *-line-or-search as a side-effect. It might be possible to fix *-line-or-search independently, but IMO that is glossing over the underlying brokenness of history-search-*ward. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com