Re: up-line-or-search still 'fixed'!

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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