Behaviour of zle list-choices

Behaviour of zle list-choices

[Joe M]

Hello,

In an earlier release of zsh, when list-choices is active and I press
"Ctrl-C", the current line gets killed and I get a new prompt.

Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
not an identifier".

Any kind thoughts, please?

Thanks
Joe

Re: Behaviour of zle list-choices

[Eric Cook]

On 02/25/2016 09:44 PM, Joe M wrote:
> Hello,
> 
> In an earlier release of zsh, when list-choices is active and I press
> "Ctrl-C", the current line gets killed and I get a new prompt.
> 
> Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
> not an identifier".
> 
> Any kind thoughts, please?
> 
> Thanks
> Joe
> 
what does ''type -f TRAPINT'' display?

Re: Behaviour of zle list-choices

[Joe M]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Hello Eric,

> > In an earlier release of zsh, when list-choices is active and I press
> > "Ctrl-C", the current line gets killed and I get a new prompt.
> >
> > Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
> > not an identifier".
>
> what does ''type -f TRAPINT'' display?

type -a -f TRAPINT
TRAPINT () {
        ft_zle_state[minibuffer]=no
        ft-psvx-default
        zle reset-prompt 2> /dev/null
        return 127
}

Does that help?

Thanks for checking this out,
Joe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of zle list-choices

[Joe M]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Hello Eric,

> > > In an earlier release of zsh, when list-choices is active and I press
> > > "Ctrl-C", the current line gets killed and I get a new prompt.
> > >
> > > Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
> > > not an identifier".
> >
> > what does ''type -f TRAPINT'' display?
>
> type -a -f TRAPINT
> TRAPINT () {
>         ft_zle_state[minibuffer]=no
>         ft-psvx-default
>         zle reset-prompt 2> /dev/null
>         return 127
> }

Thanks for your suggestion. Removing the above TRAPINT fixed the
issue that I am noticing.

Thanks a lot,
Joe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of zle list-choices

[Joe M]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

Hello Bart,

I have a multi-line prompt.

When I have an empty prompt and I press Ctrl-C, I get the next prompt.
But, when I have the list-choices active and I press Ctrl-C, the line
above the command is disappearing.

For example, this is the behavior when zle list-choices is not active
and I press Ctrl-C:

- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -
l
- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -

This is the behavior, when zle list-choices is active and I press
Ctrl-C:

- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -
l
ls
- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -

It should have been:

- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -
l
- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -
ls
- (0:i:/tmp/zsh-build)  -  -  -  -  -  -  -


When I "git bisect" zsh, I found that this:

691547cda60f0512c645e80246292936e660f326 is the first bad commit
commit 691547cda60f0512c645e80246292936e660f326
Author: Barton E. Schaefer <schaefer@zsh.org>
Date:   Wed Oct 29 08:45:57 2014 -0700

    33563: Completion/Base/Core/_main_complete, Src/Zle/complist.c: fix thinko in status message for INT/QUIT signals; check errflag in output loops

    Two semi-related patches for keyboard interrupt handling in completion,
    most importantly so that unexpectedly long completion listings can be
    interrupted.

:100644 100644 54fac61ca8d2f0d76020fe91c58600c425d6c6c8 676d2697968a06c855091681dd5ba4c8e15f6cf3 M        ChangeLog
:040000 040000 4bd268b6f03e9232602127edfa5c1d1257477a3a 0604aba5e8a729e0e3e28aa5aaaa9db0dba6a1ad M        Completion
:040000 040000 28150242dcea19e15813219cdae0c8bed8a0c3f6 7a23b88a420c221c2dd26b45e1ca0cac774a477d M        Src

Any kind comments, please?

Thanks
Joe

Joe M wrote:
> Hello,
>
> In an earlier release of zsh, when list-choices is active and I press
> "Ctrl-C", the current line gets killed and I get a new prompt.
>
> Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
> not an identifier".
>
> Any kind thoughts, please?
>
> Thanks
> Joe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of zle list-choices

[Peter Stephenson]

On Thu, 25 Feb 2016 20:44:19 -0600
Joe M <joe9mail@gmail.com> wrote:
> In an earlier release of zsh, when list-choices is active and I press
> "Ctrl-C", the current line gets killed and I get a new prompt.
> 
> Now (zsh 5.2), When I press "Ctrl-C", I get the message: "TRAPINT:1:
> not an identifier".

There was a bug here that's been fixed, where Ctrl-C didn't abort in the
way you expected.  It affected menu selection --- zsh-workers/37643,
commit 1d8b528522.  I don't have time now to check if it's the same one
affecting listing, I'm afraid, though it's obviously very similar.  I
hope that fixes this version of the problem, though I don't remember
this particular symptom.

pws

Re: Behaviour of zle list-choices

[Bart Schaefer]

On Feb 26, 11:17am, Peter Stephenson wrote:
}
} There was a bug here that's been fixed, where Ctrl-C didn't abort in the
} way you expected.

I don't entirely understand Joe's description of his multi-line prompt
(it looks like he may have lines BELOW the input position?), but this
appears to work as expected with my own multi-line prompt (one line
above the input) and list-choices.

It's not quite the same thing as menu selection because it's not in the
menu navigation loop, it just has to clear the completion list before the
prompt is redrawn.

Re: Behaviour of zle list-choices

[Joe M]

[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]

Hello Bart,

> I don't entirely understand Joe's description of his multi-line prompt
> (it looks like he may have lines BELOW the input position?), but this
> appears to work as expected with my own multi-line prompt (one line
> above the input) and list-choices.

I recorded the console behavior using ttyrec. I am attaching the
ttyrecord.ttyrec file. I am not sure if you use ttyrec. If not,
"ttyplay ttyrecord.ttyrec" will show the behavior that I am talking
about.

Thanks
Joe


[-- Attachment #1.2: ttyrecord.ttyrec --]
[-- Type: application/octet-stream, Size: 19476 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Behaviour of zle list-choices

[Bart Schaefer]

On Feb 27,  5:09pm, Joe M wrote:
}
} I recorded the console behavior using ttyrec.

Thanks, but I'm still not able to reproduce that behavior.  It looks
as though you may be using zsh-syntax-highlighting or some similar
add-on configuration -- are you sure that's not a contributing factor?

Re: Behaviour of zle list-choices

[Joe M]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Hello Bart,

> } I recorded the console behavior using ttyrec.
>
> Thanks, but I'm still not able to reproduce that behavior.  It looks
> as though you may be using zsh-syntax-highlighting or some similar
> add-on configuration -- are you sure that's not a contributing factor?

Thanks a lot for checking on this issue. It was caused by my
customization. Sorry for not checking my setup thoroughly before
raising the issue.

Thanks again,
Joe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]