I wrote:
>> Stepan Rutz <stepan.rutz@gmx.de> writes:
>>> Anyway, I am sure the iteration used in encode_history and decode_history in input.c does not work on libedit.
>> Yeah, I noticed your comment about that. That seems odd; a look at the
>> Apple libedit sources suggests it should work. I was just about to trace
>> through the logic and try to see what's happening.
> Sigh ... the answer is that libedit has the direction of traversal
> backwards compared to libreadline. If you replace next_history() by
> previous_history() in those loops, then it works as expected.
Oh, even *more* interesting: the existing coding seems to work as designed
in OS X Tiger. I duplicated your result that it's broken on Mavericks
(that was what you were testing, no?). I have a couple intermediate
Mac versions laying about, but no time to test them right now.
So apparently what we've got here is another episode in Apple's
nearly-unblemished record of shipping broken versions of libedit.
Sigh. Either they have astonishingly bad luck at choosing when to
pull from the upstream sources, or the upstream sources are broken
most of the time.
regards, tom lane