emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#11785: closed (24.1; term-mode doesn't respect fir


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11785: closed (24.1; term-mode doesn't respect first color change from a process)
Date: Thu, 27 Sep 2012 07:08:01 +0000

Your message dated Thu, 27 Sep 2012 03:07:17 -0400
with message-id <address@hidden>
and subject line Re: bug#11785: 24.1; term-mode doesn't respect first color 
change from a process
has caused the debbugs.gnu.org bug report #11785,
regarding 24.1; term-mode doesn't respect first color change from a process
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11785: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11785
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.1; term-mode doesn't respect first color change from a process Date: Mon, 25 Jun 2012 17:37:18 -0700
A small test file will demonstrate this problem:

$ cat test.sh
#!/usr/bin/env bash
echo -e "\E[31mRed \E[32mGreen"

When running this, I expect to get "Red" in red and "Green" in green.

Running `emacs -Q --eval '(ansi-term "./test.sh")' with Emacs 24 results
in "Red" in black (not red as expected) and "Green" in green. Doing this
with Emacs 23.1 results in the expected behavior ("Red" in red).

In GNU Emacs 24.1.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
 of 2012-06-21 on rhel5-x64.grid.gs.washington.edu
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
Configured using:
 `configure '--without-gif' '--with-x' '--with-x-toolkit=gtk'
 '--prefix=/net/gs/vol3/software/modules-sw/emacs/24.1/Linux/RHEL5/x86_64''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=SCIM
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)



--- End Message ---
--- Begin Message --- Subject: Re: bug#11785: 24.1; term-mode doesn't respect first color change from a process Date: Thu, 27 Sep 2012 03:07:17 -0400 User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
Version: 24.3

Stefan Monnier wrote:

>> Stefan, you have some comments in term.el saying that
>> term-ansi-face-already-done should perhaps be t in more places.
>> Maybe this example shows why it shouldn't be?
>
> I can't remember any of it and don't have time to look into it now,
> so... I'll trust you on that, but in any case, it suggest complementing
> my comment.

I'm afraid I know nothing about what is going on here, I just saw by
experiment that reverting that change fixed the reported issue.
I committed it so it will hopefully get some testing that may reveal
whether or not there are any other consequences.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]