Tab completion error after upgrade

Tab completion error after upgrade

[Thorsten Kampe]

[Zsh 5.0.8 on Cygwin 64-bit]

Hello,

since the upgrade from 5.0.7 to 5.0.8 every attempt for tab 
completion results in `_main_complete:143: parse error near `()'`.

What can I do to resolve this issue? Is this an issue for the Cygwin 
Zsh maintainer?

Thorsten

Re: Tab completion error after upgrade

[Peter A. Castro]

On Fri, 26 Jun 2015, Thorsten Kampe wrote:

> Date: Fri, 26 Jun 2015 20:25:10 +0200
> From: Thorsten Kampe <thorsten@thorstenkampe.de>
> To: zsh-users@zsh.org
> Subject: Tab completion error after upgrade
> 
> [Zsh 5.0.8 on Cygwin 64-bit]
>
> Hello,

Greetings, ,

> since the upgrade from 5.0.7 to 5.0.8 every attempt for tab
> completion results in `_main_complete:143: parse error near `()'`.
>
> What can I do to resolve this issue? Is this an issue for the Cygwin
> Zsh maintainer?

You should be posting this to the Cygwin email list, if you believe this 
is a Cygwin issue.

BTW, I didn't see this issue when I built 5.0.8, but I'll look into it.

Just to be sure, have you re-run compinit ?

> Thorsten

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: Tab completion error after upgrade

[Frank Terbeck]

Thorsten Kampe wrote:
> Hello,

Hi!

> since the upgrade from 5.0.7 to 5.0.8 every attempt for tab 
> completion results in `_main_complete:143: parse error near `()'`.

The golden rule of fixing weird compsys behaviour is this:

  - Remove ~/.zcompdump
  - Restarting the shell by issuing "exec zsh" for example.

If that doesn't fix the issue, that sounds like trouble.

Regards, Frank

Re: Tab completion error after upgrade

[Thorsten Kampe]

* Peter A. Castro (Fri, 26 Jun 2015 12:06:40 -0700 (PDT))

> On Fri, 26 Jun 2015, Thorsten Kampe wrote:
> 
> > Date: Fri, 26 Jun 2015 20:25:10 +0200
> > From: Thorsten Kampe <thorsten@thorstenkampe.de>
> > 
> > [Zsh 5.0.8 on Cygwin 64-bit]
> >
> 
> > since the upgrade from 5.0.7 to 5.0.8 every attempt for tab
> > completion results in `_main_complete:143: parse error near `()'`.
> >
> > What can I do to resolve this issue? Is this an issue for the Cygwin
> > Zsh maintainer?
> 
> You should be posting this to the Cygwin email list, if you believe this 
> is a Cygwin issue.

I have no idea. That's why I asked.
 
> BTW, I didn't see this issue when I built 5.0.8, but I'll look into it.
> 
> Just to be sure, have you re-run compinit ?

`autoload -U compinit; compinit -C ` is run from my .zshrc. I also 
deleted .zcompdump and .zcompdump.zwc.

Thorsten

Re: Tab completion error after upgrade

[Peter A. Castro]

On Fri, 26 Jun 2015, Thorsten Kampe wrote:

> Date: Fri, 26 Jun 2015 22:35:41 +0200
> From: Thorsten Kampe <thorsten@thorstenkampe.de>
> To: zsh-users@zsh.org
> Subject: Re: Tab completion error after upgrade
> 
> * Peter A. Castro (Fri, 26 Jun 2015 12:06:40 -0700 (PDT))
>
>> On Fri, 26 Jun 2015, Thorsten Kampe wrote:
>>
>>> Date: Fri, 26 Jun 2015 20:25:10 +0200
>>> From: Thorsten Kampe <thorsten@thorstenkampe.de>
>>>
>>> [Zsh 5.0.8 on Cygwin 64-bit]
>>>
>>
>>> since the upgrade from 5.0.7 to 5.0.8 every attempt for tab
>>> completion results in `_main_complete:143: parse error near `()'`.
>>>
>>> What can I do to resolve this issue? Is this an issue for the Cygwin
>>> Zsh maintainer?
>>
>> You should be posting this to the Cygwin email list, if you believe this
>> is a Cygwin issue.
>
> I have no idea. That's why I asked.

Ok, let me see if I can repro it first.

>> BTW, I didn't see this issue when I built 5.0.8, but I'll look into it.
>>
>> Just to be sure, have you re-run compinit ?
>
> `autoload -U compinit; compinit -C ` is run from my .zshrc. I also
> deleted .zcompdump and .zcompdump.zwc.

Ok, just checking.  Do you happen to have any customizations for 
completion?  I suspect not, but want to check.

> Thorsten

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: Tab completion error after upgrade

[Thorsten Kampe]

* Peter A. Castro (Fri, 26 Jun 2015 13:42:09 -0700 (PDT))

> Ok, just checking.  Do you happen to have any customizations for 
> completion?  I suspect not, but want to check.

Lots of. Error stays the same when I delete them in .zshrc.

Thorsten

Re: Tab completion error after upgrade

[Bart Schaefer]

On Jun 26, 10:35pm, Thorsten Kampe wrote:
}
} > Just to be sure, have you re-run compinit ?
} 
} `autoload -U compinit; compinit -C ` is run from my .zshrc. I also 
} deleted .zcompdump and .zcompdump.zwc.

If you have .zwc files, you may need to delete and rebuild those as
well.  There was some effort made to improve the algorithm that
compares the .zwc file version to the zsh version, but it still
may sometimes load a compiled function from an older shell.

In particular there are no parens on line 143 of _main_complete,
which makes the error suspicious.

Re: Tab completion error after upgrade

[Thorsten Kampe]

* Bart Schaefer (Fri, 26 Jun 2015 14:52:38 -0700)
> 
> On Jun 26, 10:35pm, Thorsten Kampe wrote:
> }
> } > Just to be sure, have you re-run compinit ?
> } 
> } `autoload -U compinit; compinit -C ` is run from my .zshrc. I also 
> } deleted .zcompdump and .zcompdump.zwc.
> 
> If you have .zwc files, you may need to delete and rebuild those as
> well.  There was some effort made to improve the algorithm that
> compares the .zwc file version to the zsh version, but it still
> may sometimes load a compiled function from an older shell.
> 
> In particular there are no parens on line 143 of _main_complete,
> which makes the error suspicious.

The error comes from "setopt no_multifuncdef" in my .zshrc. Setting 
multifuncdef interactively makes the error disappear and unsetting 
the option again manually does not reintroduce the error.

These two statements (in an otherwise empty .zshrc) will show the 
error on my system:

```
setopt no_multifuncdef
autoload -U compinit; compinit -C   # completion system
```

Thorsten

Re: Tab completion error after upgrade

[Thorsten Kampe]

* Thorsten Kampe (Sat, 27 Jun 2015 12:09:11 +0200)

> The error comes from "setopt no_multifuncdef" in my .zshrc.

This is the description of the option from the man page:

Allow  definitions  of  multiple  functions  at once in the form `fn1 
fn2...()'; if the option is not set, this causes a parse error. 
Definition of multiple functions with the function keyword is always 
allowed.  Multiple function definitions are not often  used  and can 
cause obscure errors.

Re: Tab completion error after upgrade

[zzapper]

Thorsten Kampe <thorsten@thorstenkampe.de> wrote in news:mmk5do$shp$1
@ger.gmane.org:

> [Zsh 5.0.8 on Cygwin 64-bit]
> 
> Hello,
> 
> since the upgrade from 5.0.7 to 5.0.8 every attempt for tab 
> completion results in `_main_complete:143: parse error near `()'`.
> 
> What can I do to resolve this issue? Is this an issue for the Cygwin 
> Zsh maintainer?
> 
> Thorsten
> 
I use zsh 5.08 on cygwin on multiple PCs with no sign of this issue.

zsh --version
zsh 5.0.8 (x86_64-unknown-cygwin)





-- 
zzapper
https://twitter.com/dailyzshtip

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Tab completion error after upgrade

[Peter Stephenson]

On Sat, 27 Jun 2015 12:12:49 +0200
Thorsten Kampe <thorsten@thorstenkampe.de> wrote:
> * Thorsten Kampe (Sat, 27 Jun 2015 12:09:11 +0200)
> 
> > The error comes from "setopt no_multifuncdef" in my .zshrc.

Ah.  This isn't Cygwin-specific at all.

MULTIFUNCDEF is turned on for completion, but that happens within
_main_complete itself, and the error is during parsing, not execution,
and functions are parsed to the end before executing.

So the simplest thing to do is just split the definitions.  I believe
these deliberately don't use the trap builtin.

diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
index c023268..9c4cfac 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -141,11 +141,16 @@ _completer_num=1
 
 # We assume localtraps to be in effect here ...
 integer SECONDS=0
-TRAPINT TRAPQUIT() {
+TRAPINT() {
   zle -M "Killed by signal in ${funcstack[2]} after ${SECONDS}s";
   zle -R
   return 130
 }
+TRAPQUIT() {
+  zle -M "Killed by signal in ${funcstack[2]} after ${SECONDS}s";
+  zle -R
+  return 131
+}
 
 # Call the pre-functions.
 

Re: Tab completion error after upgrade

[Bart Schaefer]

On Jun 27,  5:43pm, Peter Stephenson wrote:
} 
} So the simplest thing to do is just split the definitions.  I believe
} these deliberately don't use the trap builtin.

Right; they deliberately DID use the trap builtin when I added them, but
it was determined that some side-effects didn't propagate correctly if
functions were not used.


-- 
Barton E. Schaefer

Assorted TRAPxxx / trap xxx observations

[Bart Schaefer]

On Jun 27, 11:35am, Bart Schaefer wrote:
}
} ... they deliberately DID use the trap builtin when I added them, but
} it was determined that some side-effects didn't propagate correctly if
} functions were not used.

Incidentally, anonymous functions provide (inflict?) some interesting 
semantics for the "trap" command.

torch% unsetopt debug_before_cmd
torch% trap '() { print $LINENO $1 } $LINENO' DEBUG
0 2
torch% echo "What's my line?"   
What's my line?
0 3
torch% 

A couple of fun things there.

1. This is probably obvious, but it means you can get the benefits of a
separate function context in the trap without side-effect of the return
value acting as an interrupt.  Are there other non-obvious things?  Any
of this worth adding to the doc?

2. Installing a DEBUG trap with NODEBUG_BEFORE_CMD in effect causes the
setting of the trap to debug itself.

Regarding the return value acting as an interrupt, a nonzero return from
a DEBUG_BEFORE_CMD trap behaves exactly the same as "setopt ERR_EXIT" in
that it prevents the upcoming command from executing.  Either this is an
unintentional change, or we don't need the ERR_EXIT trick any more.

I also previously had not considered the interaction of $? with debug
traps, specifically DEBUG_BEFORE_CMD.  (Sorry, Peter, I'm about to make
your eyes glaze over, again.)  The upshot is that $? in the trap refers
to the previous command in one case, and to the command being debugged
in the second case.

torch% trap '() { print ERR $? }' ZERR
torch% trap '() { print DBG $? }' DEBUG
torch% false
DBG 0
ERR 1
torch% true
DBG 1
torch% unsetopt debugbeforecmd
DBG 0
torch% false
DBG 1
ERR 1
torch% true
DBG 0
torch% 

I suppose $? has to be the status of the previous command in the debug
trap when it runs before, because the upcoming command has to be able
to test the previous command's status.

Mostly this raises documentation issues.  It's not mentioned anywhere
that toggling DEBUG_BEFORE_CMD inside the trap will NOT cause the trap
to execute twice (something that might be interesting if you want to
examine $? both before and after).  It's also not explicitly called out
that the value of $? always refers to whatever executed right before
the trap, which differs with the state of DEBUG_BEFORE_CMD, but this may
be considered obvious.

That's all for now ...

-- 
Barton E. Schaefer