Re: Commands like ls(1) does not emits color sequences in 25.0.50.1

[Dmitry Igrishin]

2015-09-08 0:58 GMT+03:00 Random832 <random832@fastmail.com>:

> Dmitry Igrishin <dmitigr@gmail.com> writes:
>
> > To workaround this problem I've tried to add
> > (setenv "TERM" "ansi") to the init.el, but Emacs resets the TERM
> > variable to "dumb" upon the startup. Is this expected?
>
> Yes, it is expected. You can see where it does this in the comint-exec-1
> function. You can test for the EMACS environment variable in your shell
> (it will be set to "t" if running within emacs) and reset the TERM in
> your e.g. bashrc file.


> if [ "$TERM" = dumb ] && [ "$EMACS" = t ]; then
>         TERM=dumb-emacs-ansi
> fi
>
I see. But in Emacs 25.0.50.1 the $EMACS variable is not intialized,
when running shell, but the INSIDE_EMACS is:
$ env | grep EMACS
INSIDE_EMACS=25.0.50.1,comint

Also I've noticed that exporting COLORTERM with value "dumb"
forces ls(1) to emit color sequences in my case. So, I've added the
following
line to .bashrc:
(echo -n $INSIDE_EMACS | grep comint) > /dev/null && export COLORTERM=dumb

Shrug...


> I would tend to use a handcrafted terminfo entry (provided below) that
> has only the color codes (and bold, italic, underline), and nothing
> else, so that full-screen apps don't think they will work. Many
> applications (top and vim both do on my machine) will assume they can
> anyway, though.
>
> dumb-emacs-ansi|Emacs dumb terminal with ANSI color codes,
>         am,
>         colors#8, it#8, ncv#13, pairs#64,
>         bold=\E[1m, cud1=^J, ht=^I, ind=^J, op=\E[39;49m,
>         ritm=\E[23m, rmul=\E[24m, setab=\E[4%p1%dm,
>         setaf=\E[3%p1%dm, sgr0=\E[m, sitm=\E[3m, smul=\E[4m,
>
> Note: 'ncv' is set to disallow reverse, blink, and standout, since these
> are mapped by default to faces that set the foreground color (C-h v
> ansi-color-faces-vector), but also does not provide codes to use them in
> the first place - only color, bold, italic, and underline are provided.
>
> I couldn't find any way to actually indicate the behavior that emacs has
> when given a backspace or carriage return (it actually deletes
> characters, rather than moving backwards to overtype them), so I omitted
> these codes. So, in that sense, this entry is even dumber than dumb.
>
Thank you! These solution can be useful indeed!



-- 
// Dmitry.