incomplete comment colorization in terminals

incomplete comment colorization in terminals

[Rob Riepel]

When using font-locking in a terminal window (xterm and the like)
single-line comments are only highlighted to the first non-space
character after a space.  This happens in more than one language-
specific mode - I've tried Emacs-lisp and CPerl modes.

The bug does not occur when running Emacs under X, only in a terminal,
and only for certain terminal types.  The bug is present when TERM is
set to xterm or xterm-color, but not when TERM is set to xterm-16color.

This bug is in 22.1 and the pretest version of Emacs, so it is not new.
Emacs 21 does not have this bug.

Here are some screen shots showing the problem:

xterm-color with the bug:

  http://www.stanford.edu/~riepel/emacs/bug/xterm.png

xterm-16color without the bug:

  http://www.stanford.edu/~riepel/emacs/bug/xterm-16color.png

xterm-color with X selection to show exact end of highlights:

  http://www.stanford.edu/~riepel/emacs/bug/xterm-hilited.png

xterm-16color with X selection for completeness:

  http://www.stanford.edu/~riepel/emacs/bug/xterm-16color-hilited.png

If this bug turns out to be in ncurses or term{cap,info} please let me
know so I can submit a bug report to them.



In GNU Emacs 22.1.92.1 (i686-pc-linux-gnu, X toolkit)
 of 2008-03-11 on daedalus
configured using `configure  '--prefix=/usr/yocal''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tpu-edt-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-j C-n r e p o r t - e m TAB RET

Recent messages:
Loading minibuffer-complete-cycle...
Loading byte-opt...done
Loading minibuffer-complete-cycle...done
Loading /home/riepel/.tpu-control...done
For information about GNU Emacs and the GNU system, type <f1> C-a.
(New file)
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
call-interactively: Text is read-only [3 times]

Re: incomplete comment colorization in terminals

[Eli Zaretskii]

> From: Rob Riepel <riepel@networking.stanford.edu>
> Date: Tue, 11 Mar 2008 16:15:14 -0700 (PDT)
> Cc: 
> 
> When using font-locking in a terminal window (xterm and the like)
> single-line comments are only highlighted to the first non-space
> character after a space.  This happens in more than one language-
> specific mode - I've tried Emacs-lisp and CPerl modes.
> 
> The bug does not occur when running Emacs under X, only in a terminal,
> and only for certain terminal types.  The bug is present when TERM is
> set to xterm or xterm-color, but not when TERM is set to xterm-16color.

This is not a bug, but a deliberate feature.  There's a new face named
font-lock-comment-delimiter-face.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Rob Riepel <riepel@networking.stanford.edu> writes:

  > When using font-locking in a terminal window (xterm and the like)
  > single-line comments are only highlighted to the first non-space
  > character after a space.  This happens in more than one language-
  > specific mode - I've tried Emacs-lisp and CPerl modes.
  > 
  > The bug does not occur when running Emacs under X, only in a terminal,
  > and only for certain terminal types.  The bug is present when TERM is
  > set to xterm or xterm-color, but not when TERM is set to xterm-16color.

A good way to avoid this, and the recommended way run emacs in a
terminal emulator, is to set TERM to xterm-256color.  All current
xterm compatible terminal emulators support 256 colors, when using that
your colors will look almost the same in the terminal as the do in X.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Rob Riepel <riepel@networking.stanford.edu>
  > > Date: Tue, 11 Mar 2008 16:15:14 -0700 (PDT)
  > > Cc: 
  > > 
  > > When using font-locking in a terminal window (xterm and the like)
  > > single-line comments are only highlighted to the first non-space
  > > character after a space.  This happens in more than one language-
  > > specific mode - I've tried Emacs-lisp and CPerl modes.
  > > 
  > > The bug does not occur when running Emacs under X, only in a terminal,
  > > and only for certain terminal types.  The bug is present when TERM is
  > > set to xterm or xterm-color, but not when TERM is set to xterm-16color.
  > 
  > This is not a bug, but a deliberate feature.  There's a new face named
  > font-lock-comment-delimiter-face.

This feature was introduced because on the Linux console the comment
face was hard to read (red on black).  But this feature also applies to
the 8 color xterm with a white background, which nobody complained
about! The comment face is quite readable on such a terminal. The face
was changed in that case for no reason.

So can we please switch the 8 color light background case back to
normal? 

Stefan and Yidong, what do you think?

Re: incomplete comment colorization in terminals

[Nick Roberts]

 >   > This is not a bug, but a deliberate feature.  There's a new face named
 >   > font-lock-comment-delimiter-face.
 > 
 > This feature was introduced because on the Linux console the comment
 > face was hard to read (red on black).

That's not my recollection.  Indeed red is very easy to see on black when
there is sufficient brightness.  ISTR that RMS added it to minimise power
consumption on laptops.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: incomplete comment colorization in terminals

[Stefan Monnier]

> When using font-locking in a terminal window (xterm and the like)
> single-line comments are only highlighted to the first non-space
> character after a space.  This happens in more than one language-
> specific mode - I've tried Emacs-lisp and CPerl modes.

Check C-h N.
I know it's long but if you search for "comment" you'll probably find it
fairly quickly.


        Stefan

Re: incomplete comment colorization in terminals

[Stefan Monnier]

>> > This is not a bug, but a deliberate feature.  There's a new face named
>> > font-lock-comment-delimiter-face.
>> 
>> This feature was introduced because on the Linux console the comment
>> face was hard to read (red on black).

> That's not my recollection.  Indeed red is very easy to see on black when
> there is sufficient brightness.  ISTR that RMS added it to minimise power
> consumption on laptops.

Well, it's kind of a jump, but IIRC it's not completely off-the-mark:
Richard complained that the font-lock-comment-face was unreadable on his
screen, and the reason was partly that he kept the brightness of his
screen at minimum to maximize battery autonomy.


        Stefan

Re: incomplete comment colorization in terminals

[Stefan Monnier]

>> When using font-locking in a terminal window (xterm and the like)
>> single-line comments are only highlighted to the first non-space
>> character after a space.  This happens in more than one language-
>> specific mode - I've tried Emacs-lisp and CPerl modes.
>> 
>> The bug does not occur when running Emacs under X, only in a terminal,
>> and only for certain terminal types.  The bug is present when TERM is
>> set to xterm or xterm-color, but not when TERM is set to xterm-16color.

> A good way to avoid this, and the recommended way run emacs in a
> terminal emulator, is to set TERM to xterm-256color.  All current
> xterm compatible terminal emulators support 256 colors, when using that
> your colors will look almost the same in the terminal as the do in X.

The NEWS entry for font-lock-comment-delimiter-face in Emacs-22 is
insufficient I believe.  It should explain the effect of the
introduction of this new face and should point to xterm-256color as well
as other methods to recover the previous behavior.


        Stefan

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > This is not a bug, but a deliberate feature.  There's a new face named
  > >> > font-lock-comment-delimiter-face.
  > >> 
  > >> This feature was introduced because on the Linux console the comment
  > >> face was hard to read (red on black).
  > 
  > > That's not my recollection.  Indeed red is very easy to see on black when
  > > there is sufficient brightness.  ISTR that RMS added it to minimise power
  > > consumption on laptops.
  > 
  > Well, it's kind of a jump, but IIRC it's not completely off-the-mark:
  > Richard complained that the font-lock-comment-face was unreadable on his
  > screen, and the reason was partly that he kept the brightness of his
  > screen at minimum to maximize battery autonomy.

Exactly, but still, the problem was exclusively with a dark background,
there was no complaint whatsoever about the light background case.
There's no reason to have this behavior for the 8 color light background
case.  So, can we please restore it?

Re: incomplete comment colorization in terminals

[Richard Stallman]

     > This feature was introduced because on the Linux console the comment
     > face was hard to read (red on black).

    That's not my recollection.  Indeed red is very easy to see on black when
    there is sufficient brightness.  ISTR that RMS added it to minimise power
    consumption on laptops.

The former is correct -- I found it hard to read comment text in red
against the black background.  I don't think that this was limited only
to when I had the brightness turned down, I think it was always.

In any case, I would not mind if some other change is made for the
white background case.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > In any case, I would not mind if some other change is made for the
  > white background case.

Thanks. I have done that.

We can actually completely get rid of `font-lock-comment-delimiter-face'
if the color for the dark background, 8 colors is changed to "yellow".
"yellow" is very readable on a black background. It will appear as
orange on the Linux console, which is also very readable.

Of the font-lock faces only font-lock-variable-name-face uses
"yellow". The 2 faces tend to appear in different contexts, so there
should not be a big problem in using the same color for both.

What do you think?

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> When using font-locking in a terminal window (xterm and the like)
  > >> single-line comments are only highlighted to the first non-space
  > >> character after a space.  This happens in more than one language-
  > >> specific mode - I've tried Emacs-lisp and CPerl modes.
  > >> 
  > >> The bug does not occur when running Emacs under X, only in a terminal,
  > >> and only for certain terminal types.  The bug is present when TERM is
  > >> set to xterm or xterm-color, but not when TERM is set to xterm-16color.
  > 
  > > A good way to avoid this, and the recommended way run emacs in a
  > > terminal emulator, is to set TERM to xterm-256color.  All current
  > > xterm compatible terminal emulators support 256 colors, when using that
  > > your colors will look almost the same in the terminal as the do in X.
  > 
  > The NEWS entry for font-lock-comment-delimiter-face in Emacs-22 is
  > insufficient I believe.  It should explain the effect of the
  > introduction of this new face and should point to xterm-256color as well
  > as other methods to recover the previous behavior.

Should we add a new entry for emacs-22.2 to correct these issues?
It might be too close to the release, but maybe we could apply the
change for the light background case?

Re: incomplete comment colorization in terminals

[Stefan Monnier]

>> >> When using font-locking in a terminal window (xterm and the like)
>> >> single-line comments are only highlighted to the first non-space
>> >> character after a space.  This happens in more than one language-
>> >> specific mode - I've tried Emacs-lisp and CPerl modes.
>> >> 
>> >> The bug does not occur when running Emacs under X, only in a terminal,
>> >> and only for certain terminal types.  The bug is present when TERM is
>> >> set to xterm or xterm-color, but not when TERM is set to xterm-16color.
>> 
>> > A good way to avoid this, and the recommended way run emacs in a
>> > terminal emulator, is to set TERM to xterm-256color.  All current
>> > xterm compatible terminal emulators support 256 colors, when using that
>> > your colors will look almost the same in the terminal as the do in X.
>> 
>> The NEWS entry for font-lock-comment-delimiter-face in Emacs-22 is
>> insufficient I believe.  It should explain the effect of the
>> introduction of this new face and should point to xterm-256color as well
>> as other methods to recover the previous behavior.

> Should we add a new entry for emacs-22.2 to correct these issues?

Yes, please.

> It might be too close to the release, but maybe we could apply the
> change for the light background case?

If noone objects, it's fine by me.


        Stefan

Re: incomplete comment colorization in terminals

[Glenn Morris]

Stefan Monnier wrote:

>> Should we add a new entry for emacs-22.2 to correct these issues?
>
> Yes, please.

I already did.

>> It might be too close to the release, but maybe we could apply the
>> change for the light background case?
>
> If noone objects, it's fine by me.

I don't mean to be difficult, but I wouldn't. Default font settings
are ridiculously controversial, and I think it's best to just leave
well alone at this stage.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Stefan Monnier wrote:

  > >> It might be too close to the release, but maybe we could apply the
  > >> change for the light background case?
  > >
  > > If noone objects, it's fine by me.
  > 
  > I don't mean to be difficult, but I wouldn't. Default font settings
  > are ridiculously controversial, and I think it's best to just leave
  > well alone at this stage.

This change will reduce controversies, not generate them...

Re: incomplete comment colorization in terminals

[Richard Stallman]

    We can actually completely get rid of `font-lock-comment-delimiter-face'
    if the color for the dark background, 8 colors is changed to "yellow".
    "yellow" is very readable on a black background. It will appear as
    orange on the Linux console, which is also very readable.

I tried that in `font-lock-comment-face', and it is ok, but having the
text in white is clearer and easier to read.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     We can actually completely get rid of `font-lock-comment-delimiter-face'
  >     if the color for the dark background, 8 colors is changed to "yellow".
  >     "yellow" is very readable on a black background. It will appear as
  >     orange on the Linux console, which is also very readable.
  > 
  > I tried that in `font-lock-comment-face', and it is ok, 

In that case, please let's go with that solution, it is the lower
complexity solution, and less surprising for the user.  We have gotten a
few bug reports from users that were confused by this (it is not
immediately intuitive).

Re: incomplete comment colorization in terminals

[Nick Roberts]

Dan Nicolaescu writes:
 > Richard Stallman <rms@gnu.org> writes:
 > 
 >   >     We can actually completely get rid of `font-lock-comment-delimiter-face'
 >   >     if the color for the dark background, 8 colors is changed to "yellow".
 >   >     "yellow" is very readable on a black background. It will appear as
 >   >     orange on the Linux console, which is also very readable.
 >   > 
 >   > I tried that in `font-lock-comment-face', and it is ok, 
 > 
 > In that case, please let's go with that solution, it is the lower
 > complexity solution, and less surprising for the user.  We have gotten a
 > few bug reports from users that were confused by this (it is not
 > immediately intuitive).

I feel that you're using journalistic techniques to steam roller through your
wishes.  Let's look at the full quote:

       I tried that in `font-lock-comment-face', and it is ok, but having the
       text in white is clearer and easier to read.

I think it conveys quite a different impression.

All these stylistic changes that you are making are probably not worth arguing
about but I think you should look for some real agreement that they are an
improvement before making them.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Nick Roberts <nickrob@snap.net.nz> writes:

  > Dan Nicolaescu writes:
  >  > Richard Stallman <rms@gnu.org> writes:
  >  > 
  >  >   >     We can actually completely get rid of `font-lock-comment-delimiter-face'
  >  >   >     if the color for the dark background, 8 colors is changed to "yellow".
  >  >   >     "yellow" is very readable on a black background. It will appear as
  >  >   >     orange on the Linux console, which is also very readable.
  >  >   > 
  >  >   > I tried that in `font-lock-comment-face', and it is ok, 
  >  > 
  >  > In that case, please let's go with that solution, it is the lower
  >  > complexity solution, and less surprising for the user.  We have gotten a
  >  > few bug reports from users that were confused by this (it is not
  >  > immediately intuitive).
  > 
  > I feel that you're using journalistic techniques to steam roller through your
  > wishes.  Let's look at the full quote:
  > 
  >        I tried that in `font-lock-comment-face', and it is ok, but having the
  >        text in white is clearer and easier to read.
  > 
  > I think it conveys quite a different impression.
  > 
  > All these stylistic changes that you are making are probably not worth arguing
  > about but I think you should look for some real agreement that they are an
  > improvement before making them.

Do you have a point here? It's unclear what you are trying to say.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Stefan Monnier wrote:
  > 
  > >> Should we add a new entry for emacs-22.2 to correct these issues?
  > >
  > > Yes, please.
  > 
  > I already did.

Wouldn't it be better if the new text you added be in the 22.2 section?
It's not very likely that 22.1 users would read pass the 22.2 section.
Just add a note that this has been present in 22.1 too.

Re: incomplete comment colorization in terminals

[Stefan Monnier]

>> >> Should we add a new entry for emacs-22.2 to correct these issues?
>> >
>> > Yes, please.
>> 
>> I already did.

> Wouldn't it be better if the new text you added be in the 22.2 section?
> It's not very likely that 22.1 users would read pass the 22.2 section.
> Just add a note that this has been present in 22.1 too.

Exactly,


        Stefan

Re: incomplete comment colorization in terminals

[Rob Riepel]

On Mar 11, 2008, at 9:26 PM, Eli Zaretskii wrote:

>> From: Rob Riepel <riepel@networking.stanford.edu>
>> Date: Tue, 11 Mar 2008 16:15:14 -0700 (PDT)
>>
>> When using font-locking in a terminal window (xterm and the like)  
>> single-line comments are only highlighted to the first non-space  
>> character after a space.  This happens in more than one language- 
>> specific mode - I've tried Emacs-lisp and CPerl modes.
>>
>> The bug does not occur when running Emacs under X, only in a  
>> terminal, and only for certain terminal types.  The bug is present  
>> when TERM is
>> set to xterm or xterm-color, but not when TERM is set to  
>> xterm-16color.
>
> This is not a bug, but a deliberate feature.  There's a new face  
> named font-lock-comment-delimiter-face.


And On Mar 11, 2008, at 9:45 PM, Dan Nicolaescu wrote:

> A good way to avoid this, and the recommended way run emacs in a  
> terminal emulator, is to set TERM to xterm-256color.  All current  
> xterm compatible terminal emulators support 256 colors, when using  
> that your colors will look almost the same in the terminal as the  
> do in X.


Thank you, Eli and Dan, for educating me.  I thought I had read NEWS,  
but apparently not.  :-(

Many of the debian systems I work on lack the ncurses-term package,  
so I often cannot set TERM to xterm-256color or even xterm-16color.   
So even though the terminals I use support 16 or more colors I'm  
often limited to xterm-color (from the debian ncurses-base package).   
So I've resorted to this:

   (and
    (boundp 'font-lock-comment-delimiter-face)
    (set-face-attribute 'font-lock-comment-face t :inherit
                        font-lock-comment-delimiter-face))

I really like the color schemes that come with 16+ color support, but  
there's no "mode" value for --color=mode that sets anything above 8.   
Is there a way to set the number of colors that can be displayed  
in .emacs?

--
Rob Riepel
(650) 725-7577
http://geek.stanford.edu

Re: incomplete comment colorization in terminals

[Rob Riepel]

On Mar 12, 2008, at 6:57 AM, Stefan Monnier wrote:

> The NEWS entry for f in Emacs-22 is insufficient I believe.  It  
> should explain the effect of the introduction of this new face and  
> should point to xterm-256color as well as other methods to recover  
> the previous behavior.

The new entry looks great.  You may want to mention font-lock-comment- 
delimiter-face in the font-lock-mode documentation.  Right now it says:

| When Font Lock mode is enabled, text is fontified as you type it:
|
|  - Comments are displayed in `font-lock-comment-face';
|  - Strings are displayed in `font-lock-string-face';

Which could be slightly confusing to those who don't know that the  
delimiter is not part of the comment (at least as far as  
fontification is concerned).

--
Rob Riepel
(650) 725-7577
http://geek.stanford.edu

Re: incomplete comment colorization in terminals

[Nick Roberts]

 >   >  >   > I tried that in `font-lock-comment-face', and it is ok, 
 >   >  > 
 >   >  > In that case, please let's go with that solution, it is the lower
 >   >  > complexity solution, and less surprising for the user.  We have
 >   >  > gotten a few bug reports from users that were confused by this (it is
 >   >  > not immediately intuitive).
 >   > 
 >   > I feel that you're using journalistic techniques to steam roller through
 >   > your wishes.  Let's look at the full quote:
 >   > 
 >   >        I tried that in `font-lock-comment-face', and it is ok, but
 >   >        having the text in white is clearer and easier to read.
 >   > 
 >   > I think it conveys quite a different impression.
 >   > 
 >   > All these stylistic changes that you are making are probably not worth
 >   > arguing about but I think you should look for some real agreement that
 >   > they are an improvement before making them.
 > 
 > Do you have a point here? It's unclear what you are trying to say.

I just think that you are only listening to the parts that you want to
hear.  Maybe that's why my message is unclear to you.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Nick Roberts <nickrob@snap.net.nz> writes:

  >  >   >  >   > I tried that in `font-lock-comment-face', and it is ok, 
  >  >   >  > 
  >  >   >  > In that case, please let's go with that solution, it is the lower
  >  >   >  > complexity solution, and less surprising for the user.  We have
  >  >   >  > gotten a few bug reports from users that were confused by this (it is
  >  >   >  > not immediately intuitive).
  >  >   > 
  >  >   > I feel that you're using journalistic techniques to steam roller through
  >  >   > your wishes.  Let's look at the full quote:
  >  >   > 
  >  >   >        I tried that in `font-lock-comment-face', and it is ok, but
  >  >   >        having the text in white is clearer and easier to read.
  >  >   > 
  >  >   > I think it conveys quite a different impression.
  >  >   > 
  >  >   > All these stylistic changes that you are making are probably not worth
  >  >   > arguing about but I think you should look for some real agreement that
  >  >   > they are an improvement before making them.
  >  > 
  >  > Do you have a point here? It's unclear what you are trying to say.
  > 
  > I just think that you are only listening to the parts that you want to
  > hear.  Maybe that's why my message is unclear to you.

OK, I wanted to make sure that you were not trying to make a technical
point, just to attack.

Your behavior is out of line, please keep it off the list and out of my
mailbox too.

Yes, it is customary not quote too much when replying to a message.  In
this case the issue is not that complicated to not remember the whole
context, and don't worry RMS understands perfectly what it is.  And I
hope he gets what I am trying to say too.  We were just having a
technical discussion, as we've have many in the past.
Not sure what exactly you are trying to obtain here, but doing it this
way is not the best.

Re: incomplete comment colorization in terminals

[Eli Zaretskii]

> Cc: emacs-pretest-bug@gnu.org
> From: Rob Riepel <riepel@networking.stanford.edu>
> Date: Fri, 14 Mar 2008 17:49:59 -0700
> 
> I really like the color schemes that come with 16+ color support, but  
> there's no "mode" value for --color=mode that sets anything above 8.   
> Is there a way to set the number of colors that can be displayed  
> in .emacs?

I'm guessing that you are reading the output of "emacs --help", which
is necessarily terse and doesn't tell the whole story.  In the Emacs
manual, by contrast, you will find this text:

    `--color=MODE'
	 For a character terminal only, specify the mode of color support.
	 This option is intended for overriding the number of supported
	 colors that the character terminal advertises in its `termcap' or
	 `terminfo' database.  The parameter MODE can be one of the
	 following:

	 ...

	`NUM'
	      Use color mode for NUM colors.  If NUM is -1, turn off color
	      support (equivalent to `never'); if it is 0, use the default
	      color support for this terminal (equivalent to `auto');
	      otherwise use an appropriate standard mode for NUM colors.
	      Depending on your terminal's capabilities, Emacs might be
	      able to turn on a color mode for 8, 16, 88, or 256 as the
	      value of NUM.  If there is no mode that supports NUM colors,
	      Emacs acts as if NUM were 0, i.e. it uses the terminal's
	      default color support mode.
	      If MODE is omitted, it defaults to ANSI8.

Thus, --color=16 should do what you want, if the terminal can support
16-color mode.

Re: incomplete comment colorization in terminals

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> >> When using font-locking in a terminal window (xterm and the like)
  > >> >> single-line comments are only highlighted to the first non-space
  > >> >> character after a space.  This happens in more than one language-
  > >> >> specific mode - I've tried Emacs-lisp and CPerl modes.
  > >> >> 
  > >> >> The bug does not occur when running Emacs under X, only in a terminal,
  > >> >> and only for certain terminal types.  The bug is present when TERM is
  > >> >> set to xterm or xterm-color, but not when TERM is set to xterm-16color.
  > >> 
  > >> > A good way to avoid this, and the recommended way run emacs in a
  > >> > terminal emulator, is to set TERM to xterm-256color.  All current
  > >> > xterm compatible terminal emulators support 256 colors, when using that
  > >> > your colors will look almost the same in the terminal as the do in X.
  > >> 
  > >> The NEWS entry for font-lock-comment-delimiter-face in Emacs-22 is
  > >> insufficient I believe.  It should explain the effect of the
  > >> introduction of this new face and should point to xterm-256color as well
  > >> as other methods to recover the previous behavior.
  > 
  > > Should we add a new entry for emacs-22.2 to correct these issues?
  > 
  > Yes, please.
  > 
  > > It might be too close to the release, but maybe we could apply the
  > > change for the light background case?
  > 
  > If noone objects, it's fine by me.

Yidong also approved the change, so I checked it in 22.2.