I think it's because after the third tab, the directory gets reprinted and
each subsequent TAB makes it cycle through possible candidates. This
redrawing I imagine is somehow interfering with the trap cuu 2 WINCH
workaround.

2011/9/26 Jorge Israel Peña <jorgepblank@gmail.com>

> Just wanted to follow up. It seems like multiline prompts cause zsh to exit
> ([Process Completed]) when I do tab completion more than once:
>
> cd ~/.vim<TAB><TAB><TAB>[Process Completed]
>
> I have made sure this is what's causing it.
>
> 2011/9/25 Jorge Israel Peña <jorgepblank@gmail.com>
>
>> Actually, `man terminfo` showed me the `cuu` command which accepts a
>> parameter referring to the number of lines to move up. Changing the
>> aforementioned line to:
>>
>> trap 'tput cuu 2' WINCH
>>
>> seems to work consistently and does not make the prompt move down when
>> resizing the terminal :)
>>
>>
>> 2011/9/25 Jorge Israel Peña <jorgepblank@gmail.com>
>>
>>> Hey Bart, you said move up one less line than the amount you have. So I
>>> was playing around with the prompt by making it three lines (so that there's
>>> an empty line after the previous command's output, etc.) and the way I did
>>> it is:
>>>
>>> trap 'tput cuu1 tput cuu1' WINCH
>>>
>>> But I don't think this is the correct way? When I resize the terminal
>>> horizontally with this, the prompt keeps moving down by itself, but this
>>> doesn't happen when it's just one line and there is only one 'tput cuu1', so
>>> I have a feeling I'm doing it wrong. Would appreciate any comments.
>>>
>>>
>>> 2011/9/25 Jorge Israel Peña <jorgepblank@gmail.com>
>>>
>>>> Thanks for your time Bart.
>>>>
>>>> I have tested your workaround and it does seem to work! This seems
>>>> better because there is no need to wrap the prompt directive in a function
>>>> or any of that stuff.
>>>>
>>>> I saw your post on the workers mailing list, thanks again for taking the
>>>> time to look into it. Hopefully now that you've brought attention to this it
>>>> could be discussed by people more knowledgeable with the zsh source and
>>>> perhaps even get it fixed.
>>>>
>>>> For now I'm glad I have a workaround I can use in .zshrc at least :)
>>>>
>>>> Thanks again!
>>>>
>>>> On Sun, Sep 25, 2011 at 3:13 PM, Bart Schaefer <
>>>> schaefer@brasslantern.com> wrote:
>>>>
>>>>> On Sep 24,  4:24pm, Jorge Israel Pena wrote:
>>>>> }
>>>>> } So are there any known workarounds? Or is this something that would
>>>>> } have to be fixed in zsh itself?
>>>>>
>>>>> Until a few minutes ago I'd have said it was something that needed to
>>>>> be fixed in Terminal, but I may have found a zsh bug that's behind it
>>>>> all.  I've sent a possible fix to zsh-workers for discussion.
>>>>>
>>>>> On Sep 24,  5:14pm, Jorge Israel Pena wrote:
>>>>> }
>>>>> } Hey guys. I have extracted what I felt were the relevant parts from
>>>>> my
>>>>> } previously posted link. Like I said, I am no zsh expert (In fact I'm
>>>>> } completely new to it) so I don't know if this is right or if there
>>>>> are
>>>>> } more efficient, better ways of doing this.
>>>>> }
>>>>> } Source: https://gist.github.com/1240023
>>>>> }
>>>>> } I tested it various times and it seems to be working perfectly.
>>>>>
>>>>> I don't find any evidence that this helps except possibly by waiting to
>>>>> change the prompt until the first time the WINCH is received, which
>>>>> would avoid the startup-time double prompt.  I still get the prompt
>>>>> printed multiple times if I later resize the window.
>>>>>
>>>>> However,
>>>>>
>>>>>    trap 'tput cuu1' WINCH
>>>>>
>>>>> (that is, move up one line on each WINCH signal) might work around it
>>>>> for you.  If your prompt has more than two lines, you'll need to move
>>>>> up one less than the number of lines in the prompt.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> - Jorge Israel Peña
>>>>
>>>
>>>
>>>
>>> --
>>> - Jorge Israel Peña
>>>
>>
>>
>>
>> --
>> - Jorge Israel Peña
>>
>
>
>
> --
> - Jorge Israel Peña
>



-- 
- Jorge Israel Peña