Is hSupportsANSIColor correct in emacs?

[Bodigrim]

https://github.com/UnkindPartition/ansi-terminal/blob/1ca977b137fb513b1990646b01bf45b8ced192a7/src/includes/Common-Include.hs#L247-L252

hSupportsANSIColor was introduced in #75 by @fommil to implement https://github.com/UnkindPartition/tasty/pull/233, but I struggle to find any reference for this incantation.

If I open emacs, go for M-x compile and probe the terminal I get TERM=dumb and INSIDE_EMACS=28.2,compile. But this terminal still does not support colors (after all, it's dumb) as can be checked by, say, running any tasty test suite:

All
  Builder
    Data.ByteString.Builder
      toLazyByteStringWith:                                OK (0.08s)

If I go fo M-x shell then TERM=xterm-color and INSIDE_EMACS=28.2,compile, and this terminal indeed support colors. But this case is already handled by normal hSupportsANSI: https://github.com/UnkindPartition/ansi-terminal/blob/1ca977b137fb513b1990646b01bf45b8ced192a7/src/System/Console/ANSI/Unix.hs#L84-L87

(This is my first time running emacs, so maybe I'm doing something horribly stupid?..)

[sergv]

The gist is that even if you do M-x compile and the terminal is TERM=dumb but there's also INSIDE_EMACS=28.2,compile then Emacs can do something on its side to process escape sequences. The default config you used didn't do anything so you saw the escsapes.

This line in one of the linked PRs https://github.com/haskell/haskell-mode/pull/1608/files#diff-170ec957d1245a41f5cd84e55aa1326f9c7ec2021fbb9a679eba7afc2ca7c3ddR107 gives an example of what Emacs can do here - ansi-color-apply-on-region will colorize escape sequences in the buffer. You may even get some luck by calling this function yourself (M-x eval-expression (ansi-color-apply-on-region (point-min) (point-max))) in the compilation buffer you got.

[Bodigrim]

OK, so it requires either manually call ansi-color-apply-on-region, or have a specific setup for a buffer as haskell-mode does. It is not an internal capability of the terminal to support ANSI color sequences.

I think this is all quite wrong. If haskell-mode knows that it is going to apply ansi-color-apply-on-region to the output, it's its responsibility to change TERM to not-dumb. It's not up to ansi-terminal to return True from hSupportsANSIColor speculatively, in a (false) hope that the output will be passed through ansi-color-apply-on-region, which does not happen by default.

Thus, I suggest deprecating hSupportsANSIColor and/or setting hSupportsANSIColor = hSupportsANSI in the meantime.

[fommil]

haskell-mode is not the only show in town. c.f. https://gitlab.com/tseenshe/haskell-tng.el

Do what you feel is best, but please don't break tools that are working just fine.

[Bodigrim]

haskell-tng does the same: it explicitly runs ans-color-apply-on-region at https://gitlab.com/tseenshe/haskell-tng.el/-/blob/tng/haskell-tng-compile.el#L127. It should have changed TERM to not-dumb as well, to signal programs that they can emit colors.

[Bodigrim]

@andreasabel as an Agda developer, I suspect you are an Emacs user ;) Could you possibly opine?

[andreasabel]

So on macOS with my emacs I get in M-x shell:

bash-3.2$ echo $TERM
dumb
bash-3.2$ echo $INSIDE_EMACS
29.1,comint

This seems to match the isEmacsTerm condition you quote. (And it supports colors.)

[Bodigrim]

@andreasabel my point was that having $INSIDE_EMACS set does not make Emacs terminal natively capable of ANSI escape sequences for colors. One has to execute ansi-color-apply-on-region manually (or have it applied by a plugin), in which case they should not advertise their $TERM as dumb.