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 ccd3f461 for ; Mon, 20 May 2019 12:42:47 +0000 (UTC) Received: (qmail 22252 invoked by alias); 20 May 2019 12:42:33 -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: 44341 Received: (qmail 28091 invoked by uid 1010); 20 May 2019 12:42:33 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm1-f52.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.128.52):SA:0(-2.3/5.0):. Processed in 2.329074 secs); 20 May 2019 12:42:33 -0000 X-Envelope-From: charlechaud@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.128.52 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=XVN2H4ALcjqurxByIJIv4btdmeVhg7Ek2ufsrLdA9vQ=; b=myUMhRtIvJLe6fCZ6EeNzmXcuPXWwlzpkfhKnhmogo3KcncNoc+DzKo/RcOpcQkVR6 faREAiGQRT1yIouWjEkcCoVeTrx4mM8x1rslfttvNimBZC/mbW2tl7hciCrIxMqGAwnm zwDeMwpxeVo0abnlWpVtHKS6PJJQ4d+qkSuyk5PCFxwWCRw2FLxKEdmbo9rPUJW7L/Po 8f5Hddvz0CEfN00n6/OR5JggXLTTUABM10OlPc8tFwmI/jc5+KDg1X2VqF9o3Uli63Uu ELQ9FkWfmOhbKn/lRog2aQSsD0KgoeFxj8bCoUu9lYCjfC9Cz68uERvRQG0ba8C/PpKz 4PGA== 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=XVN2H4ALcjqurxByIJIv4btdmeVhg7Ek2ufsrLdA9vQ=; b=jVEZ1O4lrDRJv4Nx1uHDhup7vubHSs4pPMn9SzVzZbfAzOL4bHf3KjSuDg3AaCOlog Hk3Qy62CnydpGxHW3w2zt1L42dn6xf4iTBp4AVWJDdu5R8yUVfrv4XxBLaQ/hHZens4h EUxKfMO/PYTpBmed6WmsQ2ughcyaWXt2R/AMOKMFVtxFfEJTUj8ZT8Pqi5fwFjE4N9HP 8BQOTEXTM1TSFKP1o1wE+Bqbw0DZbcEqsll7R/MxX3CEtxyuUYZ3ZVOVdWxub6pa3jNH RPVCpuMaKSVdjwws1b2KfmzNAQ1u7kBsE6fERD97qsVaS4VGQbNcfXe14OHmrzf4BMJs ky8A== X-Gm-Message-State: APjAAAUmvOs1OxoMKRypogZjqk+CI9Fyp3GviCYsezBi4vRGVXjmClrz JK/M/xn8m94kFdCx6TB6hkgx71EGsZ2pXENdfhxeiqWsAE8= X-Google-Smtp-Source: APXvYqwAx5xdZ58ALI0IuR7QmKxTKiZ5A0aqzewbr17C0S3zhPWIF7Iln+Fkw0w//ZZC5od3Qq8trCOVaNskpW0zbVg= X-Received: by 2002:a1c:7312:: with SMTP id d18mr11766756wmb.147.1558356117285; Mon, 20 May 2019 05:41:57 -0700 (PDT) MIME-Version: 1.0 References: <68081d8c-1aa6-203b-eb6c-e2d048de1340@ibr.cs.tu-bs.de> In-Reply-To: From: Charles Blake Date: Mon, 20 May 2019 08:41:21 -0400 Message-ID: Subject: Re: Incorrect cursor position when ZLE_RPROMPT_INDENT=0 (with a fix) To: Roman Perepelitsa Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="000000000000cdee070589510ef1" --000000000000cdee070589510ef1 Content-Type: text/plain; charset="UTF-8" So, feel free to confirm yourself with xterm -rw or resource/default or menu setting of reverseWrap, but with your patch and reverseWrap enabled, I get incorrect behavior of a different sort. The cursor is not left immediately after the 2, but there is an intervening blank space of exactly 1 character. Flipping the menu item on/off and hitting enter in the shell to force a refresh toggles the misbehavior. As to whether this should be a "supported configuration", well that is for the larger audience to decide. Obviously for N config bools there are 2^N configs and supporting them all is probably between impractical and impossible. However, the xterm man page under the -rw option section says this one is specifically encouraged: This is very useful for editing long shell command lines and is encouraged. I'm not sure why reverseWrap is not on by default..You'd have to ask Tom Dickey that, but I would guess it is to support some popular shell/usage mode. Or maybe the feature and documentation are vestiges from some long bygone era. I haven't looked into it much. In better news, I also got things to work both with/without your patch in emacs shell mode under X11 emacs as well as terminal mode emacs -nw. --000000000000cdee070589510ef1--