How to avoid ANSI terminal control sequences when not running on a terminal?

[jidanni]

Description

In emacs compilation mode we see:

-*- mode: compilation; default-director
Compilation started at Wed Apr 22 01:02
quarto render example.qmd --to html
^[[0G^[[2K^[[J^[[0G^[[2K^[[J^[[0G
to: html
output-file: example.html
standalone: true

Is there some flag quarto --no-escape-sequences ?

Or maybe quarto should check $TERM first. If unset or dumb, don't assume an ANSI terminal.

[cookesan]

Try setting NO_COLOR=1 for the Emacs compilation command:

NO_COLOR=1 quarto render example.qmd --to html

Quarto vendors a colors module that explicitly honors the NO_COLOR environment variable and disables coloring when it is set. The Windows launcher also sets NO_COLOR=TRUE, which is a useful hint that this is the intended coarse switch for colorized console output.

If you are consuming logs programmatically, also look at:

quarto render example.qmd --log-format plain

or:

QUARTO_LOG_FORMAT=plain quarto render example.qmd --to html

plain is the default log format, but setting it explicitly removes ambiguity if Emacs/PTY detection is involved.

If the remaining sequences are progress-control sequences rather than color, then this may be a Quarto bug in terminal detection for Emacs compilation buffers. In that case, a minimal repro with NO_COLOR=1 included would be useful upstream.

[jidanni]

Thanks, but when running in emacs' M-x compile, we still see

$ NO_COLOR=1 QUARTO_LOG_FORMAT=plain \
quarto render /dev/null --to html
^[[0G^[[2K^[[J^[[0G^[[2K^[[J^[[0G

Yes, at the end even adding just |cat would prevent it, but that would be a hack.

[cookesan]

Thanks for testing that combination. That narrows it: NO_COLOR and QUARTO_LOG_FORMAT=plain are not the relevant switches because these are line-control/progress sequences, not color or log formatting.

In current source, clearLine() writes ansi.eraseLine.cursorLeft(), and the progress/spinner helpers write carriage-return progress messages. The log-file path also treats messages starting with \r as progress messages, which matches what you are seeing.

So I would treat this as a Quarto terminal-detection/progress-output bug or feature gap. --quiet is the only in-tree coarse workaround I see if suppressing console output is acceptable:

quarto render /dev/null --to html --quiet

If you file an issue, the minimal repro you posted is good. I would include the detail that adding | cat suppresses it, because that points to Quarto deciding it can use terminal line rewriting in an Emacs compilation buffer.

[cookesan]

Those are cursor-control/line-clear sequences, not color, so NO_COLOR will not affect them. Also, QUARTO_LOG_FORMAT=plain controls Quarto's log file format when using --log; it does not disable console progress/spinner output. Env docs: https://quarto.org/docs/advanced/environment-vars.html

The behavior matches the current source: src/core/console.ts has clearLine() writing ansi.eraseLine.cursorLeft() via the console logger, and several spinner/progress paths call it based on runningInCI() rather than on a stderr TTY check. Source: https://github.com/quarto-dev/quarto-cli/blob/main/src/core/console.ts

So | cat works because it changes the output path, but I agree it is a workaround. If you can suppress console output, --quiet --log quarto.log --log-format plain is the cleanest CLI-side route. If you need normal console messages in Emacs compile, this looks like an upstream bug/feature request: clearLine() should probably no-op when stderr is not a TTY, or Quarto needs an explicit "no terminal control sequences" option.

[jidanni]

Thanks everybody. I worry about --quiet making it too quiet -- the user misses wanted messages. Anyway as this is now over my head perhaps someone else can take the ball and convert it into an enhancement request.

[cderv]

Thanks for the report.

The analysis in this thread is on track. Quarto already gates some interactive features on isInteractiveTerminal() — e.g. prompts in quarto create and the publish commands — but the spinner and progress-bar helpers in src/core/console.ts don't, so cursor-control sequences still reach stderr when it's not a terminal.

I've opened #14419 to track this. We think we can extend the same TTY check we already use for prompts to these console helpers.