font-lock-comment-delimiter-face

font-lock-comment-delimiter-face

[Richard Stallman]

I introduced a new face, font-lock-comment-delimiter-face,
to make it possible to customize separately the fontification 
of comment delimiters and comment text.  I also set up Rmail
and Sendmail modes to use this.  However, lots of other modes
ought to be set up to use it.

Can people please go to work on those modes?

Re: font-lock-comment-delimiter-face

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 23 Apr 2005 18:51:38 -0400
> 
> I introduced a new face, font-lock-comment-delimiter-face,
> to make it possible to customize separately the fontification 
> of comment delimiters and comment text.  I also set up Rmail
> and Sendmail modes to use this.

Thanks.

However, there's a problem similar to what I've seen with yesterday's
CVS and reported earlier today: multilevel citations are not fontified
correctly.  For example, in this fragment:

>> The function that _clearly_ should trigger/use the recorded
>> information, however, is "require".

the first of the two `>' characters is not fontified.  I think it
should be.

Re: font-lock-comment-delimiter-face

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I introduced a new face, font-lock-comment-delimiter-face,
> to make it possible to customize separately the fontification 
> of comment delimiters and comment text.  I also set up Rmail
> and Sendmail modes to use this.  However, lots of other modes
> ought to be set up to use it.

Feature freeze ?

> Can people please go to work on those modes?

Can people please work on completing the release...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Feature freeze (was Re: font-lock-comment-delimiter-face)

[Glenn Morris]

Kim F. Storm wrote:

> Feature freeze ?
[...]
> Can people please work on completing the release...

This prompts me to ask, when were the details of a feature freeze
agreed upon? I'm not trying to be provocative, but rather to suggest
that one reason for the continued delay is (IMO), lack of a clear
policy.

I'm aware of Kim's mail from 08 April last year ("It is time for a
feature freeze (it is NOW or never)",
<http://lists.gnu.org/archive/html/emacs-devel/2004-04/msg00176.html>),
which was clearly very prescient in its negative predictions (sadly).

This was a "we *should* do this" kind of email. But where was the
official announcement, "it's been decided, we *will* do this"? In
other words, a widely publicized announcement saying, eg: As of date X
there will be a feature freeze. After this date, do not do A, B, C.
Instead, concentrate on D, E, F.

If I missed it, I apologize, but a quick search of the archives didn't
find it. Maybe there is some implicit convention inherited from
previous occasions, but I think Emacs has acquired many new CVS
contributors (such as myself) since the last release, and hopefully
will continue to do so in future, so explicitness would be good, I
feel.


Also, shouldn't there also be a new branch for the release?
admin/notes/BRANCH says:

    This is the "HEAD" branch, otherwise known as the "trunk"
    ...
    The closure process for this branch is undocumented; concepts such
    as "freeze", "release", or "integration with the trunk" are not
    applicable to this branch.


This is all water under the bridge really, and I don't want to cause
more wasteful discussion, so by all means ignore this message. I'm just
saying:

1) with hindsight (or with foresight for the next time round), a clear
   statement of release policy would seem essential. Maybe it would
   even help now to make a such a statement.

2) should there be a new CVS branch for the release?

Re: Feature freeze (was Re: font-lock-comment-delimiter-face)

[Thien-Thi Nguyen]

   From: Glenn Morris <gmorris+emacs@ast.cam.ac.uk>
   Date: Sun, 24 Apr 2005 21:27:47 +0100

   2) should there be a new CVS branch for the release?

that depends on the precise release methodology, which hasn't been
captured under admin/ or admin/notes/, as far as i can tell.  perhaps
that action (and even the term "capture") goes against the hacker way,
even though it is accepted in other organizational structures...

at this time there is a frustration from people who have a backlog of
changes they would like to commit, but have refrained from doing so,
especially when they see the continuing drizzle of commits done by
others.

perhaps the well-restrained can help the drizzlers to taper off by
showing how they keep their backlog maintained (but ready for commit
once the next release is made), while working on the items in the file
FOR-RELEASE.  the idea is not to stem the hacking, but to buffer it in
such a way that rms' release-threshold criteria can be met, even though
we don't know the criteria fully.

thi

Re: Feature freeze (was Re: font-lock-comment-delimiter-face)

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@glug.org>
> Date: Sun, 24 Apr 2005 17:46:40 -0400
> Cc: emacs-devel@gnu.org
> 
>    From: Glenn Morris <gmorris+emacs@ast.cam.ac.uk>
>    Date: Sun, 24 Apr 2005 21:27:47 +0100
> 
>    2) should there be a new CVS branch for the release?
> 
> that depends on the precise release methodology, which hasn't been
> captured under admin/ or admin/notes/, as far as i can tell.

FWIW, previous practice was to cut the branch after the pretest was
over, i.e. immediately before releasing a new version.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    > I introduced a new face, font-lock-comment-delimiter-face,
    > to make it possible to customize separately the fontification 
    > of comment delimiters and comment text.  I also set up Rmail
    > and Sendmail modes to use this.  However, lots of other modes
    > ought to be set up to use it.

    Feature freeze ?

I installed this because it seems to be the only good way to resolve
the problem that was encountered with fontification and Rmail to
general satisfaction.  (No one objected to this solution.)  I agree it
is an unpleasantly large change, but what else should we do?

I would be glad to see a simpler solution that does the job.

Re: font-lock-comment-delimiter-face

[Luc Teirlinck]

Richard Stallman wrote:

   I installed this because it seems to be the only good way to resolve
   the problem that was encountered with fontification and Rmail to
   general satisfaction.  (No one objected to this solution.)

If nothing else. the defface docstring seems wrong:

  "Font Lock mode face used to highlight comments."

The defvar docstring (which does not appear in the Custom buffer)
more accurately says:

  "Face name to use for comment delimiters."

The best solution would seem to go for a mail specific face.
Alternatively, one could write in the defvar and defface docstrings:

  "Font Lock mode face used to highlight comment delimiters.
This is currently only used in a limited number of modes such as
rmail-mode and mail-mode.  In other modes, comment delimiters get
fontified using `font-lock-comment-face'."

Sincerely,

Luc.

Re: Feature freeze (was Re: font-lock-comment-delimiter-face)

[Richard Stallman]

We should not make a new branch now.  Just now we should focus on the
release itself.

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

> I introduced a new face, font-lock-comment-delimiter-face,
> to make it possible to customize separately the fontification
> of comment delimiters and comment text.  I also set up Rmail
> and Sendmail modes to use this.

Seems odd to introduce a new face whose name refers to "comment" even though
the only two known uses for it are not for comments but for email citations.

> However, lots of other modes ought to be set up to use it.
> Can people please go to work on those modes?

It could be directly added in a generic way to
font-lock-fontify-syntactically-region.  But really, I haven't seen much of
a need for such fine-grained font-locking of comment delimiters.

I'm surprised you opted for such a disruptive "solution" to your problem,
when a much simpler one was proposed.  I.e. I'd have much preferred the
introduction of a new mail-citation-face (message has one already called
message-cited-text-face), which could by defaut just inherit from
font-lock-comment-face but which you could change to be more legible for
your specific needs.  You wouldn't get the specific look you currently
have, but it might be good enough, and if not, you can always get your
particular look using font-lock-add-keywords.


        Stefan

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    Seems odd to introduce a new face whose name refers to "comment" even though
    the only two known uses for it are not for comments but for email citations.

Those were the only uses yet implemented for it,
but now I've changed font-lock-fontify-syntactically-region
to use it for comment delimiters.  I think this will work
for all modes.  It works for C mode and Lisp mode.

It would be cleaner, in some ways, to use font-lock-comment-face for
the delimiters and use font-lock-comment-text-face for the comment
contents.  The improvement is that this would not involve any change
in what font-lock-comment-face looks like.  It would just involve
adding font-lock-comment-text-face and using it.

However, the method that works in font-lock-fontify-syntactically-region
for font-lock-comment-delimiter-face does not work when adapted to
font-lock-comment-text-face.  I can't figure out why,
but it seems to relate to jit-lock.

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

>     Seems odd to introduce a new face whose name refers to "comment" even
>     though the only two known uses for it are not for comments but for
>     email citations.

> Those were the only uses yet implemented for it,
> but now I've changed font-lock-fontify-syntactically-region
> to use it for comment delimiters.  I think this will work
> for all modes.  It works for C mode and Lisp mode.

For C++ mode, it doesn't quite work:

   foo // comment1
   bar /* comment2 */

The // and /* are put in font-lock-comment-delimiter-face (which I find to
be useless clutter and makes the text less legible without helping
understand the structure), but the */ is left with just
font-lock-comment-face.

In SML mode I see another problem:

   (* comment 1 start
      (* nested comment *)
      comment 1 end *)

The first (* is in f-l-c-d-f, the second isn't.  That's correct.
OTOH depending on how the text is refontified, not only the second *)
but sometimes also the first *) gets the new f-l-c-d-f.

> It would be cleaner, in some ways, to use font-lock-comment-face for
> the delimiters and use font-lock-comment-text-face for the comment
> contents.  The improvement is that this would not involve any change
> in what font-lock-comment-face looks like.  It would just involve
> adding font-lock-comment-text-face and using it.

I don't understand the above.  In what way does the current code change what
font-lock-comment-face looks like?

> However, the method that works in font-lock-fontify-syntactically-region
> for font-lock-comment-delimiter-face does not work when adapted to
> font-lock-comment-text-face.  I can't figure out why,
> but it seems to relate to jit-lock.

Here also, I seem to be missing something.


        Stefan "who dislikes this new gaudier font-locking, again for the
                same reason that it is lexical rather than syntactic
                highlighting"

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    For C++ mode, it doesn't quite work:

       foo // comment1
       bar /* comment2 */

    The // and /* are put in font-lock-comment-delimiter-face (which I find to
    be useless clutter and makes the text less legible without helping
    understand the structure), but the */ is left with just
    font-lock-comment-face.

That is because comment-end is empty in C++ mode.

I see there is a variable comment-end-skip, whose doc string suggests
it ought to be useful for this (but the doc string is not entirely
clear tome).  But it doesn't seem to be set up in C++ mode.  Should it
be?

    In SML mode I see another problem:

       (* comment 1 start
	  (* nested comment *)
	  comment 1 end *)

    The first (* is in f-l-c-d-f, the second isn't.  That's correct.
    OTOH depending on how the text is refontified, not only the second *)
    but sometimes also the first *) gets the new f-l-c-d-f.

I don't see how to handle nested comments easily.

    I don't understand the above.  In what way does the current code change what
    font-lock-comment-face looks like?

When I added font-lock-comment-delimiter-face, I copied the
definition of font-lock-comment-face into it, then changed
the definition o font-lock-comment-face.

It would be cleaner to leave font-lock-comment-face unchanged and
define font-lock-comment-text-face with the modified value.
However, I couldn't make that work.  Adapting the code in
font-lock-fontify-syntactically-region in a straightforward
way resulted in incorrect results, and I don't know why.

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

>     For C++ mode, it doesn't quite work:
>        foo // comment1
>        bar /* comment2 */

>     The // and /* are put in font-lock-comment-delimiter-face (which I find to
>     be useless clutter and makes the text less legible without helping
>     understand the structure), but the */ is left with just
>     font-lock-comment-face.

> That is because comment-end is empty in C++ mode.

> I see there is a variable comment-end-skip, whose doc string suggests
> it ought to be useful for this (but the doc string is not entirely
> clear tome).  But it doesn't seem to be set up in C++ mode.  Should it
> be?

Major modes should set comment-end-skip, like they set comment-start-skip,
but since this variable was new in Emacs-21.1 I had to handle the backward
compatible case where a major mode does not set comment-end-skip, so
comment-end-skip is set to an "educated guess" value (based on comment-end
and "\\s>") if not set already.  This defaulting is done by
comment-normalize-vars which is called at the beginning of all major
comment function.

>     I don't understand the above.  In what way does the current code
>     change what font-lock-comment-face looks like?

> When I added font-lock-comment-delimiter-face, I copied the
> definition of font-lock-comment-face into it, then changed
> the definition o font-lock-comment-face.

> It would be cleaner to leave font-lock-comment-face unchanged and
> define font-lock-comment-text-face with the modified value.
> However, I couldn't make that work.  Adapting the code in
> font-lock-fontify-syntactically-region in a straightforward
> way resulted in incorrect results, and I don't know why.

Without seeing the "straightforward way" code, it's hard to tell.


        Stefan

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

>     Seems odd to introduce a new face whose name refers to "comment" even
>     though the only two known uses for it are not for comments but for
>     email citations.

> Those were the only uses yet implemented for it,
> but now I've changed font-lock-fontify-syntactically-region
> to use it for comment delimiters.  I think this will work
> for all modes.  It works for C mode and Lisp mode.

Taking a second look at the idea I can't help feeling like it's the wrong
solution.  Basically, nobody has ever requested for comment-delimiters to be
hilighted differently than the comment body, so we're adding a feature that
nobody asked for (and this, one-year into a feature freeze).

Problem is that this feature doesn't work quite right: the border cases are
non-trivial and nobody has the expertise/time/willingness to fix it.

But the oddest part of all is that this was introduced because of something
completely unrelated: the ability to mark mail quoting-prefix without
marking the quoted text.  And this, of course, has nothing to do with
comments, other than an accidental reuse of font-lock-comment-face.

Please, let's rename this new face to something sensible like
mail-citation-prefix-face (or the same without the "-face" suffix) and stop
the madness about comment delimiters.


        Stefan

Re: font-lock-comment-delimiter-face

[Kim F. Storm]

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

> Please, let's rename this new face to something sensible like
> mail-citation-prefix-face (or the same without the "-face" suffix) and stop
> the madness about comment delimiters.

FWIW, I agree 100%.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: font-lock-comment-delimiter-face

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 13 May 2005 10:21:35 +0200
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Please, let's rename this new face to something sensible like
> > mail-citation-prefix-face (or the same without the "-face" suffix) and stop
> > the madness about comment delimiters.
> 
> FWIW, I agree 100%.

FWIW, me too.

Re: font-lock-comment-delimiter-face

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: storm@cua.dk (Kim F. Storm)
>> Date: Fri, 13 May 2005 10:21:35 +0200
>> Cc: rms@gnu.org, emacs-devel@gnu.org
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> > Please, let's rename this new face to something sensible like
>> > mail-citation-prefix-face (or the same without the "-face"
>> > suffix) and stop the madness about comment delimiters.
>> 
>> FWIW, I agree 100%.
>
> FWIW, me too.

AOL

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: font-lock-comment-delimiter-face

[Edward O'Connor]

>>>> Please, let's rename this new face to something sensible like
>>>> mail-citation-prefix-face (or the same without the "-face" suffix)
>>>> and stop the madness about comment delimiters.
>>>
>>> FWIW, I agree 100%.
>>
>> FWIW, me too.
>
> AOL

FWIW[0], I completely, entirely, and totally agree.


Ted

0. Since I'm not an Emacs developer, I imagine this doesn't count as
   much as, say, Eli's opinion.

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: font-lock-comment-delimiter-face

[Daniel Brockman]

>>>>> Please, let's rename this new face to something sensible like
>>>>> mail-citation-prefix-face (or the same without the "-face"
>>>>> suffix) and stop the madness about comment delimiters.
>>>>
>>>> FWIW, I agree 100%.
>>>
>>> FWIW, me too.
>>
>> AOL
>
> FWIW[0], I completely, entirely, and totally agree.

I think comments look better when the delimiters appear in a slightly
more washed-out color.  Having the delimiters and text in completely
different colors is just distracting, but I find a slight difference
in color actually helps me focus on the text.

It's not a big deal, but I just wanted to mention that while the
current implementation may be lacking, I don't think there's anything
wrong with the idea.  (Though as Richard has been saying, it would be
cleaner to instead add `font-lock-comment-text-face'.)

I don't think the feature is trivial, and it is currently very rough.
For example, it would be nice to have comments such as the following
be fontified in the expected way:

/*
 * foobarbaz.c --- do that stuff with the thing
 *
 * This file is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published
 * by the Free Software Foundation; either version 2 of the License,
 * or (at your option) any later version.
 *
 * [...]
 */

I understand the people who think that the best thing to do for now is
to rename the face to refer to mail specifically and ``stop the
madness about comment delimiters,'' as Stefan put it.  This feature
can wait until after the release.

-- 
Daniel Brockman <daniel@brockman.se>

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    Taking a second look at the idea I can't help feeling like it's the wrong
    solution.  Basically, nobody has ever requested for comment-delimiters to be
    hilighted differently than the comment body, so we're adding a feature that
    nobody asked for (and this, one-year into a feature freeze).

I want this, and I want it badly.  It is hard to read comments in red
on a tty.  However, highlighting the comment delimiters in red on a
tty is fine.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

      This defaulting is done by
    comment-normalize-vars which is called at the beginning of all major
    comment function.

That means it isn't (at present) set up for font-lock mode to use.

Re: font-lock-comment-delimiter-face

[Nick Roberts]

 > I want this, and I want it badly.  It is hard to read comments in red
 > on a tty.  However, highlighting the comment delimiters in red on a
 > tty is fine.

I have had this problem before, with an old monitor. It can also be solved
by turning up the brightness or buying a new monitor.

Nick

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    I have had this problem before, with an old monitor. It can also be solved
    by turning up the brightness or buying a new monitor.

I have to turn the brightness down to make the battery last.

Re: font-lock-comment-delimiter-face

[Ralf Angeli]

* Richard Stallman (2005-05-11) writes:

> Those were the only uses yet implemented for it,
> but now I've changed font-lock-fontify-syntactically-region
> to use it for comment delimiters.  I think this will work
> for all modes.  It works for C mode and Lisp mode.

In Lisp mode it fails to apply `font-lock-comment-delimiter-face' to a
single ";" as long as it is not located at the start of a line.  The
cause is probably that `comment-start-skip' in Lisp mode contains
precautions for not matching escaped semicolons:

  (setq comment-start-skip "\\(\\(^\\|[^\\\\\n]\\)\\(\\\\\\\\\\)*\\);+ *")

It appears strange to me that `(looking-at comment-start-skip)' with
this regexp returns t in case of multiple semicolons but nil in case
of a single one.

-- 
Ralf

Re: font-lock-comment-delimiter-face

[Nick Roberts]

 >     I have had this problem before, with an old monitor. It can also be
 >     solved by turning up the brightness or buying a new monitor.
 > 
 > I have to turn the brightness down to make the battery last.

I'm probably missing the point, but the eye is not very sensitive to red (or
blue) wavelengths. ISTR the maximum sensitivity of the eye (photopic response)
is at about 550nm i.e green. So your battery might last longer if you use a
color for comments that is close to this (assuming the emitters for red,
green and blue are equally efficient).

Nick

Re: font-lock-comment-delimiter-face

[Paul Pogonyshev]

Nick Roberts wrote:
>  >     I have had this problem before, with an old monitor. It can also be
>  >     solved by turning up the brightness or buying a new monitor.
>  >
>  > I have to turn the brightness down to make the battery last.
>
> I'm probably missing the point, but the eye is not very sensitive to red
> (or blue) wavelengths. ISTR the maximum sensitivity of the eye (photopic
> response) is at about 550nm i.e green. So your battery might last longer if
> you use a color for comments that is close to this (assuming the emitters
> for red, green and blue are equally efficient).

BTW green (forest green in Emacs) is my preferred color for comments.
Strongly recommended :)

Paul

Re: font-lock-comment-delimiter-face

[David Kastrup]

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

>  >     I have had this problem before, with an old monitor. It can
>  >     also be solved by turning up the brightness or buying a new
>  >     monitor.
>  > 
>  > I have to turn the brightness down to make the battery last.
>
> I'm probably missing the point, but the eye is not very sensitive to
> red (or blue) wavelengths. ISTR the maximum sensitivity of the eye
> (photopic response) is at about 550nm i.e green. So your battery
> might last longer if you use a color for comments that is close to
> this (assuming the emitters for red, green and blue are equally
> efficient).

It is the backlight that is consuming the bulk of the power, not the
color cells.  So if you are worried about battery power, you should be
using only black and white and turn the backlight down as much as
possible with this setting.  I have my doubts that this will save
inordinate amounts of powers, though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    I'm probably missing the point, but the eye is not very sensitive to red (or
    blue) wavelengths. ISTR the maximum sensitivity of the eye (photopic response)
    is at about 550nm i.e green. So your battery might last longer if you use a
    color for comments that is close to this (assuming the emitters for red,
    green and blue are equally efficient).

The computer has a single brightness control.  I turn it down to the level
needed for me to see ordinary white text.  Therefore, I don't want any text
to be in red.

I would suppose this applies to everyone using a laptop.

    BTW green (forest green in Emacs) is my preferred color for comments.
    Strongly recommended :)

The problem is, green is used for comments.  There are not many colors
available on a tty.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    In Lisp mode it fails to apply `font-lock-comment-delimiter-face' to a
    single ";" as long as it is not located at the start of a line.  The
    cause is probably that `comment-start-skip' in Lisp mode contains
    precautions for not matching escaped semicolons:

I fixed that.  Thanks.

Re: font-lock-comment-delimiter-face

[Ralf Angeli]

* Richard Stallman (2005-05-15) writes:

>     In Lisp mode it fails to apply `font-lock-comment-delimiter-face' to a
>     single ";" as long as it is not located at the start of a line.  The
>     cause is probably that `comment-start-skip' in Lisp mode contains
>     precautions for not matching escaped semicolons:
>
> I fixed that.  Thanks.

As your fix does not concern regular expression matching, does this
mean it is correct for `(looking-at comment-start-skip)' in Lisp mode
to return different values in case of single and multiple semicolons?
That's what I was actually more concerned about.

-- 
Ralf

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    It is the backlight that is consuming the bulk of the power, not the
    color cells.  So if you are worried about battery power, you should be
    using only black and white and turn the backlight down as much as
    possible with this setting.

The keyboard has functions to raise and lower the brightness; how
would I control the backlight separately?  (What exactly is the
backlight, anyway?)

Re: font-lock-comment-delimiter-face

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     It is the backlight that is consuming the bulk of the power, not the
>     color cells.  So if you are worried about battery power, you should be
>     using only black and white and turn the backlight down as much as
>     possible with this setting.
>
> The keyboard has functions to raise and lower the brightness; how
> would I control the backlight separately?

By raising and lowering the brightness settings...

> (What exactly is the backlight, anyway?)

The thing that is shining from behind your LCD screens.  You'll notice
that there is a difference between a nominally black screen and a
switched-off screen.  The difference is the backlight shining through
the LCDs which don't block the light from the backlight absolutely
even when switched to "black".

Not sure whether "backlight" is the right expression.  It is the light
source for the LCD, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    As your fix does not concern regular expression matching, does this
    mean it is correct for `(looking-at comment-start-skip)' in Lisp mode
    to return different values in case of single and multiple semicolons?

I don't understand that question.

Re: font-lock-comment-delimiter-face

[Ralf Angeli]

* Richard Stallman (2005-05-16) writes:

>     As your fix does not concern regular expression matching, does this
>     mean it is correct for `(looking-at comment-start-skip)' in Lisp mode
>     to return different values in case of single and multiple semicolons?
>
> I don't understand that question.

Okay, here are two examples:

(with-temp-buffer
  (insert " ;")
  (backward-char)
  (looking-at "\\(\\(^\\|[^\\\\\n]\\)\\(\\\\\\\\\\)*\\);+ *"))

(with-temp-buffer
  (insert " ;;")
  (backward-char 2)
  (looking-at "\\(\\(^\\|[^\\\\\n]\\)\\(\\\\\\\\\\)*\\);+ *"))

Shouldn't both examples return the same value?  It looks like a bug to
me that the first example returns nil and the second t.

-- 
Ralf

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    > The keyboard has functions to raise and lower the brightness; how
    > would I control the backlight separately?

    By raising and lowering the brightness settings...

That's what I'm already doing, so I guess you don't have a suggestion
for something else I could do instead.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    (with-temp-buffer
      (insert " ;")
      (backward-char)
      (looking-at "\\(\\(^\\|[^\\\\\n]\\)\\(\\\\\\\\\\)*\\);+ *"))

    (with-temp-buffer
      (insert " ;;")
      (backward-char 2)
      (looking-at "\\(\\(^\\|[^\\\\\n]\\)\\(\\\\\\\\\\)*\\);+ *"))

    Shouldn't both examples return the same value?

For that regexp, it is clear that they should NOT both return
the same value.

As for whether it is correct to use that regexp for comment-start-skip,
I am not sure, but I don't see a bug in it as of now.

Re: font-lock-comment-delimiter-face

[Ralf Angeli]

* Richard Stallman (2005-05-16) writes:

> For that regexp, it is clear that they should NOT both return
> the same value.

I reduced the `looking-at' call to `(looking-at "[^\\\n];+")' and now
also see why it does not match in front of a single semicolon.  D'oh.
Sorry for the noise.

-- 
Ralf

Re: font-lock-comment-delimiter-face

[Edward O'Connor]

> By raising and lowering the brightness settings...
>
> That's what I'm already doing, so I guess you don't have a suggestion
> for something else I could do instead.

           M-x customize-face RET font-lock-comment-face RET

I don't mean to sound hostile, but I don't see what is wrong with a
simple user customization. I don't understand why you would make large
changes to Emacs when you could simply change the offending face on your
machine.


Hoping to see an Emacs release in my lifetime,
Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: font-lock-comment-delimiter-face

[Romain Francoise]

Richard Stallman <rms@gnu.org> writes:

> I would suppose this applies to everyone using a laptop.

Well, I have been using Emacs on laptops for years and never had this
problem.  I suggest you revert your changes in Emacs and instead
customize the face in your local setup.  Releasing Emacs 22 like this
will probably get us *lots* of bug reports about comments not being
fontified on ttys.

-- 
Romain Francoise <romain@orebokech.com> | They're nothing but cold
it's a miracle -- http://orebokech.com/ | little demons.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    I don't mean to sound hostile, but I don't see what is wrong with a
    simple user customization. I don't understand why you would make large
    changes to Emacs when you could simply change the offending face on your
    machine.

I don't think I am the only user who uses a console and finds
comments in red hard to read.  Nor the only one who would like comment
delimiters in red.  And this is a small change.

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

And to fix the bug with the single-semi-colon we now introduce
yet-another-config-var that major modes have to set?

So as long as major modes aren't adjusted to also set
font-lock-comment-start-skip, users will see strange behaviors under some
"unusual" circumstances (i.e. only on 8 color ttys, only for single-char
comment starters)?

While I'm here, I'll post yet-another-bug-report about this new feature:

      /*** test in c-mode ***/
      ^^^^                  ^^

The two ** preceding the closing comment marker don't get the
comment-delimiter face.

I'm sure I'll have bumped into yet-another by the time I get to post another
message in this thread.

I must say I'm baffled.


        Stefan


PS: BTW, has anyone measured the slowdown cause by this new code?  The call to
looking-at should be negligible, but the call to looking-back could end up
significant, although by default it won't make any visible difference unless
you're one of the lucky ones running in an 8 color tty, so it's
wasted effort.

Re: font-lock-comment-delimiter-face

[Lute Kamstra]

Richard Stallman <rms@gnu.org> writes:

>     I don't mean to sound hostile, but I don't see what is wrong with a
>     simple user customization. I don't understand why you would make large
>     changes to Emacs when you could simply change the offending face on your
>     machine.
>
> I don't think I am the only user who uses a console and finds
> comments in red hard to read.  Nor the only one who would like comment
> delimiters in red.  And this is a small change.

I agree that red is hard to read on an 8-color console.  White reads
much better.  While I don't like it that comment delimiters look
different than the comment text, I think that the benefit of having
readable comment text outweighs that disadvantage.

Just customizing font-lock-comment-face to white (and not using
font-lock-comment-delimiter-face) on an 8-color console doesn't cut it
as that makes the comments hard to spot.

Lute.

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

> I don't think I am the only user who uses a console and finds
> comments in red hard to read.

You're probably right.  But:
- how many exactly?
- how serious is it?  can't they just customize their comment color?
- why should these users get special treatment?
  I mean, I find the default colors in font-lock to be illegible
  (i.e. I can read every letter, but the colors significantly slowdown my
  reading), so I had to change most/all of them.

> Nor the only one who would like comment delimiters in red.
> And this is a small change.

The downsides of course are:
- it costs CPU time even though in the end the result is only visible for
  those specific users who happen to be using 8-color ttys (or those few
  extra rare ones who read the NEWS and figured they want an angrier fruit
  salad and thus changed their font-lock-comment-delimiter-face to be
  visible in other cases as well).
- it annoys those users who do run 8-color ttys but whose red is readable
  just fine.
- maybe some users want it, but they can't want it that badly since they
  haven't asked for it.
- The most important problem: it's majorly buggy.


        Stefan

Re: font-lock-comment-delimiter-face

[Stefan Monnier]

BTW, let me try to be constructive instead of just trying to shoot down
the feature.

How 'bout we change the current buggy code and replace it with something
more general (and thus more useful to those people who aren't among the
rare few who use 8 color ttys and whose red is not readable and who haven't
already changed their font-lock colors):

Introduce font-lock-comment-keywords which would basically work like
font-lock-keywords, except it's applied only to comments (with the buffer
narrowed to just the comment so that comment-start-skip matches correctly,
without needing font-lock-comment-start-skip).  This way we could highlight
all nested comments in SML, or we could highlight the "*" used on some
continuation lines in some multiline C commenting styles, and people could
set it to nil if they don't care about the feature, and major modes could
add stuff to it, e.g. to highlight javadoc directives, ...


        Stefan

Re: font-lock-comment-delimiter-face

[Kim F. Storm]

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

> BTW, let me try to be constructive instead of just trying to shoot down
> the feature.
>
> How 'bout we change the current buggy code and replace it with something
> more general (and thus more useful to those people who aren't among the
> rare few who use 8 color ttys and whose red is not readable and who haven't
> already changed their font-lock colors):
>
> Introduce font-lock-comment-keywords which would basically work like
> font-lock-keywords, except it's applied only to comments (with the buffer
> narrowed to just the comment so that comment-start-skip matches correctly,
> without needing font-lock-comment-start-skip).  This way we could highlight
> all nested comments in SML, or we could highlight the "*" used on some
> continuation lines in some multiline C commenting styles, and people could
> set it to nil if they don't care about the feature, and major modes could
> add stuff to it, e.g. to highlight javadoc directives, ...

That would be excellent -- after the release.

Since there is such a good way to DTRT, I definitely think
the current comment delimiter highlighting should be removed.
JM2c.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: font-lock-comment-delimiter-face

[Kim F. Storm]

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

>> And this is a small change.

And - as any small change - causes a lot of discussion which
takes away time from making the release.

> - The most important problem: it's majorly buggy.

And we can conclude by now that THERE ARE NO SMALL CHANGES.

So far, it seems that the only user wanting this new feature
is RMS, and it surely wasn't listed in FOR-RELEASE before it
was added.

Sigh!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: font-lock-comment-delimiter-face

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> And this is a small change.
>
> And - as any small change - causes a lot of discussion which
> takes away time from making the release.
>
>> - The most important problem: it's majorly buggy.
>
> And we can conclude by now that THERE ARE NO SMALL CHANGES.
>
> So far, it seems that the only user wanting this new feature
> is RMS, and it surely wasn't listed in FOR-RELEASE before it
> was added.

One thing we wanted to have done for release is to be able to enable
font-locking by default.  Richard considered the default behavior with
comments unsuitable for general use and tried changing that.

The question is whether we can come up with a good scheme not
requiring destabilizing changes that would address his concerns.

Personally, I would still want to see font-lock enabled by default for
22.1.  Since I don't use it myself, I am not in the position of
judging what kind of coloring and schemes people liking font locking
(and it would appear to be a large majority, particularly among
beginning users) would find acceptable, and what not.

I don't like the destabilizing prospects of the recent experiments,
and I don't like the prospect of having font-lock disabled by default
because we could not find settings with the current scheme that were
deemed generally acceptable.

The current experiments seem to indicate that the necessary changes to
sanely accommodate the scheme of Richard are too complicated for the
current point of time.

I don't think that this was obvious from the beginning.  At the
current point of time it would seem to be most sensible to me to scrap
the current attempts, record Stefan's proposal in TODO, and find
settings for the font locking of comments that work well on most
platforms (after all, faces _can_ specify colors depending on tty and
color scarcity) now.

If the results then are generally tolerable, font-locking can probably
be globally enabled for the next release.  If not, not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: font-lock-comment-delimiter-face

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     I don't mean to sound hostile, but I don't see what is wrong with a
  >     simple user customization. I don't understand why you would make large
  >     changes to Emacs when you could simply change the offending face on your
  >     machine.
  > 
  > I don't think I am the only user who uses a console and finds
  > comments in red hard to read.  Nor the only one who would like comment
  > delimiters in red.  And this is a small change.


If the red colored comments are hard to read on a console, can't we
just change the face foreground for font-lock-comment-face for that
situation (i.e. min-colors == 8 and background-mode == 'dark)? 
It seems to me that would be a lot easier than adding
font-lock-comment-delimiter-face route? 

We could either swap the color used by font-lock-comment-face with one
of the other font-lock faces, or use the same color for both
font-lock-comment-face and another face. it's not like there's a lot
of choice for colors (only 8), or very likely to confuse comments with
anything else. 

So just do M-x list-colors-display RET pick a color for comments and
I'll do the needed change.


PS: Offtopic wish: I would be nice if the Linux console allowed for
more than 8 colors to be used (like 256 colors). Maybe this is not
even hard to do, now that a lot of machines use a frame buffer
console. Any linux guys listening? (No, I have no idea if this is
possible or desirable)

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    If the red colored comments are hard to read on a console, can't we
    just change the face foreground for font-lock-comment-face for that
    situation (i.e. min-colors == 8 and background-mode == 'dark)? 
    It seems to me that would be a lot easier than adding
    font-lock-comment-delimiter-face route? 

I am not entirely sure what you're proposing.
Could you be more specific?  I could try it out.

The current behavior, highlighting comment delimiters but not the
comment text, looks good to me.  However, it's possible that some
other solution would also look good.

    So just do M-x list-colors-display RET pick a color for comments and
    I'll do the needed change.

Please don't install such a change, but I'd appreciate it if you sent
me a patch to try.

Re: font-lock-comment-delimiter-face

[Richard Stallman]

    Introduce font-lock-comment-keywords which would basically work like
    font-lock-keywords, except it's applied only to comments (with the buffer
    narrowed to just the comment so that comment-start-skip matches correctly,
    without needing font-lock-comment-start-skip).  This way we could highlight
    all nested comments in SML, or we could highlight the "*" used on some
    continuation lines in some multiline C commenting styles, and people could
    set it to nil if they don't care about the feature, and major modes could
    add stuff to it, e.g. to highlight javadoc directives, ...

It sounds like a good method.  However, I agree that this should only
be tried after the release.  It would require additional work,
customizing various modes to support it.

Re: font-lock-comment-delimiter-face

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     If the red colored comments are hard to read on a console, can't we
  >     just change the face foreground for font-lock-comment-face for that
  >     situation (i.e. min-colors == 8 and background-mode == 'dark)? 
  >     It seems to me that would be a lot easier than adding
  >     font-lock-comment-delimiter-face route? 
  > 
  > I am not entirely sure what you're proposing.
  > Could you be more specific?  I could try it out.

Your original complaint was that font-lock-comment-face that has
face-foreground "red" is hard to read on a console. I am proposing to
just change that "red" color to some other color that is readable on a
console.

  >     So just do M-x list-colors-display RET pick a color for comments and
  >     I'll do the needed change.
  > 
  > Please don't install such a change, but I'd appreciate it if you sent
  > me a patch to try.

I had no intention of installing a change without reaching some
consensus. That would not be wise given the amount of discussions
going on.

Please try this patch:

*** font-lock.el	20 May 2005 15:40:40 -0700	1.257
--- font-lock.el	21 May 2005 10:36:03 -0700	
***************
*** 1678,1686 ****
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      )
      (((class color) (min-colors 8) (background dark))
!      )
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)
--- 1678,1691 ----
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      ;; IMHO this should not have been changed, red is quite readable
!      ;; on a light background (e.g. xterm -bg white)
!      (:foreground "red"))
      (((class color) (min-colors 8) (background dark))
!      ;; Change the color here if you want to see how other colors
!      ;; look like for comments. 
!      ;; You can choose one of: black red green yellow blue magenta cyan white
!      (:foreground "yellow"))
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)
***************
*** 1689,1698 ****
    '((default :inherit font-lock-comment-face)
      (((class grayscale)))
      (((class color) (min-colors 16)))
!     (((class color) (min-colors 8) (background light))
!      :foreground "red")
!     (((class color) (min-colors 8) (background dark))
!      :foreground "red1"))
    "Font Lock mode face used to highlight comment delimiters."
    :group 'font-lock-highlighting-faces)
  
--- 1694,1705 ----
    '((default :inherit font-lock-comment-face)
      (((class grayscale)))
      (((class color) (min-colors 16)))
! ;; Commented out to disable the effects of font-lock-comment-delimiter-face
! ;;     (((class color) (min-colors 8) (background light))
! ;;      :foreground "red")
! ;;     (((class color) (min-colors 8) (background dark))
! ;;      :foreground "red1"))
!     )
    "Font Lock mode face used to highlight comment delimiters."
    :group 'font-lock-highlighting-faces)