Re: 5.1.1?

Re: 5.1.1?

[Mikael Magnusson]

On Wed, Sep 2, 2015 at 10:31 AM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Mon, 31 Aug 2015 22:27:22 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>> Confirmed this with zsh-5.1-3-g6e825e7 (recall my question about whether
>> fixing things like this will be 5.1.1 or ...?)
>
> If the freeze Vincent found gets resolved, we might have enough tweaks
> for a 5.1.1, i.e. 5.1 with a few fixes, in a week or two,

Just got this report on #zsh,

% f() { cat << x << y; }
foo
x
bar
y
% which f
f () {
    cat <<x <<y
foo
xbar
y
}

There should be a newline between x and bar in the output. The
function itself works fine.

Also, every time I do vared 'functions[f]' it adds on an extra xy at
the end, after a while:
% vared functions\[f\]
        cat <<x <<y
foo
xbar
yxyxyxyxy

This (obviously) makes the function not work so well anymore.

PS I get this recently for all your emails,
"Gmail couldn't verify that this message was sent by samsung.com."

-- 
Mikael Magnusson

Here document in code chunks

[Peter Stephenson]

On Wed, 2 Sep 2015 10:50:07 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> Just got this report on #zsh,
> 
> % f() { cat << x << y; }
> foo
> x
> bar
> y
> % which f
> f () {
>     cat <<x <<y
> foo
> xbar
> y
> }
> 
> There should be a newline between x and bar in the output. The
> function itself works fine.

Looks like this isn't especially new --- was present in 5.0.0 --- so
while this ought to be easy enough to fix and go into the next release,
it's not especially related to 5.1 / 5.1.1, either.

pws

Re: Here document in code chunks

[Peter Stephenson]

On Wed, 2 Sep 2015 10:03:47 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Wed, 2 Sep 2015 10:50:07 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> % f() { cat << x << y; }
>> foo
>> x
>> bar
>> y
>> % which f
>> f () {
>>     cat <<x <<y
>> foo
>> xbar
>> y
>> }
>>
>> There should be a newline between x and bar in the output. The
>> function itself works fine.

It seems to be this simple.  (Here, here.)

pws

diff --git a/Src/text.c b/Src/text.c
index 3978a26..7e65f43 100644
--- a/Src/text.c
+++ b/Src/text.c
@@ -77,8 +77,8 @@ taddpending(char *str1, char *str2)
      */
     if (tpending) {
 	int oldlen = strlen(tpending);
-	tpending = zrealloc(tpending, len + oldlen);
-	sprintf(tpending + oldlen, "%s%s", str1, str2);
+	tpending = zrealloc(tpending, len + oldlen + 1);
+	sprintf(tpending + oldlen, "\n%s%s", str1, str2);
     } else {
 	tpending = (char *)zalloc(len);
 	sprintf(tpending, "%s%s", str1, str2);
diff --git a/Test/A04redirect.ztst b/Test/A04redirect.ztst
index 602341d..d7fe22f 100644
--- a/Test/A04redirect.ztst
+++ b/Test/A04redirect.ztst
@@ -555,3 +555,34 @@
 0:Assignment with exec used for redirection: POSIX_BUILTINS
 >x=And this
 ?This should appear, too
+
+  fn-two-heres() {
+# tabs below
+    cat <<-x <<-y
+	foo
+	x
+	bar
+	y
+  }
+  which -x2 fn-two-heres
+  fn-two-heres
+  eval "$(which -x2 fn-two-heres)"
+  fn-two-heres
+  print $functions[fn-two-heres]
+0:Two here-documents in a line are shown correctly.
+>fn-two-heres () {
+>  cat <<x <<y
+>foo
+>x
+>bar
+>y
+>}
+>foo
+>bar
+>foo
+>bar
+>	cat <<x <<y
+>foo
+>x
+>bar
+>y

Bug: magic-space and expand-history delete part of line since 5.0.8

[Jacob Niehus]

Since zsh 5.0.8, using magic-space or expand-history can delete part of the
command line for no apparent reason. This does not occur in 5.0.7 or 5.0.5.

To reproduce:

    $ zsh -f
    $ bindkey ' ' magic-space

type this:

    $ vim =(ls) -c 'foo'

move the cursor between 's)' and type '|' then space, and it changes to this:

    $ vim =(ls| )

"-c 'foo'" has been deleted. Many times now I'll edit a command and the whole
right half will just disappear. The same problem happens when using
expand-history.

I git bisected this down to a single commit:
    https://github.com/zsh-users/zsh/commit/c0d01a6fe0c67911650730cf13a2b9a0db16e59b

The commit info/message:

>     commit c0d01a6fe0c67911650730cf13a2b9a0db16e59b
>     Author: Peter Stephenson <pws@zsh.org>
>     Date:   Tue Jan 6 17:05:17 2015 +0000
>
>         Fix command substitutions to parse contents as they are read in.
>
>         Do this by refactoring misnamed lexsave()/lexrestore() to allow
>         continuity of history and input.
>
>         Add test.

-Jacob Niehus

Re: Bug: magic-space and expand-history delete part of line since 5.0.8

[Bart Schaefer]

On Aug 31,  7:32pm, Jacob Niehus wrote:
}
}     $ vim =(ls) -c 'foo'
} 
} move the cursor between 's)' and type '|' then space, and it changes to this:
} 
}     $ vim =(ls| )
} 
} "-c 'foo'" has been deleted.

Confirmed this with zsh-5.1-3-g6e825e7 (recall my question about whether
fixing things like this will be 5.1.1 or ...?)

5.1.1?

[Peter Stephenson]

On Mon, 31 Aug 2015 22:27:22 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Confirmed this with zsh-5.1-3-g6e825e7 (recall my question about whether
> fixing things like this will be 5.1.1 or ...?)

If the freeze Vincent found gets resolved, we might have enough tweaks
for a 5.1.1, i.e. 5.1 with a few fixes, in a week or two,

pws