From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 538 invoked from network); 9 Jun 1998 15:28:09 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Jun 1998 15:28:09 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id LAA08816; Tue, 9 Jun 1998 11:21:58 -0400 (EDT) Resent-Date: Tue, 9 Jun 1998 11:21:58 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980609082238.ZM5717@candle.brasslantern.com> Date: Tue, 9 Jun 1998 08:22:37 -0700 In-Reply-To: <19980609141304.41665@gmp-fores1.uk.jpmorgan.com> Comments: In reply to Anthony Heading "Re: up-line-or-search still 'fixed'!" (Jun 9, 2:13pm) References: <19980428143325.59341@gmp-fores1.uk.jpmorgan.com> <199804281408.PAA32237@taos.demon.co.uk> <19980609141304.41665@gmp-fores1.uk.jpmorgan.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Andrew Main , zsh-workers@math.gatech.edu Subject: Re: up-line-or-search still 'fixed'! Cc: Anthony Heading MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"DY8qS3.0.d92.LCLVr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4062 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 9, 2:13pm, Anthony Heading wrote: } Subject: Re: up-line-or-search still 'fixed'! } } On Tue, Apr 28, 1998 at 03:08:04PM +0100, Andrew Main wrote: } > Yes. That's why I'm unwilling to go back to the old behaviour. } > The behaviour of up-line-or-search used to depend on whether the } > immediately preceding editing command was also up-line-or-search. } > The model I'm trying to move ZLE to has the effects of each editing } > command as independent as possible of other commands } > } > How would people feel about making up-line-or-search do a } > history-beginning-search-backwards? This would be a lot closer to the } > old behaviour, differing only in the resulting cursor position. } } OK. I've done my best to live with this for six weeks. But it just isn't } working for me. This was a really major feature for anyone who had it } turned on, and having read the code now, IMHO the hit far outweighed the } benefits of a fractionally less broken architecture: it was doing no real } harm until it was the last of the residual state variables. 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. Are we writing usable software or carrying on an academic excercise? Making editing commands independent of each other is impossible anyway. They have to share the text buffer, the cursor position, the cut buffer, all the vi named registers, etc. etc. Eliminating shared data is the wrong approach; consolidating shared data into an "editor state" object is the way to go. It is true that remembering a position in the line and keying the search from there was never the "right" thing to do. The actual string to search for should be saved somewhere and re-used. If we were following the emacs model, there'd be a repeat-history-search-*ward that called up that string and searched again for it, and invoking history-search-*ward would install a new keymap where the keys used to begin searching are bound to repeat-* and the other keys install the old keymap and then re-interpret themselves. Regardless of how it's implemented, that is the way this should *behave*. The claim that searching for the whole first word is "more like the documentation says" is nothing more than a rationalization for breakage, and is still imperfect if implementation purity is what you're after. (The two patches that originally introduced this change can be found at http://www.zsh.org/mla/workers-1997-hyper/0030.html http://www.zsh.org/mla/workers-1997-hyper/0039.html Hey, there, mailing-list-archive maintainer, how's about including the X-Mailing-List header somewhere in what's visible and searchable, so that the patch numbers in the ChangeLog can be used to hunt this stuff down?) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com