From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /L5ABJ5y5mbNgisAWB0awg (envelope-from ) for ; Sun, 15 Sep 2024 01:37:34 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=jxBFsgXf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EC6B61E353; Sun, 15 Sep 2024 01:37:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-12.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED, URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 309C71E05C for ; Sun, 15 Sep 2024 01:37:32 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 636BE3858C66 for ; Sun, 15 Sep 2024 05:37:31 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D316D3858D20 for ; Sun, 15 Sep 2024 05:37:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D316D3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D316D3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726378632; cv=none; b=r4oEipPaISaht0f0fcFU9yQIu7fqcjrcAAu06d3FY5Fj/TVG3G0OjBjRU1qcoEQuxjyxPLjZSkfiBrwCVvFJ+TLchxHdAsjO0sIg1XD0uH43nIP1W6Mf+H6cxCQ3CHw4iGOpf9qf2xmgIso4HOaNfATOcFYXgJK9r/0nh2nKEU0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726378632; c=relaxed/simple; bh=G6afQEkthOy9rAWiXonpy7OMhpboUc4JgsCXjKaya5A=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=fbvDxSjXiXpQY/t1qAGF3mQuWITOGtzHfut5Up8ZyvX8Y8z6PE/oObJAPtzGn2GLL80QmPCXhRVZkDfhz7DIEowbWtmj+I8sVhHPDT1nw39Oij4bTR0mqvmr0nWBc80aeY8x/2cHrFnabXADGXW+h4DElzLsNmZx1Mfpa4WcXPg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sphwb-0002z9-QD; Sun, 15 Sep 2024 01:37:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vmOprUzIOTJEuGyeQiBlyxrWYqVwLBbBO/aAY4WXjok=; b=jxBFsgXfc8GW b/cNgLX+zD1+3rXIx9Ba7bGNoD8SiWTf+ttS2Qrn/RISTgeSbb9Luewx90y6EJlfShyhkSFRa2nkF u6i7R/yXhpDLlAZRgMcfOEILzU46RAK1Oy6hzpACNKNZRo10rf+Vn9KdBJHBLldT97DxBnRo0a93/ n/PqtlceXlMoTPcHn5Q8BqW/AFqHYGTqRWAZBwvb3qKA6NDz8f2jLCELBO8n07wfki/asq5CLFjG+ 1lVVN1iZ8/JNSJddY6Iike5cDE5WIvgyckr+ZjZjfddEZ3JaOT6AWbRzPMEP3+BbUtlGho6gwwPdf XnAP7tmSscnnD62dZtpvwA==; Date: Sun, 15 Sep 2024 08:37:06 +0300 Message-Id: <86seu1eav1.fsf@gnu.org> From: Eli Zaretskii To: Andrei Pikas Cc: tom@tromey.com, gdb-patches@sourceware.org, gdb@mail.api.win In-Reply-To: <20240914190452.423367-1-gdb@mail.api.win> (message from Andrei Pikas on Sat, 14 Sep 2024 22:04:52 +0300) Subject: Re: [PATCH v7] Add an option with a color type. References: <87mskb1f83.fsf@tromey.com> <20240914190452.423367-1-gdb@mail.api.win> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: Andrei Pikas > Cc: gdb-patches@sourceware.org, > Andrei Pikas > Date: Sat, 14 Sep 2024 22:04:52 +0300 > > Colors can be specified as "none" for terminal's default color, as a name of > one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc., > as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an > integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard > colors. Integers 8-15 are used for the so-called bright colors from the > aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm > extended 256-color palette (usually 6x6x6 cube plus gray ramp). In > general, 256-color palette is terminal dependent and sometimes can be > changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\". > > It is the responsibility of the user to verify that the terminal supports > the specified colors. > > PATCH v5 changes: documentation fixed. > PATCH v6 changes: documentation fixed. > PATCH v7 changes: rebase onto master and fixes after review. > --- > gdb/Makefile.in | 2 + > gdb/NEWS | 29 ++ > gdb/cli/cli-cmds.c | 7 + > gdb/cli/cli-decode.c | 174 +++++++++ > gdb/cli/cli-decode.h | 21 + > gdb/cli/cli-option.c | 44 +++ > gdb/cli/cli-option.h | 21 + > gdb/cli/cli-setshow.c | 21 + > gdb/cli/cli-style.c | 49 +-- > gdb/cli/cli-style.h | 4 +- > gdb/command.h | 26 +- > gdb/doc/gdb.texinfo | 38 +- > gdb/doc/guile.texi | 104 +++++ > gdb/doc/python.texi | 97 +++++ > gdb/guile/guile-internal.h | 9 + > gdb/guile/guile.c | 1 + > gdb/guile/scm-color.c | 443 ++++++++++++++++++++++ > gdb/guile/scm-param.c | 33 +- > gdb/python/py-color.c | 347 +++++++++++++++++ > gdb/python/py-color.h | 35 ++ > gdb/python/py-param.c | 38 +- > gdb/python/python.c | 7 + > gdb/testsuite/gdb.base/style.exp | 197 ++++++++++ > gdb/testsuite/gdb.guile/scm-color.exp | 110 ++++++ > gdb/testsuite/gdb.guile/scm-parameter.exp | 47 +++ > gdb/testsuite/gdb.python/py-color.exp | 100 +++++ > gdb/testsuite/gdb.python/py-parameter.exp | 53 +++ > gdb/testsuite/lib/gdb-utils.exp | 22 +- > gdb/testsuite/lib/gdb.exp | 3 +- > gdb/top.c | 14 + > gdb/ui-style.c | 331 ++++++++++++---- > gdb/ui-style.h | 142 ++++++- > gdb/unittests/style-selftests.c | 6 +- > 33 files changed, 2414 insertions(+), 161 deletions(-) > create mode 100644 gdb/guile/scm-color.c > create mode 100644 gdb/python/py-color.c > create mode 100644 gdb/python/py-color.h > create mode 100644 gdb/testsuite/gdb.guile/scm-color.exp > create mode 100644 gdb/testsuite/gdb.python/py-color.exp Thanks. > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -37,11 +37,40 @@ > history has been reached. It also specifies that the forward execution can > continue, and the recording will also continue. > > +* "set style" commands now supports numeric format for basic colors > + from 0 to 255 and #RRGGBB format for TrueColor. > + > +* New built-in convenience variable $_colorsupport provides comma-separated > + list of color space names supported by terminal. It is handy for > + conditionally using styling colors based on terminal features. For example: > + > + (gdb) if $_regex ($_colorsupport, ".*(^|,)rgb_24bit($|,).*") > + >set style filename background #FACADE > + >else > + >if $_regex ($_colorsupport, ".*(^|,)xterm_256color($|,).*") > + >set style filename background 224 > + >else > + >set style filename background red > + >end > + >end > + I'd prefer to have a plain-English explanation of "color space" here, instead of trying to explain it via script which uses the variable. > --- a/gdb/cli/cli-style.c > +++ b/gdb/cli/cli-style.c > @@ -42,20 +42,6 @@ bool source_styling = true; > > bool disassembler_styling = true; > > -/* Name of colors; must correspond to ui_file_style::basic_color. */ > -static const char * const cli_colors[] = { > - "none", > - "black", > - "red", > - "green", > - "yellow", > - "blue", > - "magenta", > - "cyan", > - "white", > - nullptr > -}; I don't understand the effect of this and related changes, and the log message says nothing about this. Could you please explain why you remove these names and their uses, and what will be used in their stead? And why? Regardless, were these changes tested in the MinGW port of GDB? It emulates Posix terminal handling of colors via SGR escape sequences, and I wonder whether these changes might somehow break styling support in the MinGW port. > +@item $_colorsupport > +@vindex $_colorsupport@r{, convenience variable} > +Comma-separated list of color space names supported by terminal. Names could > +be any of @samp{monochrome}, @samp{ansi_8color}, @samp{aixterm_16color}, > +@samp{xterm_256color}, @samp{rgb_24bit}. E.g., for plain linux terminal the > +value could be @samp{monochrome,ansi_8color} and for terminal with truecolor > +support it could be > +@samp{monochrome,ansi_8color,aixterm_16color,xterm_256color,rgb_24bit}. What does this return for the MS-Windows terminal? aixterm_16color? IOW, will any 16-color terminal return aixterm_16color? I think this should be documented, and perhaps we should remove the "aix" part from the name (since it is not necessarily specific to AIX). Also, please add a "@cindex color space" entry before the above text, as I believe this is where we describe this term. For the same reason, I think the first use of "color spaces" should have the @dfn markup. > -Set the background to @var{color}. Valid colors are @samp{none} > -(meaning the terminal's default color), @samp{black}, @samp{red}, > -@samp{green}, @samp{yellow}, @samp{blue}, @samp{magenta}, @samp{cyan}, > -and@samp{white}. > +Set the background to @var{color}. @var{color} can be @samp{none} > +(meaning the terminal's default color), a name of one of the eight standard > +colors of ISO/IEC 6429, index from 0 to 255 into terminal's color > +palette or a hexadecimal RGB triplet in @samp{#RRGGBB} format for > +24-bit TrueColor. Should the RGB specs always use 2 hex characters per component, or can one use RRRGGGBBB etc. as well? This should be documented.