Zle bug
Wez Furlong
Hi,
I am reporting a bug that is present in zsh 3.1.2 and also 3.1.2-zefram3.
I have mentioned it before (when 3.1.2 was first released) but it does not
appear to have been addressed.
Here's a demonstration:
% > zsh -f
% > echo $ZSH_VERSION
3.0.5
% > bindkey '\e[A' up-line-or-search
% > who
wez tty3 Feb 1 00:37
root tty4 Feb 1 00:42
root tty2 Jan 31 16:51
wez tty5 Feb 1 01:42
% > ls
Admin Personal UNI root
Amiga Povray Wez-Crontab spambounce.tar.gz
Dave Src mail.vim tmp
PCMCIA Stuff mbox
% > w
At this point I press cursor up
% > who
This is correct.
And here is the bug, with 3.1.2:
% > zsh -f
% > echo $ZSH_VERSION
3.1.2
% > bindkey '\e[A' up-line-or-search
% > who
wez tty3 Feb 1 00:37
root tty4 Feb 1 00:42
root tty2 Jan 31 16:51
wez tty5 Feb 1 01:42
% > ls
Admin Personal UNI root
Amiga Povray Wez-Crontab spambounce.tar.gz
Dave Src mail.vim tmp
PCMCIA Stuff mbox
% > w
Pressing cursor up produces a beep.
% > w
This is a feature which I use a lot, and it's a shame it is missing/broken. I
have tested this on the following:
Linux twinklestar 2.0.31 #4 Thu Dec 18 14:19:38 GMT 1997 m68k
And an SGI IRIX 5.3 system - we have had several older versions of zsh which
work correctly, but both builds of 3.1.2 and 3.1.2-zefram3 exhibit the broken
behaviour.
While on the subject of IRIX and zeframs baseline version, there were a couple
changes needed in order for the build to be successful. I had applied zeframs
diff, and the build diff to correct the bashisms (which failed on about 5
hunks - I tried the systems default patch, and the latest gnu patch - the gnu
version failed less hunks than the other).
After applying those hunks manually, I then had to edit Src/signames.awk and
Builtins/rlimits.awk and change the references to 034 to 042, as gawk (3.x)
was producing \^ (or something similar) instead of ". Note, however, that
042 is octal for 34 which is the ascii code for ". 034 is the ascii code for
FS, which is not really what is wanted. This could be a portability of
{g,m,n}awk issue - interpretation of different radices.
I hope you can sort out the zle thing, and also fix the build setup (I had to
get autoconf (for autoheader) which required gnu m4, and then apply patches by
hand etc. etc.) - the zefram version was very difficult to build on the
semi-stock IRIX setup.
I also hope this is a ``useful'' bug report. :-)
Thanks,
Wez.
--
Wez Furlong Undergrad - Electronic Systems Engineering
http://www.twinklestar.demon.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thomas Köhler
On Feb 1, Wez Furlong wrote
> Hi,
>
> I am reporting a bug that is present in zsh 3.1.2 and also 3.1.2-zefram3.
> I have mentioned it before (when 3.1.2 was first released) but it does not
> appear to have been addressed.
>
> Here's a demonstration:
>
> % > zsh -f
> % > echo $ZSH_VERSION
> 3.0.5
> % > bindkey '\e[A' up-line-or-search
> % > who
> wez tty3 Feb 1 00:37
> root tty4 Feb 1 00:42
> root tty2 Jan 31 16:51
> wez tty5 Feb 1 01:42
> % > ls
> Admin Personal UNI root
> Amiga Povray Wez-Crontab spambounce.tar.gz
> Dave Src mail.vim tmp
> PCMCIA Stuff mbox
> % > w
>
> At this point I press cursor up
>
> % > who
>
> This is correct.
I'd say "no, it's a bug" ;-)
> And here is the bug, with 3.1.2:
>
> % > zsh -f
> % > echo $ZSH_VERSION
> 3.1.2
> % > bindkey '\e[A' up-line-or-search
> % > who
> wez tty3 Feb 1 00:37
> root tty4 Feb 1 00:42
> root tty2 Jan 31 16:51
> wez tty5 Feb 1 01:42
> % > ls
> Admin Personal UNI root
> Amiga Povray Wez-Crontab spambounce.tar.gz
> Dave Src mail.vim tmp
> PCMCIA Stuff mbox
> % > w
>
> Pressing cursor up produces a beep.
>
> % > w
Looking at the manpages, I found this:
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.
It works like this:
~> zsh -f
% echo $ZSH_VERSION
3.1.2
% bindkey '\e[A' up-line-or-search
% ls -l
total 1503
[snip]
% pwd
/home/jean-luc
% l_
^
Cursor here, hit cursor-up -> beeps, because the _word_ l wasn't
found in the history
% ls_
^
Cursor here, hit cursor-up -> expands to ls -l
This behaviour seems to be OK, looking at the documentation...
Perhaps this can't be done in zsh-3.1.2 as it is now, we may need
something like "up-line-or-history-beginning-search-backward". ;-)
CU,
Thomas [using history-beginning-search-backward]
--
-- Thomas Köhler Email: jean...@picard.franken.de
<>< jean...@mayn.de
IRC: jeanluc Channels: #star_trek #linuxger #ixthys #knf
WWW: http://home.pages.de/~jeanluc/
Anthony JR Heading
On Sun, Feb 01, 1998 at 03:41:48PM +0100, Thomas Köhler wrote:
>
> I'd say "no, it's a bug" ;-)
>
> 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.
>
Wouldn't it be preferable to fix the documentation rather than
the code? I've also used this feature for as long as I can recall,
and FWIW the new behaviour I also assumed to be a bug.
Long live the status quo! Down with user-defined widgets! Affirmative
action for non-word-boundaries!
Seriously, if you have this function bound the cursor keys, this is
a major breakage.
Anthony
Wez Furlong
On Feb 9, 12:57pm, Anthony JR Heading wrote:
: On Sun, Feb 01, 1998 at 03:41:48PM +0100, Thomas Köhler wrote:
: > I'd say "no, it's a bug" ;-)
: > Looking at the manpages, I found this:
: >
: > 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.
:
: Wouldn't it be preferable to fix the documentation rather than
: the code? I've also used this feature for as long as I can recall,
: and FWIW the new behaviour I also assumed to be a bug.
: Seriously, if you have this function bound the cursor keys, this is
: a major breakage.
After trying to use the other suggestion, I have to agree - can we fix
the documentation and adjust the code so that the behaviour is the same
as 3.0.5? I can't see the way to getting the widget to work for this
function anyway.
Andy Wick
I sent a message a while back that up-line-or-search DOESN'T work AT ALL
on many platforms with zsh-3.1.2-zefram4, up-line-or-history DOES
work when bound to the arrow keys. Can anyone get up-line-or-search to work
with zefram4?
Thanks,
Andy
On Tue, Apr 28, 1998 at 01:34:46PM +0100, Anthony Heading wrote:
> We had the following discussion a couple of months back. Zefram, can you please comment.
>
> Anthony
>
> On Mon, Feb 09, 1998 at 01:23:55PM +0000, Wez Furlong wrote:
> > On Feb 9, 12:57pm, Anthony JR Heading wrote:
> >
> > : On Sun, Feb 01, 1998 at 03:41:48PM +0100, Thomas Kvhler wrote:
> > : > I'd say "no, it's a bug" ;-)
> > : > Looking at the manpages, I found this:
> > : >
> > : > 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.
> > :
> > : Wouldn't it be preferable to fix the documentation rather than
> > : the code? I've also used this feature for as long as I can recall,
> > : and FWIW the new behaviour I also assumed to be a bug.
> >
> > : Seriously, if you have this function bound the cursor keys, this is
> > : a major breakage.
> >
> > After trying to use the other suggestion, I have to agree - can we fix
> > the documentation and adjust the code so that the behaviour is the same
> > as 3.0.5? I can't see the way to getting the widget to work for this
> > function anyway.
>
> --
> Anthony J.R. Heading J.P. Morgan Securities Ltd, London
> Email: heading...@jpmorgan.com Tel: +44 171 325 5962
>
--
aw...@vt.edu Andy Wick
aw...@purple.org Virginia Tech
Andrew Main
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
Anthony Heading
We had the following discussion a couple of months back. Zefram, can you please comment.
Anthony
On Mon, Feb 09, 1998 at 01:23:55PM +0000, Wez Furlong wrote:
> On Feb 9, 12:57pm, Anthony JR Heading wrote:
>
Anthony Heading
On Tue, Apr 28, 1998 at 01:34:46PM +0100, I wrote:
> We had the following discussion a couple of months back. Zefram, can you please comment.
Sorry to follow up my own email (though I realize my sig needed to be updated).
Am just trying to patch in the old behaviour, and realizing it's quite involved -
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.
I'm willing to write a patch to add this all back again if it would help, but
there's not much point unless there's a desire to maintain this functionality.
Why was it so totally removed?
A
--
Anthony J.R. Heading J.P. Morgan & Co. Inc, Singapore
Email: heading...@jpmorgan.com Tel: +65 326 9027