RFC: comint.el - comint-highlight-prompt and unreadable colors

RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto]

The color control is turned on by default in 21.3 (which I use in
Windows)

   comint-highlight-prompt

This is causing unreadable terminal output when terminal's background
is dark. Using xterm/rxvt with custom dark backgound setting makes the
Emacs M-x shell buffer quite problematic. Similarly in Windows, the
popular Putty terminal by default uses black background.

There are two possiblilities

1) comint-highlight-prompt is set to nil by default
2) comint-highlight-prompt face is modified. The current "cyan" is
   not optimal. Unofrtunately any color could possibly be unreadable
   in user's selected terminal and background

I don't see variable `comint-highlight-prompt' (1) in latest CVS
comint.el. I think it should be reintroduced, because sometimes colors
are not working correctly and one wants to work in "plain" mode (just
like without font-lock).

The best solution would be not to turn on any colors by default.

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Jari Aalto <jari.aalto@cante.net> writes:
> I don't see variable `comint-highlight-prompt' (1) in latest CVS
> comint.el. I think it should be reintroduced

Comint highlighting now respects font-lock-mode like other modes, so no
special variable should be necessary.

> The best solution would be not to turn on any colors by default.

No.  If you have a wacky environment, it's your problem.

-Miles

-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto]

Miles Bader <miles@gnu.org> writes:

> Jari Aalto <jari.aalto@cante.net> writes:
> 
> > I don't see variable `comint-highlight-prompt' (1) in latest CVS
> > comint.el. I think it should be reintroduced
> 
> Comint highlighting now respects font-lock-mode like other modes, so no
> special variable should be necessary.

Ok.

> > The best solution would be not to turn on any colors by default.
> 
> No.  If you have a wacky environment, it's your problem.

The default color selected is still a problem for completely black
background. Would there be better alternative to currently used "cyan"?
Like using "dark green"?

The current definition reads:

(defface comint-highlight-prompt
  '((((background dark)) (:foreground "cyan"))
    (t (:foreground "dark blue")))
  "Face to use to highlight prompt when `comint-highlight-prompt' is non-nil."
  :group 'comint)


Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Sun, 2007 Mar 25  09:29 UTC
GNU Emacs 22.0.96.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
started with

 /usr/local/src/emacs/src/emacs -i -q -bg black -fg white &
 /usr/local/src/emacs/src/emacs -i -q -bg white -fg black

   The default color selected is still a problem for completely black
   background. Would there be better alternative to currently used
   "cyan"?  Like using "dark green"?

I don't have any trouble with "cyan" on a black (i.e. dark) background.
Also, "dark blue" on a white background works fine.

On the other hand, "dark green" fails me for a dark background.

My normal background is "DodgerBlue4"; "cyan" works fine on it, too.
Perhaps our color renditions are different?

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Jari Aalto <jari.aalto@cante.net> writes:
> The default color selected is still a problem for completely black
> background. Would there be better alternative to currently used "cyan"?

Cyan was carefully chosen for use on a black background, and on all the
displays I have, it looks great -- it's close enough in brightness to
the default text color (white) that while it clearly stands out, it
doesn't stand out "too much" (which would make it distracting).

That is on a display that shows colors directly (X11).

TTY displays are somewhat more tricky.  Unfortunately there is some
variance in the way various terminal emulators render colors (e.g., rxvt
and xterm both use "xterm" as a terminal type, but use different
brightness for some colors).  However as far as I've tested, cyan looks
as good as anything on typical terminal emulators.  There just aren't
many choices on a typical terminal (I tried "green", it is actually less
visible than cyan on my display using gnome-terminal in xterm/rxvt/etc
emulation modes).

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto]

* Mon 2007-03-26 Miles Bader <miles AT gnu.org> INBOX
> Jari Aalto <jari.aalto AT cante.net> writes:
>
>> The default color selected is still a problem for completely black
>> background. Would there be better alternative to currently used "cyan"?
>
> Cyan was carefully chosen for use on a black background, and on all the
> displays I have, it looks great -- it's close enough in brightness to
> the default text color (white) that while it clearly stands out, it
> doesn't stand out "too much" (which would make it distracting).
>
> That is on a display that shows colors directly (X11).
>
> TTY displays are somewhat more tricky.  Unfortunately there is some
> variance in the way various terminal emulators render colors (e.g., rxvt
> and xterm both use "xterm" as a terminal type, but use different
> brightness for some colors).  However as far as I've tested, cyan looks
> as good as anything on typical terminal emulators.  There just aren't
> many choices on a typical terminal (I tried "green", it is actually less
> visible than cyan on my display using gnome-terminal in xterm/rxvt/etc
> emulation modes).

Have a look at these:

1) On Windows, terminal Putty, which is very popular free SSH terminal.

http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--win32-putty.jpg

2) On windows, displaying a rxvt terminal back to the Cygwin X11 server
   from a Unix host using "-bg black -fg snow"

http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--rxvt-cygwin-X11.jpg

What if plain 'bold was used instead of cyan?

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Jari Aalto <jari.aalto@cante.net> writes:
> Have a look at these:
>
> 1) On Windows, terminal Putty, which is very popular free SSH terminal.
>
> http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--win32-putty.jpg
...
> 2) On windows, displaying a rxvt terminal back to the Cygwin X11 server
>    from a Unix host using "-bg black -fg snow"
>
> http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--rxvt-cygwin-X11.jpg

In both cases it looks like Emacs doesn't realize that it's on a
dark-background terminal, and is using light-background mode (which
indeed defaults to a darkish blue for comint prompts).

This is a common problem, because Emacs generally _cannot_ tell the
background color on a terminal, so it has to guess; I don't know about
windows, but on X11 it defaults to assuming dark-background on terminals
unless the TERM environment variable is "xterm".  If TERM = "xterm",
Emacs assumes a light background.

Since rxvt sets TERM to "xterms", that's almost certainly what's
happening in the 2nd case.  On windows, I don't know, but it's probably
a similar problem.

You can override what background mode emacs uses by customizing the
variable `frame-background-mode'.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto+mail.emacs]

* Mon 2007-03-26 Miles Bader <miles.bader AT necel.com> gmane.emacs.devel
* Message-Id: buoircowocf.fsf AT dhapc248.dev.necel.com
> Jari Aalto <jari.aalto AT cante.net> writes:
>
>> Have a look at these:
>>
>> 1) On Windows, terminal Putty, which is very popular free SSH terminal.
>>
>> http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--win32-putty.jpg
> ...
>> 2) On windows, displaying a rxvt terminal back to the Cygwin X11 server
>>    from a Unix host using "-bg black -fg snow"
>>
>> http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--rxvt-cygwin-X11.jpg
>
> In both cases it looks like Emacs doesn't realize that it's on a
> dark-background terminal, and is using light-background mode (which
> indeed defaults to a darkish blue for comint prompts).
>
> This is a common problem, because Emacs generally _cannot_ tell the
> background color on a terminal, so it has to guess; I don't know about
> windows, but on X11 it defaults to assuming dark-background on terminals
> unless the TERM environment variable is "xterm".  If TERM = "xterm",
> Emacs assumes a light background.
>
> Since rxvt sets TERM to "xterms", that's almost certainly what's
> happening in the 2nd case.  On windows, I don't know, but it's probably
> a similar problem.
>
> You can override what background mode emacs uses by customizing the
> variable `frame-background-mode'.

The problem is that many people will hit this. The putty is very
popular on Windows side. 

May I suggest that the default is changed to 'bold instead of cyan.
That would probably be more safer choice now when 22 turns colors on
by default.

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto+mail.emacs]

* Sun 2007-03-25 Robert Chassell <bob AT rattlesnake.com> gmane.emacs.devel
>  /usr/local/src/emacs/src/emacs -i -q -bg black -fg white &
>  /usr/local/src/emacs/src/emacs -i -q -bg white -fg black
>
>    The default color selected is still a problem for completely black
>    background. Would there be better alternative to currently used
>    "cyan"?  Like using "dark green"?
>
> I don't have any trouble with "cyan" on a black (i.e. dark) background.
> Also, "dark blue" on a white background works fine.

I mean these:

  1) Windows: standard Putty
  http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--win32-putty.jpg

  1) windows: rxvt -bg black -fg snow on Cygwin X11 display
  http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--rxvt-cygwin-X11.jpg    
Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Romain Francoise]

Miles Bader <miles.bader@necel.com> writes:

> On windows, I don't know, but it's probably a similar problem.

I don't think it's related to TERM, PuTTY sets it to "xterm".

Actually, the `frame-set-background-mode' function suggests that the
logic is a bit more convoluted...

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Romain Francoise <romain@orebokech.com> writes:
>> On windows, I don't know, but it's probably a similar problem.
>
> I don't think it's related to TERM, PuTTY sets it to "xterm".

Actually that's probably the _reason_ the problem arises:  If TERM =
"xterm", then Emacs assumes a light background (it's a hack, but it was
decided when we discussed this a long time ago that light-background
xterm instances were more common than dark-background instances,
especially for newbies).

> Actually, the `frame-set-background-mode' function suggests that the
> logic is a bit more convoluted...

No doubt.  But it seems pretty likely this is the problem Jari is
seeing, and the solution is obvious:  he should customize
`frame-background-mode' to match his environment.

-Miles

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto+mail.emacs]

* Mon 2007-03-26 Miles Bader <miles.bader AT necel.com> gmane.emacs.devel
* Message-Id: buo4po8we6c.fsf AT dhapc248.dev.necel.com
> Romain Francoise <romain AT orebokech.com> writes:
>
>>> On windows, I don't know, but it's probably a similar problem.
>>
>> I don't think it's related to TERM, PuTTY sets it to "xterm".
>
> Actually that's probably the _reason_ the problem arises:  If TERM =
> "xterm", then Emacs assumes a light background (it's a hack, but it was
> decided when we discussed this a long time ago that light-background
> xterm instances were more common than dark-background instances,
> especially for newbies).
>
>> Actually, the `frame-set-background-mode' function suggests that the
>> logic is a bit more convoluted...
>
> No doubt.  But it seems pretty likely this is the problem Jari is
> seeing, and the solution is obvious:  he should customize
> `frame-background-mode' to match his environment.

Perhaps there is miunderstanding. I have been talking about general
problem, nothing special to my environment. The problem also happens
if user changes the background of rxvt (see previous pictures) at
least under Cygwin X11.

Would not default value 'bold, instead of cyan, work better?

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

jari.aalto@cante.net (Jari Aalto+mail.emacs) writes:
>> No doubt.  But it seems pretty likely this is the problem Jari is
>> seeing, and the solution is obvious:  he should customize
>> `frame-background-mode' to match his environment.
>
> Perhaps there is miunderstanding. I have been talking about general
> problem, nothing special to my environment. The problem also happens
> if user changes the background of rxvt (see previous pictures) at
> least under Cygwin X11.

No, you are confused.  You clearly haven't read my replies very
carefully.

> Would not default value 'bold, instead of cyan, work better?

No.

-miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god.  He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question."  [John McCarthy]

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto+mail.emacs]

* Mon 2007-03-26 Miles Bader <miles.bader AT necel.com> gmane.emacs.devel
* Message-Id: buo3b3sz5et.fsf AT dhapc248.dev.necel.com
> jari.aalto@cante.net (Jari Aalto+mail.emacs) writes:

>> ...general
>> problem, nothing special to my environment. The problem also happens
>> if user changes the background of rxvt (see previous pictures) at
>> least under Cygwin X11.
>
> No, you are confused.  You clearly haven't read my replies very
> carefully.

Was it "... should customize `frame-background-mode' to match his
environment."

Now I'm confused. 

Should this problem be left to every putty (or dark background term)
user? I understood that the the code doesn't get enough information to
decide the correct dark/light environment in presented cases. So it
might guesses wrong, and the results are pretty bad with the select
default color.

>> Would not default value 'bold, instead of cyan, work better?
>
> No.

Do you have in use cases where 'bold would not work?

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

jari.aalto@cante.net (Jari Aalto+mail.emacs) writes:
> Was it "... should customize `frame-background-mode' to match his
> environment."
>
> Should this problem be left to every putty (or dark background term)
> user? I understood that the the code doesn't get enough information to
> decide the correct dark/light environment in presented cases. So it
> might guesses wrong, and the results are pretty bad with the select
> default color.

Basically, unless you have a proper frame-background-mode, then _all_
the highlighting in Emacs will be fairly screwed up:  a large percentage
of the colors used in Emacs highlighting only look good against the
proper background type.  Attempting to pick "neutral" faces for
everything simply doesn't work -- it's hard enough making things look
good if you _can_ depend on the background type -- and the problem is
even worse on ttys with their limited selection of color and alternate
font styles (basically only bold, and often not even that, works).

So even if we changed the comint prompt to make you happy, the entire
rest of the interface will still look awful.

If you can find a way to detect Putty/rxvt then Emacs could use that
information, but absent that, I don't think there's any choice but user
education.

> Do you have in use cases where 'bold would not work?

Bold is already used in comint.  But for the real problem, see above.

-miles

-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 26, 2007 at 09:17:40PM +0900, Miles Bader wrote:

[...]

> If you can find a way to detect Putty/rxvt then Emacs could use that
> information, but absent that, I don't think there's any choice but user
> education.

I kow it's unpopular around here (and with a reason!), but the most user
friendly solution seems to be yet another menu entry in Options (say,
"Color Scheme" with a submenu containing "Dark Background" "Light
Background" and may be others. Post release?

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGB8BVBcgs9XrR2kYRArE/AJ9achp1Yzlsa9cTfwIrizRkXvBYIwCeMOLo
IRP/ze5AXOYWdwqU8WK3jCA=
=DRNX
-----END PGP SIGNATURE-----

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Stefan Monnier]

> I kow it's unpopular around here (and with a reason!), but the most user
> friendly solution seems to be yet another menu entry in Options (say,
> "Color Scheme" with a submenu containing "Dark Background" "Light
> Background" and may be others. Post release?

I occasionally use PuTTY (typically from a "locutorio" when I'm in
Argentina) and always find it relatively difficult to remember/find the
right var to customize.

Problem is: in terminal mode, menus are also more difficult to
use :-( I wish PuTTY used a special TERM setting (or alternatively, I wish
the xterm control-sequences included one which can be used to identify the
terminal in use, and maybe even its background color).  Maybe we should
write&submit a patch to X.org (or whoever is maintaining xterm nowadays) for
that, so that we can use it in Emacs-23.


        Stefan

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Robert J. Chassell]

   Do you have in use cases where 'bold would not work?

Yes.  (The standard bold, `out of the box', will not work.)  The
problem will become more common until absolute units become the norm.
Then the problem vanishes.

When you have a high resolution screen, as I do, but fonts are
provided in pixels rather than in absolute units, and you get older
and need (in an absolute unit) 10 or 12 point fonts to be able to
read, you need to pick a font with a larger than normal number of
pixels ... that is the problem ...

In my case, with the larger font as measured in pixels, shown at a
decent size as measured in absolute units, to increase the weight for
bolding fails.  (Otherwise, the many pixeled font looks proper; I set
my bold to be normal weight and a different color.  All is well.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Jari Aalto+mail.emacs]

* Mon 2007-03-26 Miles Bader <miles.bader AT necel.com> gmane.emacs.devel
>
> Basically, unless you have a proper frame-background-mode, then _all_
> the highlighting in Emacs will be fairly screwed up:  a large percentage
> of the colors used in Emacs highlighting only look good against the
> proper background type.  Attempting to pick "neutral" faces for
> everything simply doesn't work -- it's hard enough making things look
> good if you _can_ depend on the background type -- and the problem is
> even worse on ttys with their limited selection of color and alternate
> font styles (basically only bold, and often not even that, works).
>
> So even if we changed the comint prompt to make you happy, the entire
> rest of the interface will still look awful.

However, the problem is not so noticeable elsewhere. 

> If you can find a way to detect Putty/rxvt then Emacs could use that
> information, but absent that, I don't think there's any choice but user
> education.
>
>> Do you have in use cases where 'bold would not work?
>
> Bold is already used in comint.  But for the real problem, see above.

Forgive, I wanted to ask if there is any cases where 'bold would
pose similar visibility problems.

    (defface comint-highlight-input '((t (:weight bold)))
      "Face to use to highlight user input."
      :group 'comint)

    (defface comint-highlight-prompt
      '((((min-colors 88) (background dark)) (:foreground "cyan1"))
        (((background dark)) (:foreground "cyan"))
        (t (:foreground "dark blue")))
      "Face to use to highlight prompts."
      :group 'comint)

=>

    (defface comint-highlight-input '((t (:weight bold)))
      "Face to use to highlight user input."
      :group 'comint)

    (defface comint-highlight-prompt '((t (:weight bold)))
      "Face to use to highlight prompts."
      :group 'comint)

Wouldn't this work ecorrectly over variaety of terminals? 

The comint (M-x shell) is the primary interface to work fluently with
the shell, so is it's usability is a high prriority problem.

Jari

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > Jari Aalto <jari.aalto@cante.net> writes:
  > > Have a look at these:
  > >
  > > 1) On Windows, terminal Putty, which is very popular free SSH terminal.
  > >
  > > http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--win32-putty.jpg
  > ...
  > > 2) On windows, displaying a rxvt terminal back to the Cygwin X11 server
  > >    from a Unix host using "-bg black -fg snow"
  > >
  > > http://cante.net/~jaalto/tmp/bug/emacs/m-x-shell-color--rxvt-cygwin-X11.jpg
  > 
  > In both cases it looks like Emacs doesn't realize that it's on a
  > dark-background terminal, and is using light-background mode (which
  > indeed defaults to a darkish blue for comint prompts).
  > 
  > This is a common problem, because Emacs generally _cannot_ tell the
  > background color on a terminal, so it has to guess; I don't know about
  > windows, but on X11 it defaults to assuming dark-background on terminals
  > unless the TERM environment variable is "xterm".  If TERM = "xterm",
  > Emacs assumes a light background.
  > 
  > Since rxvt sets TERM to "xterms", that's almost certainly what's
  > happening in the 2nd case.  On windows, I don't know, but it's probably
  > a similar problem.

If the term is rxvt, then it's not a good idea to set TERM to xterms.

With "xterms" no term/*.el terminal initialization file is run!

rxvt sets the variable COLORFGBG to show the default foreground and
background. Based on COLORFGBG that term/rxvt.el can determine the
default background color, and correctly decide if the background is
light or dark.

Unfortunately other terminals do not have such a feature...

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

jari.aalto@cante.net (Jari Aalto+mail.emacs) writes:
>> So even if we changed the comint prompt to make you happy, the entire
>> rest of the interface will still look awful.
>
> However, the problem is not so noticeable elsewhere. 

You're quite wrong there.

-miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere islands
of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Eli Zaretskii]

> From: jari.aalto@cante.net (Jari Aalto+mail.emacs)
> Date: Mon, 26 Mar 2007 09:22:33 +0200
> 
> The problem is that many people will hit this. The putty is very
> popular on Windows side. 

Then please convince the PuTTY maintainer to use a bright background
color by default, since PuTTY sets TERM to xterm, and xterm uses
bright background.

> May I suggest that the default is changed to 'bold instead of cyan.

Please don't waste your time on such suggestions so close to the
release.  The current color schemes in Emacs are an outcome of many
discussions, and manage just barely to be good enough for everybody to
live with them.  It would be madness for us to agree to open that can
of worms again before the release.

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 26 Mar 2007 09:27:03 -0400
> Cc: Miles Bader <miles.bader@necel.com>, emacs-devel@gnu.org
> 
> Problem is: in terminal mode, menus are also more difficult to
> use :-( I wish PuTTY used a special TERM setting

I don't think this is a good idea, since most systems won't know what
to do with such a special TERM value.  (PuTTY already has its own TERM
name, but doesn't use it by default, for the above reason, I guess.)

It is much better if PuTTY would by default use the same colors as
xterm, since that's the default TERM it uses.

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Problem is: in terminal mode, menus are also more difficult to
> use :-( I wish PuTTY used a special TERM setting (or alternatively, I wish
> the xterm control-sequences included one which can be used to identify the
> terminal in use, and maybe even its background color).  Maybe we should
> write&submit a patch to X.org (or whoever is maintaining xterm nowadays) for
> that, so that we can use it in Emacs-23.

Yeah; someone mentioned that rxvt, while it uses TERM=xterms, defines
some extra environment variables.  I just checked, and I see these:

   # black-on-white rxvt (the default)
   TERM="xterms"
   COLORFGBG="0;15"
   COLORTERM="rxvt"

   # white-on-black rxvt (rxvt -fg white -bg black)
   TERM="xterms"
   COLORFGBG="15;0"
   COLORTERM="rxvt"

   # green-on-black rxvt (rxvt -fg green -bg black)
   TERM="xterms"
   COLORFGBG="10;0"
   COLORTERM="rxvt"

Not perfect (it would be better to actually get the terminal's whole
colormap in absolute terms) but that seems enough for emacs to do a
decent job of setting up the background type at least.

So I think Emacs could use the above information if it's present, which
will cover rxvt, and as you say, submit a patch to make xterm define the
same variables.

[An additional variable giving the whole colormap would be even nicer,
e.g.:

   COLORMAP="0:#000000,1:#ff0000,2:#00ff00,..."

Maybe we could try to submit a patch to export that info too...]

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > > Problem is: in terminal mode, menus are also more difficult to
  > > use :-( I wish PuTTY used a special TERM setting (or alternatively, I wish
  > > the xterm control-sequences included one which can be used to identify the
  > > terminal in use, and maybe even its background color).  Maybe we should
  > > write&submit a patch to X.org (or whoever is maintaining xterm nowadays) for
  > > that, so that we can use it in Emacs-23.
  > 
  > Yeah; someone mentioned that rxvt, while it uses TERM=xterms, defines
  > some extra environment variables.  I just checked, and I see these:
  > 
  >    # black-on-white rxvt (the default)
  >    TERM="xterms"
  >    COLORFGBG="0;15"
  >    COLORTERM="rxvt"
  > 
  >    # white-on-black rxvt (rxvt -fg white -bg black)
  >    TERM="xterms"
  >    COLORFGBG="15;0"
  >    COLORTERM="rxvt"
  > 
  >    # green-on-black rxvt (rxvt -fg green -bg black)
  >    TERM="xterms"
  >    COLORFGBG="10;0"
  >    COLORTERM="rxvt"
  > 
  > Not perfect (it would be better to actually get the terminal's whole
  > colormap in absolute terms) but that seems enough for emacs to do a
  > decent job of setting up the background type at least.
  > 
  > So I think Emacs could use the above information if it's present, which
  > will cover rxvt, 

Emacs does use the above information correctly (i.e. it sets the
default background and the colormap) IFF TERM is set to: xterm,
xterm-*, rxvt or rxvt-*.

TERM=xterms is equivalent to not having any terminal initialization
code in lisp/term/*.el

Where does "xterms" come from? Is is a default setting on some
systems, or just a user that thought it would be a good idea to set
TERM to that?

  > and as you say, submit a patch to make xterm define the
  > same variables.

  > [An additional variable giving the whole colormap would be even nicer,
  > e.g.:
  > 
  >    COLORMAP="0:#000000,1:#ff0000,2:#00ff00,..."
  > 
  > Maybe we could try to submit a patch to export that info too...]

Now all the major terminal implementations support 256 colors...
(luckily except rxvt, all implement the xterm color scheme for the
colors 16-256)

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > So I think Emacs could use the above information if it's present, which
>   > will cover rxvt, 
>
> Emacs does use the above information correctly (i.e. it sets the
> default background and the colormap) IFF TERM is set to: xterm,
> xterm-*, rxvt or rxvt-*.
>
> TERM=xterms is equivalent to not having any terminal initialization
> code in lisp/term/*.el

Emacs ought to handle "xterms" too; it's a historical artifact of sorts,
but it used to be very common.

> Where does "xterms" come from? Is is a default setting on some
> systems, or just a user that thought it would be a good idea to set
> TERM to that?

I looked around a bit more, and realized, it's my fault -- it's from my
~/.Xresources file:

    XTerm*termName: xterms

What's really strange is that the real xterm doesn't seem to use that
resource, only rxvt does... so it went unnoticed for ages.

Anyway, I removed that line, and now when I run rxvt, TERM="rxvt", and
Emacs colors are set up properly by default no matter what colors rxvt
is using.

Thanks for the clue that something was funny...

-miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 26, 2007 at 09:27:03AM -0400, Stefan Monnier wrote:
[Me: yet another menu]
[...]
> Problem is: in terminal mode, menus are also more difficult to
> use :-( I wish PuTTY used a special TERM setting [...]

That's true. So the most elegant way around seems to be Miles' env
variables...

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGC9C8Bcgs9XrR2kYRAtT1AJ9Wh0fqcB+ZmgqkXxGbrWR2m5aA5QCfdQIr
aTJbM6RLkoIr1iaSrjb65g8=
=o+ww
-----END PGP SIGNATURE-----

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[Stefan Monnier]

> That's true. So the most elegant way around seems to be Miles' env
> variables...

Are they properly propagated by things like `ssh'?
I'd think a terminal command (i.e. escape sequence) which returns the term's
identification would be even better.


        Stefan

Re: RFC: comint.el - comint-highlight-prompt and unreadable colors

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Mar 29, 2007 at 12:10:35PM -0400, Stefan Monnier wrote:
> > That's true. So the most elegant way around seems to be Miles' env
> > variables...
> 
> Are they properly propagated by things like `ssh'?

Yes and no. The ssh man page mentions a set of variables which are
propagated (things like TZ, MAIL, PATH and some ssh specific stuff), and
then you may pre-set things in .ssh/environment. I don't know whether
Putty mimics this.

But then, all this behaviour can be disabled, server-side.

(Hmpf. Come to think of it, I _know_ my ssh propagates LANG as well,
although it isn't mentioned in the man page. Ah, I see: man page is
wrong. Which vars to send can be configured for the client as well).

> I'd think a terminal command (i.e. escape sequence) which returns the term's
> identification would be even better.

Yes, the ideal would be to be able to query the terminal about its
current settings ("are you dark background?"). But the flexibility of
ssh would allow the users to solve the concrete Putty problem now, I
think.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGDJ0rBcgs9XrR2kYRAq8OAJ0Swh6n4NpAELsM09jgmhN5uuUOsACffkJf
M925eu5HKLeJslnnBeKEOFg=
=KK9Z
-----END PGP SIGNATURE-----