possible patches for merging to 4.0

possible patches for merging to 4.0

[Oliver Kiddle]

I went through the output of difflog.pl and the following is a list of
patches which I think might be suitable for merging back into 4.0. Where
I've not otherwise specified, patches are from Peter.

users/6421 (Wayne)
not 19696 (_cvs v1.20)
18941
18880
18839/18840
18769
18569
18565
18548
18476 (Andrey)
18435
18318
18264
17295
17175
16737 (Bart)

Re: possible patches for merging to 4.0

[Wayne Davison]

On Fri, Aug 29, 2003 at 04:10:40PM +0200, Oliver Kiddle wrote:
> users/6421 (Wayne)

I checked the 4.0 branch back when I committed that fix, and it didn't
have the bug:  the code in yankpop() is older.  The patch would only be
needed if we wanted to include Peter's changes to improve the kill-ring
into the 4.0 branch.

..wayne..

Re: possible patches for merging to 4.0

[Peter Stephenson]

Oliver Kiddle wrote:
> I went through the output of difflog.pl and the following is a list of
> patches which I think might be suitable for merging back into 4.0. Where
> I've not otherwise specified, patches are from Peter.

Thanks for looking.  Go ahead and apply them, if you like.  Translation:
I'm not likely to have time for this.  However, I will get round to it
eventually.  Some of them I'm surprised I didn't apply straight away.

> 18839/18840

_nice: remember what was committed was not quite the patch that appeared.

> 18769

This is the failed autoload fix... I was pretty convinced that this had
to be correct to prevent some horrific problems, the more so the more I
thought about it, but Bart didn't seem quite so convinced, so I never
got around to committing it back to 4.0.

> 18264

This fixes a minor memory leak when entering a subshell.  Since it only
happens once in the subshell when you enter it, I vaguely thought it was
unnecessarily complicated to port back to 4.0, but it seems to be
working so it's probably OK.

> 17295

I don't think zle -F was in 4.0.

> 17175

I think this also applies only to 4.1, since 4.0 doesn't have the
(slightly hairy) fix that (( foo = ... )) didn't work if foo expanded to
something that couldn't be parsed as an arithmetic expression, even
though it correctly assigned it if it did.

> 16737 (Bart)

This fixed a problem with [ -d = ... ].  Bart's question never got
answered, but I don't suppose it will without some hairier test tests.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk