unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Commands like ls(1) does not emits color sequences in 25.0.50.1
@ 2015-09-07 18:57 Dmitry Igrishin
  2015-09-07 21:58 ` Random832
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Igrishin @ 2015-09-07 18:57 UTC (permalink / raw)
  To: help-gnu-emacs

Hello,

Recently I've build Emacs 25.0.50.1 and noticed that ls(1)
even with --colors=always option does not emits color sequences.
Setting the environment variable XTERM to "ansi" directly from the inferior
shell affects the behavior of ls(1) in this case and ls --colors
works as expected in *shell* buffer. Is it new expected behavior for
comint shell?

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?

Thanks!

-- 
// Dmitry.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Commands like ls(1) does not emits color sequences in 25.0.50.1
  2015-09-07 18:57 Commands like ls(1) does not emits color sequences in 25.0.50.1 Dmitry Igrishin
@ 2015-09-07 21:58 ` Random832
  2015-09-08  8:18   ` Dmitry Igrishin
  0 siblings, 1 reply; 5+ messages in thread
From: Random832 @ 2015-09-07 21:58 UTC (permalink / raw)
  To: help-gnu-emacs

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 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.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Commands like ls(1) does not emits color sequences in 25.0.50.1
  2015-09-07 21:58 ` Random832
@ 2015-09-08  8:18   ` Dmitry Igrishin
  2015-09-08 12:13     ` Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Igrishin @ 2015-09-08  8:18 UTC (permalink / raw)
  To: Random832; +Cc: help-gnu-emacs

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Commands like ls(1) does not emits color sequences in 25.0.50.1
  2015-09-08  8:18   ` Dmitry Igrishin
@ 2015-09-08 12:13     ` Stefan Monnier
  2015-09-08 13:57       ` Random832
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2015-09-08 12:13 UTC (permalink / raw)
  To: help-gnu-emacs

>> function.  You can test for the EMACS environment variable in your shell

That's been deprecated for ages.  And that won't work in Emacs-25 any more.
You want to use $INSIDE_EMACS instead (whose value is not just "t", either).


        Stefan




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Commands like ls(1) does not emits color sequences in 25.0.50.1
  2015-09-08 12:13     ` Stefan Monnier
@ 2015-09-08 13:57       ` Random832
  0 siblings, 0 replies; 5+ messages in thread
From: Random832 @ 2015-09-08 13:57 UTC (permalink / raw)
  To: help-gnu-emacs

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> >> function.  You can test for the EMACS environment variable in your shell
> 
> That's been deprecated for ages.

I don't know how I would have discovered that - there's no documentation for
this function, which I found by searching for "TERM". There's no
documentation of that fact anywhere inside comint.el.

It's mentioned in the manual at
https://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html
, but that page doesn't come up for any reasonable search on how Emacs sets
TERM.

> And that won't work in Emacs-25 any more.
> You want to use $INSIDE_EMACS instead (whose value is not just "t", either).




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-09-08 13:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-07 18:57 Commands like ls(1) does not emits color sequences in 25.0.50.1 Dmitry Igrishin
2015-09-07 21:58 ` Random832
2015-09-08  8:18   ` Dmitry Igrishin
2015-09-08 12:13     ` Stefan Monnier
2015-09-08 13:57       ` Random832

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).