From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30111 invoked from network); 31 Dec 2022 03:52:53 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 03:52:53 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1672458773; b=sqQyb15nW15THhONU9rq5XSSm94kY+xDlFFMDk2E4ibaTeJVbR+x5Dy5JknQkUFXUA4EmOSpBc 4i2ERPuX1yKpY3lp2M9I5YA4xUkdT5X8XRVzojWYlG/rmamS7NmuiRoqorpUEd/6m1M1W7q0XG wKyiZR41eZX9obD4DtEeM8tRJTJpOcbPPRhmQIq68xoc/Qa+L9FbcESdhT7i887yCFwK11imo/ 9iro407wb8uOaDqRGZvEcnnIlqQJBc0VIohBA1vKO39H8Z86wE4isIYJ3y8JPJhGoPp1J1CbqW HRU/DaEdSMv0d7/hLtS5VnRG+fxvQvqCbDqNuAwrXuMwSQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-yw1-f177.google.com) smtp.remote-ip=209.85.128.177; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1672458773; bh=zrLB08lKxzYEQGzNpo0G48vHZJbEOSPPYrHAdaFsCEI=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=QaINTsTaVdKcD4dU/rwSvWnowqKDhvEMcRmXvVTOnFmlEgoq5m1bLy4zc6byUruN/Q1pmz1G0i WRmB2gevap25/Cf/3pnfmJ/u5e5Zve1Atkos8pR950xxCl/XvV4KNgfoxcc0kvJut0XbCuzAap AMKheryvZ5UOESWbTtnKH0zGiQAGhzQbHYfuIGrg5o/y1hmpuHj9dcn1b9j2znp3uIH2jzTvlv wBRuma88SA6l9MFtTUVQbUZobIvS5V+Wn9pTM1hFfFNAdNNnUwXYoNWMgQjxzrKa0XDlofFv9E INbltl/umIFfF+M8TjovGxA8BaDGExCh4NN6mdiwsGIcnA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=+mAskN1SmuteQHImbD+GYptx/vYOKisSzxkra681pAk=; b=GZkcFBc4V6ZMkx6ZRf9LNFJmhW RQLiBq6yrXFYfE6EOxHVsnQmAQK6zXQ+r9bCMyumJq2KZ/EJj6t+307JTCkhTE0Ou+G/KcOKib4W/ L9DqLUwsO7airG/xgcaH3CKwvhcNyOAyNx848bDNKdnAXLD+culzJKrpgx1aSzs1MF/pQaOwS4tcJ mx+6HOET2D5ofq62pwvW3wekyqzJFweeOjFzEM2xJ1AvZf8PSKKGmczOMv+iKIDCd/7N7T4bEylK0 VbOhAGA+jzjZNa2hIZA3ZiTVverbqQjhXPHEAHvJkqxD6c0VUzjqG2+uoqaa2ghTqHFYqRPgtV2HD SqDD4jMA==; Received: by zero.zsh.org with local id 1pBSvT-000JQ0-H3; Sat, 31 Dec 2022 03:52:51 +0000 Authentication-Results: zsh.org; iprev=pass (mail-yw1-f177.google.com) smtp.remote-ip=209.85.128.177; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-yw1-f177.google.com ([209.85.128.177]:36861) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pBSuv-000J6A-LX; Sat, 31 Dec 2022 03:52:18 +0000 Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-482363a1232so164432097b3.3 for ; Fri, 30 Dec 2022 19:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+mAskN1SmuteQHImbD+GYptx/vYOKisSzxkra681pAk=; b=YYu8cjJ6erwyetN8vT4ZzwIGPFp8ZmeUpPZoJNQ+syPhvswCucQBDbmhN4BjU2sMvk c0FG6e/kASjSFaDMCuKK3E9E0LBj4oxo1SsLQpJGI3rjARZwyfe9/fn+ZAdI1Itw0L0o 4cf3CJGbmTq7GaajW/KwcRCC+xQrM2cm+ZHuD3RapClG7aCjnownG3XWYaV2BbdYK3N9 oL3DEI0XQ3WMzla+ajTo4pKNswTIrQJzLeuKZ322NR9tgUCr5O2v32icUz4XBpU7IQIV 7w4inlbs3PfPrOpeC7J2aVYoR4XhQrsymw6sr7c1aFhcbqwA5t3Pa9hFaDZV2titY/zu BDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+mAskN1SmuteQHImbD+GYptx/vYOKisSzxkra681pAk=; b=j2L/V635iC3amMiL1jInqQZQhj0V1WqgcIMSMTZbCyxY28A14kuQ6WOHktQhpLG0S+ kB2Q2h4MifrtYM1f6UX1Q2sslh1TSb+KxkOj3R48LZm/Ot5ZuUO7ay1VJswid6xa5B6N /cYLYx1gYQvl6ytSfANhZsd2C7W1ekBaJXBLeUpvBcdRGuxR7C2iBBnpxD3+/XfCOdMk oUlWhpjFI/fCaQM4137YFYFrzJFby9M7cEyUFivOtAaDFwcHWNUzZW6d0iAdab+NHkI/ 9BsUPIpT67LzKChFRLe/8/oatiugqQb8eLsDVRYKk/5g9GrHB7u2VLj/i/ISQi8Jqt6c BNiw== X-Gm-Message-State: AFqh2kpw/DkLCxfhMq3EdqsJJfgwt2L0PmPE+/A8XZE+iFMg/Mxh+9qc hFWoGCCClrFbeyJBaWHCQAcoDucA9ZKpSHeFU33+KzN7uK8t9iVo2OY= X-Google-Smtp-Source: AMrXdXsQ2tHTlBzgKTKM7CJe2DQ120DXBcMyX9+s78ctwbzWYVNN28d8gui7Wlg7L/z9meXNA2Y4yoVowYULW5nFSeM= X-Received: by 2002:a81:4e8b:0:b0:471:d0:fcdf with SMTP id c133-20020a814e8b000000b0047100d0fcdfmr2492599ywb.108.1672458736277; Fri, 30 Dec 2022 19:52:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: OG Code Poet Date: Fri, 30 Dec 2022 19:52:05 -0800 Message-ID: Subject: Re: Read a line from user without clearing screen below the prompt while allowing user to use arrow keys to make edits in middle of line To: Bart Schaefer Cc: Zsh hackers list Content-Type: multipart/alternative; boundary="000000000000e09e8d05f117a452" X-Seq: 51264 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: --000000000000e09e8d05f117a452 Content-Type: text/plain; charset="UTF-8" Here's some more context. I have an interactive CLI application built using zsh, and am already using alternate screen to draw contents in it. vared's default behavior (of clearing current line of cursor and below) makes sense when a script calling vared does not use alternate screen. This is because screen contents on and below the current cursor position (after vared is called) in an interactive shell are mostly not exciting (generally empty). But the same is not true for applications that use alternate screen and paint entire screen with text. Let's say the application designer wants to use the first line on screen to get user input. They might not want any other line on screen to get cleared or moved when vared is called. But that doesn't seem possible with vared, as vared clears from current line the cursor is on to everything below. IMO, vared makes an assumption that is limiting (something that ``bash -e -p`` doesn't). It would be nice to have a switch that disables vared's clearing behavior, and leaves it on developer to insert commands to clear line/s. Till such a switch exists, is it possible to zle and bypass such clearing? Here's an example that shows vared always clears lines on and below the cursor position on the screen. ``` tput smcup; tput clear; tput cup 0 0 for ((i=1;i wrote: > (Leaving this on -workers because of the possible bug mentioned at the > end.) > > On Thu, Dec 29, 2022 at 9:38 PM OG Code Poet wrote: > > > > Using Bash ``tput cup 0 0; read -e -p "Enter input: " userinput`` works > well for getting a line of user input: > > > > * It does not clear screen below the prompt > > * It allows user to use arrow keys to go to middle of line and edit a > mistake they might have made while typing > > Bash is invoking the GNU "readline" library for the "read" builtin. > Unlike ZLE, which despite having "line" in its name attempts to be a > reasonable multi-line editor, readline is designed to do exactly what > its name says, so it doesn't do any other screen prep. > > > How can this be achieved in zsh? > > Closest I can come up with is this: > > vared-finish() { tput rc } > zle -N vared-finish > tput sc > vared -f vared-finish -c -p "%{$(tput cup 0 0)%}Enter input: " userinput > > However, this is not entirely satisfactory because the finish widget > is not invoked if this is interrupted by ^C or ^G (send-break), and > vared then clears the screen before exiting. This is possibly a bug? > Shouldn't the finish widget(s) always be run when the line editor > exits, even if it exits "abnormally"? (This affects the PS1 ZLE as > well.) > --000000000000e09e8d05f117a452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's some more context. I have an interactive C= LI application built using zsh, and am already=C2=A0using alternate screen = to draw contents in it. vared's default behavior (of clearing current l= ine of cursor and below) makes sense when a script calling vared does not u= se alternate screen. This is because screen contents on and below the curre= nt cursor position (after vared=C2=A0is called) in an interactive shell are= mostly not exciting (generally empty). But the same is not true for applic= ations that use alternate screen and paint entire screen with text. Let'= ;s say the application designer wants to use the first line on screen to ge= t user input. They might not want any other line on screen to get cleared o= r moved when vared is called. But that doesn't seem possible with vared= , as vared clears from current line the cursor is on to everything below. I= MO, vared makes an assumption that is limiting (something that ``bash -e -p= `` doesn't). It would be nice to have a switch that disables vared'= s clearing behavior, and leaves it on developer to insert commands to clear= line/s. Till such a switch exists, is it possible to zle and bypass such c= learing?

Here's an example that shows vared al= ways clears lines on and below the cursor position on the screen.

```
tput smcup; tput clear; tput cup 0 0
for (= (i=3D1;i<LINES;i=3Di+1)); do
=C2=A0 =C2=A0 printf '%s\n' &quo= t;$i. Hello world"
done
printf "\e[31m$i. Hello World\e[0m&= quot;
tput cup $((RANDOM%LINES)) 0
sleep 1
vared -f vared-finish -= c -p "%{$(tput cup 0 0)%}Enter input: " userinput
tput rmcupecho "User entered: $userinput"
```
P.S. I posted this to zsh-workers with an imagining that this l= ikely will turn into a feature request or bug report.

<= /div>
O= n Fri, Dec 30, 2022 at 9:56 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
(Leaving this on -workers because of the possible bug mentioned = at the end.)

On Thu, Dec 29, 2022 at 9:38 PM OG Code Poet <ogcodepoet@gmail.com> wrote:
>
> Using Bash ``tput cup 0 0; read -e -p "Enter input: " userin= put`` works well for getting a line of user input:
>
> * It does not clear screen below the prompt
> * It allows user to use arrow keys to go to middle of line and edit a = mistake they might have made while typing

Bash is invoking the GNU "readline" library for the "read&qu= ot; builtin.
Unlike ZLE, which despite having "line" in its name attempts to b= e a
reasonable multi-line editor, readline is designed to do exactly what
its name says, so it doesn't do any other screen prep.

> How can this be achieved in zsh?

Closest I can come up with is this:

vared-finish() { tput rc }
zle -N vared-finish
tput sc
vared -f vared-finish -c -p "%{$(tput cup 0 0)%}Enter input: " us= erinput

However, this is not entirely satisfactory because the finish widget
is not invoked if this is interrupted by ^C or ^G (send-break), and
vared then clears the screen before exiting.=C2=A0 This is possibly a bug?<= br> Shouldn't the finish widget(s) always be run when the line editor
exits, even if it exits "abnormally"?=C2=A0 (This affects the PS1= ZLE as
well.)
--000000000000e09e8d05f117a452--