On Tue, 14 Nov 2023 at 11:46, Dirk Eddelbuettel via ESS-help <ess-help@r-project.org> wrote: > > > On 14 November 2023 at 17:22, Lionel Henry wrote: > | Worth noting I'm using `xterm-color` instead of `ansi-color` in my > | comint buffers. IIRC the latter (which is builtin) didn't support some > | features. Not sure if that could explain the bad behaviour you've > | observed. > > I was also thinking cli could take advantage of TERM. In ESS under x11 and on > the terminal I seem to see > > > Sys.getenv("TERM") > [1] "dumb" > > > > so I guess ESS (or Emacs?) overrides because I otherwise settled on TERM and > BYOBY_TERM as screen-256color which is decent setting for Nord. > > Back to rlang and cli messing up sessions they maybe should leave alone: > would the team consider not asking the user to set NO_COLOR and rather > inspect the terminal info and refraining from damaging working setups?
Not that I know a lot about this, but... Despite Sys.getenv("TERM") being "dumb", Emacs can actually handle ANSI color codes, and, e.g., I get a nice red cross sign with > cli::cli_alert_danger("stop") ✖ stop (which is no longer red when I copy-and-paste). Are you suggesting that we should not be getting that by default? I know I can still probably force it by setting options(cli.ansi = TRUE, cli.num_colors = 256) etc. Best, -Deepayan > > Best, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > ______________________________________________ > ESS-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help ______________________________________________ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help