Re: Zle bug

Re: Zle bug

[Wez Furlong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

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.


-- 
Wez Furlong                        Undergrad - Electronic Systems Engineering
                                           http://www.twinklestar.demon.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

[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:
> 
> : 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.

-- 
Anthony J.R. Heading    J.P. Morgan Securities Ltd, London
Email: heading_anthony@jpmorgan.com  Tel: +44 171 325 5962

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

[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_anthony@jpmorgan.com  Tel: +44 171 325 5962
> 

-- 
awick@vt.edu                                    Andy Wick
awick@purple.org                              Virginia Tech

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

[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_anthony@jpmorgan.com    Tel: +65 326 9027

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

[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

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

[Anthony Heading]

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, 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).
[...] 
> 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.

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.

So I really must protest.  This is purism over usability!

Thus unfortunately, I'm going to have to switch back to 3.0.5 until
the brave new dawn.  

-- 
Anthony J.R. Heading    J.P. Morgan & Co. Inc, Singapore
Email: heading_anthony@jpmorgan.com    Tel: +65 326 9027

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

[Bart Schaefer]

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

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

[Bruce Stephens]

"Bart Schaefer" <schaefer@brasslantern.com> 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.  Are we writing
> usable software or carrying on an academic excercise?

The former, but people are also aiming for internal beauty and
simplicity, I think.  (Well, maybe it's more "practical
maintainability" than "simplicity".)

Maybe somebody could summarise the specific question?  I've not
noticed any particular change recently: the last change that irritated
me a bit was the */ becoming *(/), which I understand was necessary,
but I used */ quite a bit.

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?

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

[Bart Schaefer]

On Jun 9,  4:50pm, Bruce Stephens wrote:
} Subject: Re: up-line-or-search still 'fixed'!
}
} "Bart Schaefer" <schaefer@brasslantern.com> 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

Re: message numbers in mla

[Geoff Wing]

Bart Schaefer <schaefer@brasslantern.com> typed:
: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?)

Yes, well, unfortunately I set it up with (a minorly hacked version of)
hypermail which is somewhat limited.  I had planned to write my own simple
one or maybe switch to one that does keep specific headers (mhonarc?) but
there are many things I didn't like (when I last looked 1 - 1 1/2 years ago)
about all of the existing ones anyway.  As for writing my own, well, time is
available to me only for short periods at the moment.
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

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

[Bruce Stephens]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> 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?

Ah, that would explain why I'm sometimes surprised by what M-p
produces.  You're right, it's broken; I just hadn't really noticed
properly and found out what was broken.

If I type "ls foo<M-p>", I'm clearly looking for a line beginning with
"ls foo", not one beginning with "ls".

As you say, one solution would be a special mode, like the incremental
modes, which would remember what they were looking for. 

Another one---which I think I'd find acceptable---would be not to move
the cursor, so history-search-backward would always search for the
text before the cursor.  Or has that been tried, and people hated it?

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

[Zefram]

Bruce Stephens wrote:
>Another one---which I think I'd find acceptable---would be not to move
>the cursor, so history-search-backward would always search for the
>text before the cursor.  Or has that been tried, and people hated it?

That's exactly what history-beginning-search-* do.

-zefram

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

[Bruce Stephens]

Zefram <zefram@tao.co.uk> writes:

> Bruce Stephens wrote:
> >Another one---which I think I'd find acceptable---would be not to move
> >the cursor, so history-search-backward would always search for the
> >text before the cursor.  Or has that been tried, and people hated it?
> 
> That's exactly what history-beginning-search-* do.

Doh.  And it's even what M-p, M-n are bound to.  So is the problem
that people really like(d) the behaviour of going to the end of the
line?

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

[Bart Schaefer]

On Jun 10, 12:57pm, Bruce Stephens wrote:
} Subject: Re: up-line-or-search still 'fixed'!
}
} Zefram <zefram@tao.co.uk> writes:
} 
} > Bruce Stephens wrote:
} > >Another one---which I think I'd find acceptable---would be not to move
} > >the cursor, so history-search-backward would always search for the
} > >text before the cursor.  Or has that been tried, and people hated it?
} > 
} > That's exactly what history-beginning-search-* do.
} 
} Doh.  And it's even what M-p, M-n are bound to.  So is the problem
} that people really like(d) the behaviour of going to the end of the
} line?

No; I explained what the problems are:

(1) history-search-*ward now match only complete words; they used to
    match prefixes of words too.
(2) history-beginning-search-*ward match across word boundaries; the
    desired behavior is to stop matching at the first word boundary
    (or before, see (1)).
(3) *-line-or-search, what we really want to use, are affected by the
    implementation of history-search-*ward.

The thing with the cursor moving to the end of the line is simply there
to "look like emacs".  (In emacs shell mode, if you hit return with the
cursor in the middle of the line, it acts like zsh's accept-and-hold, but
if you hit return at the end of the line it acts like accept-line.  So
history searches in emacs always place the cursor at end of the line, and
Paul F. made zsh act the same.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: message numbers in mla

[Geoff Wing]

Geoff Wing <mason@primenet.com.au> typed:
:Bart Schaefer <schaefer@brasslantern.com> typed:
::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?)
:Yes, well, unfortunately I set it up with (a minorly hacked version of)
:hypermail which is somewhat limited.  I had planned to write my own simple
:one or maybe switch to one that does keep specific headers (mhonarc?) but
:there are many things I didn't like (when I last looked 1 - 1 1/2 years ago)
:about all of the existing ones anyway.  As for writing my own, well, time is
:available to me only for short periods at the moment.

Heyla,
I've just reprocessed all the current mailing list archive (1995 - now) with
Mhonarc.  There are a couple of changes I will probably make when I get some
more time: forward/backward date/thread links per message; properly 
searchable; etc.

The X-Mailing-List header is preserved in each final message which contains
the official archive number as indexed by the mailing list distributer (and
allows retrieving of non-HTML'd versions from either math.gatech.edu or 
http://www.zsh.org/mla/zsh-{users,workers})

All references to .../mla/*-hyper/ are now invalid ('cos I've deleted it all). 
Hope this is useful to people.
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: message numbers in mla

[Bart Schaefer]

On Jun 22, 11:16am, Geoff Wing wrote:
} Subject: Re: message numbers in mla
}
} All references to .../mla/*-hyper/ are now invalid ('cos I've deleted it
} all).

This is the sort of thing that should be mentioned on the web page, at
least temporarily, and announced on zsh-announce.  (Who is the official
announce person now?  Zefram?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: message numbers in mla

[Richard Coleman]

> } All references to .../mla/*-hyper/ are now invalid ('cos I've deleted it
> } all).
> 
> This is the sort of thing that should be mentioned on the web page, at
> least temporarily, and announced on zsh-announce.  (Who is the official
> announce person now?  Zefram?)

Zefram, Peter, and myself can post to zsh-announce.

--
Richard Coleman
coleman@math.gatech.edu