Usefulness of TERM=dumb-emacs-ansi?

Howdy, happy user of M-x shell & C-x p s.

Recently found out that some programs (IIUC, those heeding terminfo)
recognize TERM=3Ddumb-emacs-ansi as "somewhat competent", e.g. enough to
process SGR sequences.

So setting comint-terminfo-terminal to "dumb-emacs-ansi" makes
e.g. 'grep --color=3Dauto' emit colored output.  Yay?  I've hit a couple
of snags that made me wonder if I want to stick with this or not.

  * Snag the first: some programs think that TERM=3Ddumb-emacs-ansi mean
  "run pagers like less".  So e.g. journalctl or Python's help() start
  invoking these pagers; OT1H M-x shell can drive them, OTOH I'd rather
  not page in an Emacs shell.

  Not to worry, comint-pager's docstring calls this problem out, and
  suggests setting that variable to "cat".  Moving on.

  * Snag the second: I often invoke 'bash' while already in a bash
  shell, to mess with variables like PATH while keeping a simple way to
  revert the changes - exit out of the nested shell.

  tl;dr (full recipe below=C2=B9) in nested shells with TERM=3Ddumb-emacs-a=
nsi,
  *something* emits a "bracketed paste off ; CRLF ; bracketed paste on"
  sequence that comint.el reduces to a spurious newline whenever I send
  a command in the nested shell.

  I'm not sure what that *something* is=C2=B2; empirically if I add
  (something equivalent to)

    [[ $TERM =3D dumb* ]] && bind 'set enable-bracketed-paste off'

  =E2=80=A6 to my .bashrc, then I no longer see extra newlines between every
  command.  (But then, infuriatingly, bash complains that "line editing
  is not enabled", despite that 'bind' command manifestely "working"?)

OT1H both of these snags sound like interesting rabbit holes to keep
burrowing through; maybe there's interesting bugs to report & patches to
send to bash or terminfo upstreams.  OTOH wondering if the experiment
has run its course, and TERM=3Ddumb-emacs-ansi is more trouble than it is
worth.  E.g.

* some programs do not even care about TERM, e.g. ip(8) merely checks
that stdout is a terminal (so emits color even with TERM=3Ddumb),
* why even spend so much time in M-x shell,
  * might as well use Emacs-native commands over their shell equivalent
  anyway (though some of them block the UI),
  * might as well learn other Emacs shell frontends (M-x term, Eshell,
  Eat?).

I'm 90% happy with M-x shell though, so keen on hearing WY'allT about
this specific setting.


=C2=B9 Step to repro & edebug the empty line, setting HOME to an empty dir =
to
hopefully factor out config jank:

$ HOME=3D$(mktemp -d) emacs -eval '(setopt comint-terminfo-terminal "dumb-e=
macs-ansi" comint-pager "cat")'
M-x shell
  $ :       # No empty line between prompts.
  $ bash
  $ :       # Empty line now:

  $=20
M-x find-function comint-output-filter
C-u C-M-x   ; Edebug it.
C-x b *shell*
  $ :       # Stopped in comint-output-filter:
e string    ; "\e[?2004l\r\n\e[?2004hpeniblec@hirondell:/home/peniblec$ "
            ; (\escaping mine; ESC & CR actually printed verbatim)

=C2=B2 Going to guess "the first-level bash, which is the process that Emacs
is still sending input to".  FTR, I need all three of these conditions
to reproduce:

1. TERM=3Ddumb-emacs-ansi: no problems with plain 'dumb'.
2. 'M-x shell': no problems with e.g. Konsole.
3. a nested shell: no symptoms until I start the second 'bash'.

FWIW: this is all on Debian 13, bash 5.2.37, GNU Emacs 32.0 (0f086c307).