Re: How can one tell rlang not to mess up R session in ESS ?
Deepayan Sarkar via ESS-help <[email protected]> Tue, 14 Nov 2023 12:03:57 -0500
| Newsgroups | gmane.emacs.ess.general |
|---|---|
| Message-ID | <CADfFDC6aQ6F6o+dyV=S+6u4ORTzN1U4TjdG6Pe1T7t34XfofNA@mail.gmail.com> |
On Tue, 14 Nov 2023 at 11:46, Dirk Eddelbuettel via ESS-help <[email protected]> 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 | [email protected] > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/ess-help