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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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