> 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 h
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
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
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Stefan Monnier <[EMAIL PROTECTED]> 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
Stefan Monnier <[EMAIL PROTECTED]> 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
Stefan Monnier <[EMAIL PROTECTED]> 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
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
e:
- 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
vis
s
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-
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, on
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
Richard Stallman <[EMAIL PROTECTED]> 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 2
> 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
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 th
* 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 ques
* 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
__
(with-temp-buffer
(insert " ;")
(backward-char)
(looking-at "\\(\\(^\\|[^\n]\\)\\(\\)*\\);+ *"))
(with-temp-buffer
(insert " ;;")
(backward-char 2)
(looking-at "\\(\\(^\\|[^\n]\\)\\(\\)*\\);+ *"))
Shouldn't both examples retu
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
* 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 conta
Richard Stallman <[EMAIL PROTECTED]> 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 sett
> 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.
___
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
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.
__
Nick Roberts <[EMAIL PROTECTED]> 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
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 s
> 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) wave
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 c
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.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http:
> 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
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.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://l
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 free
> 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 to
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.
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> From: [EMAIL PROTECTED] (Kim F. Storm)
>> Date: Fri, 13 May 2005 10:21:35 +0200
>> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>>
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
>>
>> > Please, let's rename this new face to something sensible like
>> >
> From: [EMAIL PROTECTED] (Kim F. Storm)
> Date: Fri, 13 May 2005 10:21:35 +0200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
> > Please, let's rename this new face to something sensible like
> > mail-citation-prefix-face (or the same without the "
Stefan Monnier <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.cua
> 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 f
> 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 st
> * font-lock.el (font-lock-comment-delimiter-face): Inherit from
> font-lock-comment-face rather than copying its setting.
> font-lock-comment-delimiter-face differs from font-lock-comment-face
> under X. They used to be Firebrick; now font-lock-comment-delimiter-face
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
Since this change:
2005-05-12 Stefan Monnier <[EMAIL PROTECTED]>
* font-lock.el (font-lock-comment-delimiter-face): Inherit from
font-lock-comment-face rather than copying its setting.
font-lock-comment-delimiter-face differs from font-lock-comment-face
under X. They u
ntactically-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
b
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&#
> 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 &q
We should not make a new branch now. Just now we should focus on the
release itself.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
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
> 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
> From: Thien-Thi Nguyen <[EMAIL PROTECTED]>
> Date: Sun, 24 Apr 2005 17:46:40 -0400
> Cc: emacs-devel@gnu.org
>
>From: Glenn Morris <[EMAIL PROTECTED]>
>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 rele
From: Glenn Morris <[EMAIL PROTECTED]>
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
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 cle
Richard Stallman <[EMAIL PROTECTED]> 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, l
> From: Richard Stallman <[EMAIL PROTECTED]>
> 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 Rm
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
53 matches
Mail list logo
