From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D53273858438 for ; Thu, 8 Jun 2023 22:44:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D53273858438 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 188821FDA3; Thu, 8 Jun 2023 22:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1686264271; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qf3KpgECiCEayns0+Esjoxk4vpBz785FdQ5hZkHRS84=; b=tTHAGuMiUCfxIdXXXxQsx6cXSmoE9wZnhQSGIJOOwoTyW/J1TMc7CF0v7Ni8xg0wHh7y2n ynCu477Y503oNiRByQGccLuFTg92z5tDnfdQP/FywepbVw0NLsJ4u9DR4cYiQRpMmPF3Z7 3tLl88ZsMNiAn2Z8vicwM6aEq3s9gs4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1686264271; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qf3KpgECiCEayns0+Esjoxk4vpBz785FdQ5hZkHRS84=; b=RiRi470eVH4fc7dcbYM+05P5GWDIk6QAFIFZ2LuePO7MDAZEvtG0bzsf4lE7TKTxWpgOvd IcQKJSHMVq+jaIDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 03136138E6; Thu, 8 Jun 2023 22:44:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Up0RO85ZgmQhOQAAMHmgww (envelope-from ); Thu, 08 Jun 2023 22:44:30 +0000 Message-ID: <26eace21-84bf-7d9d-051b-93f2bc38edd7@suse.de> Date: Fri, 9 Jun 2023 00:44:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] [gdb/tui] Handle unicode chars in prompt Content-Language: en-US From: Tom de Vries To: Tom Tromey , Tom de Vries via Gdb-patches References: <20230526132512.29496-1-tdevries@suse.de> <0c1512d8-0912-044d-6c12-ec93de068b87@suse.de> <875y89wy48.fsf@tromey.com> <678ad6f8-b39e-0f0d-5933-62f81c44d27c@suse.de> In-Reply-To: <678ad6f8-b39e-0f0d-5933-62f81c44d27c@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_LOTSOFHASH,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/31/23 13:29, Tom de Vries wrote: > On 5/30/23 19:03, Tom Tromey wrote: >>>> In TUI, the prompt is written out by tui_puts_internal, which >>>> outputs one byte >>>> at a time using waddch, which apparantly breaks multi-byte char >>>> support. >>>> Fix this by detecting multi-byte chars in tui_puts_internal, and >>>> printing them using >>>> waddnstr. >> >>> FWIW, I just came across this commit, which seems relevant: >> >> Tom> Note that tui_puts_internal remains.  It is needed to handle >> computing >> Tom> the start line of the readline prompt, which is difficult to do >> Tom> properly in the case where redisplaying can also cause the command >> Tom> window to scroll.  This might be possible to implement by >> reverting to >> Tom> single "character" output, by using mbsrtowcs for its side >> effects to >> Tom> find character boundaries in the input.  I have not attempted this. >> Tom> ... >> >> I no longer remember what made this difficult.  I wonder if it's >> possible to simply emit as many characters as possible in a single call, >> and then use getyx to figure out the length of the prompt after it has >> been fully displayed.  If the prompt wraps or if it takes multiple >> lines, offhand it seems fine to just pick whatever the final column >> happens to be. > > I've given that a try, and that seems to work. > > I also realized that we don't cover wrapping prompts in the testsuite, > so I wrote a test-case ( > https://sourceware.org/pipermail/gdb-patches/2023-May/199950.html ). I've committed the test-case (excluding the proposed fix for now), with an extra check that FAILs in combination with this patch: ... FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: end of screen: scrolling ... because we have: ... 17 (gdb) set prompt 123456789A123456789B123 18 456789C123456789D> 19 123456789A123456789B123456789C123456789D 20 123456789A123456789B123456789C123456789D 21 123456789A123456789B123456789C123456789D 22 >set prompt (gdb) 23 (gdb) ... instead of the expected: ... 19 (gdb) set prompt 123456789A123456789B123 20 456789C123456789D> 21 123456789A123456789B123456789C123456789D 22 >set prompt (gdb) 23 (gdb) ... The logic I used in this patch: ... + if (height != nullptr) + { + int line = getcury (w); + *height += line - prev_line; } ... was to use the current line to detect a wrap but that doesn't work if writing the prompt wraps at the last line which then generates a scroll. This is the reason that a wrap is detected in the original code using a reduction in wrap position. But AFAIU that doesn't work either for this "maximum-string" approach. If the string is long enough, it's possible to wrap and increase column position. In conclusion, AFAIU this approach doesn't work. Thanks, - Tom