Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: up-line-or-search still 'fixed'!
- X-seq: zsh-workers 3885
- From: Andrew Main <zefram@xxxxxxxxx>
- To: aheading@xxxxxxxxxxxx (Anthony Heading)
- Subject: Re: up-line-or-search still 'fixed'!
- Date: Tue, 28 Apr 1998 15:08:04 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <19980428143325.59341@xxxxxxxxxxxxxxxxxxxxxxxxxx> from "Anthony Heading" at Apr 28, 98 02:33:25 pm
Anthony Heading wrote:
>ZLE_HISTSEARCH has been excised, and histpos is no longer a static variable,
>so there's no record of how far through a word the search should be keyed from.
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, so that eventually
most of them can be separated into modules or even implemented purely
as shell functions. Each of the ZLE_* flags violates this principle to
some extent, so I'm trying to remove them as far as possible (which will
not be completely).
I've been considering other ways of recording the bits of state that the
ZLE_* flags and various static variables contain. I'd like everything to
be user-accessible, for widgets. In a future version it will definitely
be possible to implement the old up-line-or-search, if one really wants
to. But for the moment it just doesn't fit into the ZLE architecture.
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.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author