From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id eeeee5c2 for ; Sun, 19 May 2019 17:35:40 +0000 (UTC) Received: (qmail 25227 invoked by alias); 19 May 2019 17:35:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44323 Received: (qmail 21758 invoked by uid 1010); 19 May 2019 17:35:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f44.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25454. spamassassin: 3.4.2. Clear:RC:0(209.85.166.44):SA:0(-2.0/5.0):. Processed in 1.638994 secs); 19 May 2019 17:35:29 -0000 X-Envelope-From: roman.perepelitsa@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.44 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XVAfH8k0ZJoJkB6vS/mXX2FjHTrXBg/jrM7SABlPr0c=; b=MNoWJq5yzW2Ak+tyT1XZBt1oM1ldtcuQxLGkQE+K/m9KZpBpy+ibcyWom+Qq782vrr lM6dTjw4rwE+dIjFDtLa3XQ0Bzw1Mk872wQCC84JZOf+fnb0twL18L4C39UR+NFAJnfw I0SunRvWrOJLd6Xb8o4Vesym4SGAHtluHd213I6Xjxf/AqaJpfnKbL8B09SfjvmZM/06 7hoONuQgQTzmxtLLQj7UmP4p2O9C9WmwyCGzdMEqfjP4K/O4Tsq69WhINpCEIytSqggC 6EAVhnXEuKtP/m0jdtLJ9eJaRUBObpNwiFXHjQHFKMI4vujMn1qeSR5q3ZS9B/qUqD3t Cwog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XVAfH8k0ZJoJkB6vS/mXX2FjHTrXBg/jrM7SABlPr0c=; b=qpR2Qksg9212gzs9pkdaiNkS1WR+h+1SE56AQ+V5SKeNkg4qipxFzgObwQk8o5wzo/ kaanSEIWdnc/1NPB8ZLL+Gj5wGcOG2MIUFqUBw8C2OungiLU9dsvzCuy5CdmJao0gpAu SkYRNAPqine2M7XlKCnmd5LJ/sErhAAnF/SvqL8Z006lStPwFjMHn4KrYLZ/hpd47oPi Z2jXetEtA03MAURoQXC1QimlgGB3tBvYgd29wGq1zV4ey1JB/jRe3ip0v+bONBFsb2wr HtgwbtpIPatsZEwpl1vpG/LPIrxcn1SaK7gOmvtJko/UkN9h3GQ387TT0nQ9qv3+cOnS x3tg== X-Gm-Message-State: APjAAAV48qt1Nn6JucfraY8knhhJGWWqnfw20TgwvQODX+CeSAz7AG15 MimO+tPmFCqlGbxR6JPbTH3EutafdoFS7EFh3b/0u4p6 X-Google-Smtp-Source: APXvYqz4BoDXFRj5uOoSTB4GSZukgfUEDcSxdEEzppGVZNq78uyBMP71PEEyQ2UCk974iodqqaX1rWYJAUIzRgPyTJ4= X-Received: by 2002:a5e:9607:: with SMTP id a7mr11921814ioq.151.1558287295402; Sun, 19 May 2019 10:34:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Perepelitsa Date: Sun, 19 May 2019 19:34:44 +0200 Message-ID: Subject: Re: Incorrect cursor position when ZLE_RPROMPT_INDENT=0 (with a fix) To: Bart Schaefer Cc: "zsh-workers@zsh.org" Content-Type: multipart/alternative; boundary="000000000000b356dc058941084f" --000000000000b356dc058941084f Content-Type: text/plain; charset="UTF-8" On Sun, May 19, 2019 at 7:05 PM Bart Schaefer wrote: > We constantly go around on this. If we un-break it for one terminal > type it breaks for another. It's an acknowledged problem that in some > cases you can't set ZLE_RPROMPT_INDENT=0, that's why the variable > exists in the first place; if it always worked to set it to zero we'd > remove it. > > All your patch does is remove a test for the value of that variable. > A more correct change would be to add to the test condition a check > for whether placing a character in the rightmost column (or the > rightmost/bottom-most position) causes the terminal to auto-wrap (or > not) the cursor onto the next line. At first I thought that on my terminal (GNOME Terminal) there is auto-wrapping when RPROMPT is written at the very right edge. It can be seen when I set RPROMPT='%K{red}X' and ZLE_RPROMPT_INDENT=0, which results in an extra line below the prompt with a red cell on the left. Then, after some debugging, I realized that it's not my terminal that causes auto-wrapping but ZSH. zputs(rpromptbuf, shout) at zle_refresh.c:1680 doesn't create that new line even when ZLE_RPROMPT_INDENT=0. The following ZSH code does. That's why my patch doesn't just disable a condition but also adjusts vcs after zputs(rpromptbuf, shout). Do I understand you correctly that prior to my patch ZSH handled ZLE_RPROMPT_INDENT=0 correctly on terminals that do auto-wrap after RPROMPT is written, but my patch broke them? If so, could point me to such a terminal? It would be very helpful. I realize that you've had this discussion a million times and I appreciate your patience. What $ZSH_PATCHLEVEL were you testing against? There was a related > change committed only a month ago, and there has not been a release in > the meantime. > echo $ZSH_PATCHLEVEL zsh-5.7.1-77-gfae7c85 My fork is currently 1 commit ahead of zsh-users/zsh on github. Roman. --000000000000b356dc058941084f--