From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3672 invoked by alias); 27 Sep 2011 01:48:48 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16435 Received: (qmail 13210 invoked from network); 27 Sep 2011 01:48:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.210.41 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJ+K/Xr0ZUUvo8DszGMa1RMgwXHvVOCqRILxxP0rrHw=; b=ew6sqAULDlXL8g9JeDI6kdoJmscPY/YchLnhHsct7BoLsiCgTFqeq2PBUyc8AHe9S+ PM6BW8gD/ss5KK+QXNZC7iBoFuUdQGQb7l2sl+wQoGjk2+fzQAWpFiRlRDVuioifCu8m 1w2YC1/Wgi1Sj/G39OZmilv8Y8GrCzD9fOffw= MIME-Version: 1.0 In-Reply-To: References: <110924112412.ZM24918@torch.brasslantern.com> <110925151330.ZM20235@torch.brasslantern.com> Date: Mon, 26 Sep 2011 18:48:41 -0700 Message-ID: Subject: Re: prompts with newlines get printed twice From: =?UTF-8?Q?Jorge_Israel_Pe=C3=B1a?= To: Bart Schaefer Cc: zsh-users@zsh.org Content-Type: multipart/alternative; boundary=bcaec544eaf2a2191d04ade27971 --bcaec544eaf2a2191d04ade27971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=B1a > Just wanted to follow up. It seems like multiline prompts cause zsh to ex= it > ([Process Completed]) when I do tab completion more than once: > > cd ~/.vim[Process Completed] > > I have made sure this is what's causing it. > > 2011/9/25 Jorge Israel Pe=C3=B1a > >> 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=C3=B1a >> >>> 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 th= ere'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 thi= s >>> 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=C3=B1a >>> >>>> 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 func= tion >>>> or any of that stuff. >>>> >>>> I saw your post on the workers mailing list, thanks again for taking t= he >>>> time to look into it. Hopefully now that you've brought attention to t= his it >>>> could be discussed by people more knowledgeable with the zsh source an= d >>>> 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=C3=B1a >>>> >>> >>> >>> >>> -- >>> - Jorge Israel Pe=C3=B1a >>> >> >> >> >> -- >> - Jorge Israel Pe=C3=B1a >> > > > > -- > - Jorge Israel Pe=C3=B1a > --=20 - Jorge Israel Pe=C3=B1a --bcaec544eaf2a2191d04ade27971--