Could the current font-lock mechanism support font locking code in comments?

Could the current font-lock mechanism support font locking code in comments?

[scame]

For example, if I have a file which have some
commented code parts then they could be easier to
read if they were also font locked maybe with dimmed
versions of the regular font lock colors.

Could it be done by reusing the current font locking
implementation and re-running it on a commented code part?

I mean something like layers, the comment is font locked
first with comment syntax as usual and then if some option
is set then font locking is run again on the comment contents
like it's some individual file and it's fontified with dimmed
colors, so it can be distinguished from regular code.

Could current font lock support this somehow or there
is no way that the same buffer part can be fontified
two times by such competing rules?

Re: Could the current font-lock mechanism support font locking code in comments?

[Stefan Monnier]

> Could current font lock support this somehow or there
> is no way that the same buffer part can be fontified
> two times by such competing rules?

`sm-c-mode` does exactly what you describe, except it does it inside
things the user doesn't think are comments: it sets up the buffer's
syntax-table such that preprocessor directives are treated a special
kinds of comments, and then it tells font-lock to apply the usual rules
inside those "comments".

IOW, the problem is just one of recognizing those comments that contain
code rather than text, which requires some kind of markup.


        Stefan

Re: Could the current font-lock mechanism support font locking code in comments?

[scame]

>
> `sm-c-mode` does exactly what you describe, except it does it inside
> things the user doesn't think are comments: it sets up the buffer's
> syntax-table such that preprocessor directives are treated a special
> kinds of comments, and then it tells font-lock to apply the usual rules
> inside those "comments".


Sounds good. Though in this case the usual rules don't apply in the sense
that it should use the dimmed version of the same colors, so that commented
code is still visually distinct from uncommented code.

Taking this  example:

// void func () {  }

the comment starter // should have regular comment color and the code
inside should be syntax highlighted with dimmed colors of the regular
faces.

Does this complicate things?


>
> IOW, the problem is just one of recognizing those comments that contain
> code rather than text, which requires some kind of markup.
>

Yes, some kind of markup should be necessary to activate syntax
coloring in those comments.

Re: Could the current font-lock mechanism support font locking code in comments?

[Stefan Monnier]

> the comment starter // should have regular comment color and the code
> inside should be syntax highlighted with dimmed colors of the regular
> faces.
> Does this complicate things?

Yes and no: AFAIK Emacs's faces don't support "dimming", so you either
do it the hard way and get what you describe (which requires creating new
faces and hence knowing which faces are used by the current
font-lock-rules, etc...), or you take the easy way out and just apply an
additional face that marks the commented out code in some other way
(e.g. by adding a background color).


        Stefan

RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments?

[Drew Adams]

> > the comment starter // should have regular comment color and the code
> > inside should be syntax highlighted with dimmed colors of the regular
> > faces.
> > Does this complicate things?
> 
> Yes and no: AFAIK Emacs's faces don't support "dimming", so you either
> do it the hard way and get what you describe (which requires creating new
> faces and hence knowing which faces are used by the current
> font-lock-rules, etc...), or you take the easy way out and just apply an
> additional face that marks the commented out code in some other way
> (e.g. by adding a background color).

Vanilla Emacs might not have dimming, but Emacs has it.

Library `doremi-frm.el' provides commands that let
you incrementally dim or strengthen a face or frame
foreground or background.

WYSIWYG - you can see the change in a sample, with
an original sample next to it, for comparison.  Hit
`C-g' to cancel the changes, or `RET' to accept them.

For example, command `doremi-face-bg+' changes the
foreground color of a face.  You can change any of
these color components at any time, switching to
another just by typing its initial letter:

  `r' - red
  `g' - green
  `b' - blue
  `h' - hue (basic color)
  `s' - saturation (purity)
  `v' - value (brightness)

  `R' - red, green, and blue, at the same time
  `H' - hue, saturation, and value, at the same time

For example, you can type `v' and use the arrow keys or
mouse wheel to change the value component, then type `s'
and use the arrows or wheel to change the saturation
component, and so on, all in the same call to the command.

Depending on what kind of "dimming" effect you want, it
means changing the value (brightness) component or the
saturation component, or both.

`doremi-face-fg+ does the same thing, but acts on the
face foreground, not background.  And `doremi-bg+' and
`doremi-fg+' act on the frame foreground and background,
instead of those of a particular face.

`doremi-frm.el' requires these other libraries.  All are
available on Emacs Wiki.

  `doremi.el'
  `hexrgb.el'
  `frame-fns.el'
  `faces+.el'

Doc: https://www.emacswiki.org/emacs/DoReMi

Code: https://www.emacswiki.org/emacs/download/doremi-frm.el

Re: [External] : Re: Could the current font-lock mechanism support font locking code in comments?

[Arthur Miller]

Drew Adams <drew.adams@oracle.com> writes:

>> > the comment starter // should have regular comment color and the code
>> > inside should be syntax highlighted with dimmed colors of the regular
>> > faces.
>> > Does this complicate things?
>> 
>> Yes and no: AFAIK Emacs's faces don't support "dimming", so you either
>> do it the hard way and get what you describe (which requires creating new
>> faces and hence knowing which faces are used by the current
>> font-lock-rules, etc...), or you take the easy way out and just apply an
>> additional face that marks the commented out code in some other way
>> (e.g. by adding a background color).
>
> Vanilla Emacs might not have dimming, but Emacs has it.
>
> Library `doremi-frm.el' provides commands that let
> you incrementally dim or strengthen a face or frame
> foreground or background.
>
> WYSIWYG - you can see the change in a sample, with
> an original sample next to it, for comparison.  Hit
> `C-g' to cancel the changes, or `RET' to accept them.
>
> For example, command `doremi-face-bg+' changes the
> foreground color of a face.  You can change any of
> these color components at any time, switching to
> another just by typing its initial letter:
>
>   `r' - red
>   `g' - green
>   `b' - blue
>   `h' - hue (basic color)
>   `s' - saturation (purity)
>   `v' - value (brightness)
>
>   `R' - red, green, and blue, at the same time
>   `H' - hue, saturation, and value, at the same time
>
> For example, you can type `v' and use the arrow keys or
> mouse wheel to change the value component, then type `s'
> and use the arrows or wheel to change the saturation
> component, and so on, all in the same call to the command.
>
> Depending on what kind of "dimming" effect you want, it
> means changing the value (brightness) component or the
> saturation component, or both.
>
> `doremi-face-fg+ does the same thing, but acts on the
> face foreground, not background.  And `doremi-bg+' and
> `doremi-fg+' act on the frame foreground and background,
> instead of those of a particular face.
>
> `doremi-frm.el' requires these other libraries.  All are
> available on Emacs Wiki.
>
>   `doremi.el'
>   `hexrgb.el'
>   `frame-fns.el'
>   `faces+.el'
>
> Doc: https://www.emacswiki.org/emacs/DoReMi
>
> Code: https://www.emacswiki.org/emacs/download/doremi-frm.el

One way is, maybe, to use theme that support different shades of color
such as B. Batsov's implementation of Solarized. Solarized ahs 8 base
colors and 8 accent colors. Batsov has introduced 8 brither and 8 darker
shades ot those 8 accent colors. A theme creator could use that scheme
to create a syntax highlight scheme where normal syntax colors uses
those 8 accented color and brighter/darker accents in comments.

I am not sure about the approach, just an idea.

Re: [External] : Re: Could the current font-lock mechanism support font locking code in comments?

[Stefan Monnier]

> Vanilla Emacs might not have dimming, but Emacs has it.
> Library `doremi-frm.el' provides commands that let
> you incrementally dim or strengthen a face or frame
> foreground or background.

What I meant is that there is no way to define a face that dims
other faces.

What you point to is what I was referring to as the hard way: you have
to come up with a list of faces used by the font-lock rules then pass it
to a function (like the ones in `doremi-frm`) which returns a new face
(since you can't modify the actual font-lock faces which are still
being needed in their non-dimmed form) and then arrange to run the
existing rules in such a way that they actually use your newly
defined faces.

It's cumbersome and tricky to do it in a reliable way.

Instead, what we'd need is a face whose effect is to modify the
underlying face (e.g. by dimming it).  I guess alpha-blending could be
used for that.


        Stefan

RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments?

[Drew Adams]

> > Vanilla Emacs might not have dimming, but Emacs has it.
> > Library `doremi-frm.el' provides commands that let
> > you incrementally dim or strengthen a face or frame
> > foreground or background.
> 
> What I meant is that there is no way to define a face that dims
> other faces.

Was that requested?

> What you point to is what I was referring to as the hard way: you have
> to come up with a list of faces used by the font-lock rules 

You can do what I described in a blanket way to
all faces.  Or to any faces.  And any faces can
be used by font-lock (rules).

> then pass it to a function (like the ones in
> `doremi-frm`) which returns a new face
> (since you can't modify the actual font-lock faces

Why do you say that you can't change the actual
font-lock faces?  With what I described you do
exactly that (to any faces, whether used for
font-locking or not).  Do you mean something
different, by "modify the actual faces" from
changing their attribute values (e.g. foreground
and background colors)?

> which are still being needed in their non-dimmed form)

I don't follow you.  Why is that?  Was that part of
the request - that the same face have two different
appearances, and at the same time no less?  I don't
even know what that means.

> and then arrange to run the existing rules in such
> a way that they actually use your newly defined faces.

In what I described face colors are changed; that's
all.  Font-locking still does what it does.  It uses
the same faces - they just change color; that's all.

In what I described the colors change as you watch,
i.e., as you change them incrementally.  There's no
change to anything in font-lock (rules, face names,
whatever).

> It's cumbersome and tricky to do it in a reliable way.

I guess we're talking about completely different things.
Perhaps I misunderstood the request.  I thought it was
just to dim some (or all) faces.  That, you can do with
what I described - dim, desaturate, the opposite, or
whatever.

> Instead, what we'd need is a face whose effect is to modify the
> underlying face (e.g. by dimming it).  I guess alpha-blending could be
> used for that.

Sorry, you've lost me.  I don't know what the need is
to have a face whose effect is to modify another,
"underlying" face (dimming it).  What's an "underlying"
face - are you perhaps talking about face attribute
inheritance?

Anyway, it's not important that I follow you.  What I
described is, I hope, clear.  If it doesn't correspond
to the request, so be it.  Sorry for the noise, in that
case.

RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments?

[Drew Adams]

Oops.

I guess I came into the thread late, and the request was
to have font-lock rules that apply outside comments also
apply within comments, but in a dimmed way.

Yes, that's something different from what I thought was
requested - I thought it was just to dim some faces.