From: Kevin Buettner <kevinb@redhat.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/styling: only check TERM environment once, during initialisation
Date: Wed, 19 Feb 2025 16:58:26 -0700 [thread overview]
Message-ID: <20250219165826.64dfe432@f41-zbm-amd> (raw)
In-Reply-To: <e6b43feb7e9c3bdbca101d4972902b4eb0cc3e74.1739997039.git.aburgess@redhat.com>
On Wed, 19 Feb 2025 20:31:04 +0000
Andrew Burgess <aburgess@redhat.com> wrote:
> We currently check the TERM environment variable any time we call one
> of the ui_file::can_emit_style_escape() functions. This seems
> excessive.
>
> During GDB's startup we also check for the NO_COLOR environment
> variable and disable styling if this is set.
>
> I propose that we combine these two checks, and perform them just once
> during startup (as the current NO_COLOR check is currently done). As
> with the NO_COLOR check, if the TERM variable is set to "dumb"
> indicating that styling is not supported then we should just set
> cli_styling to false.
>
> This does mean that the user can then 'set style enabled on', even for
> a dumb terminal, which was not possible previously. Before this
> commit the "dumb" terminal check was separate and would prevent
> styling even if 'set style enabled on' was in effect.
>
> Of course, trying to turn on styling in a dumb terminal might not give
> the results that a user hope for. And so, I have implemented a check
> in `set_style_enabled`, so in a dumb terminal a user will see this:
>
> (gdb) set style enabled on
> warning: The current terminal doesn't support styling. Styled output might not appear as expected.
>
> After which GDB will try to emit styling. We could, potentially,
> prevent styling being enabled instead of emitting a warning, but I'm
> inclined to let the user turn on styling if they really want to.
This all makes sense to me.
I found one nit...
> diff --git a/gdb/ui-file.c b/gdb/ui-file.c
> index dd15ea427bc..14931f3aef9 100644
> --- a/gdb/ui-file.c
> +++ b/gdb/ui-file.c
> @@ -180,28 +180,12 @@ null_file::write_async_safe (const char *buf, long sizeof_buf)
>
> \f
>
> -/* true if the gdb terminal supports styling, and styling is enabled. */
> +/* Return true styling is currently enabled. */
I think you should add an "if" to the comment, i.e. "Return true if ..."
Approved-by: Kevin Buettner <kevinb@redhat.com>
Kevin
next prev parent reply other threads:[~2025-02-19 23:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 20:31 Andrew Burgess
2025-02-19 23:58 ` Kevin Buettner [this message]
2025-02-20 14:09 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250219165826.64dfe432@f41-zbm-amd \
--to=kevinb@redhat.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox