* Could the current font-lock mechanism support font locking code in comments? @ 2021-03-30 7:40 scame 2021-03-30 14:06 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: scame @ 2021-03-30 7:40 UTC (permalink / raw) To: emacs-devel@gnu.org 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 7:40 Could the current font-lock mechanism support font locking code in comments? scame @ 2021-03-30 14:06 ` Stefan Monnier 2021-03-30 15:44 ` scame 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2021-03-30 14:06 UTC (permalink / raw) To: scame; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 14:06 ` Stefan Monnier @ 2021-03-30 15:44 ` scame 2021-03-30 16:18 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: scame @ 2021-03-30 15:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel@gnu.org > > `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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 15:44 ` scame @ 2021-03-30 16:18 ` Stefan Monnier 2021-03-30 18:09 ` [External] : " Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2021-03-30 16:18 UTC (permalink / raw) To: scame; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 16:18 ` Stefan Monnier @ 2021-03-30 18:09 ` Drew Adams 2021-03-31 0:10 ` Arthur Miller 2021-03-31 1:12 ` Stefan Monnier 0 siblings, 2 replies; 9+ messages in thread From: Drew Adams @ 2021-03-30 18:09 UTC (permalink / raw) To: Stefan Monnier, scame; +Cc: emacs-devel@gnu.org > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 18:09 ` [External] : " Drew Adams @ 2021-03-31 0:10 ` Arthur Miller 2021-03-31 1:12 ` Stefan Monnier 1 sibling, 0 replies; 9+ messages in thread From: Arthur Miller @ 2021-03-31 0:10 UTC (permalink / raw) To: Drew Adams; +Cc: scame, Stefan Monnier, emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-30 18:09 ` [External] : " Drew Adams 2021-03-31 0:10 ` Arthur Miller @ 2021-03-31 1:12 ` Stefan Monnier 2021-03-31 4:36 ` Drew Adams 1 sibling, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2021-03-31 1:12 UTC (permalink / raw) To: Drew Adams; +Cc: scame, emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-31 1:12 ` Stefan Monnier @ 2021-03-31 4:36 ` Drew Adams 2021-03-31 4:38 ` Drew Adams 0 siblings, 1 reply; 9+ messages in thread From: Drew Adams @ 2021-03-31 4:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: scame, emacs-devel@gnu.org > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Re: Could the current font-lock mechanism support font locking code in comments? 2021-03-31 4:36 ` Drew Adams @ 2021-03-31 4:38 ` Drew Adams 0 siblings, 0 replies; 9+ messages in thread From: Drew Adams @ 2021-03-31 4:38 UTC (permalink / raw) To: Drew Adams, Stefan Monnier; +Cc: scame, emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-31 4:38 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-30 7:40 Could the current font-lock mechanism support font locking code in comments? scame 2021-03-30 14:06 ` Stefan Monnier 2021-03-30 15:44 ` scame 2021-03-30 16:18 ` Stefan Monnier 2021-03-30 18:09 ` [External] : " Drew Adams 2021-03-31 0:10 ` Arthur Miller 2021-03-31 1:12 ` Stefan Monnier 2021-03-31 4:36 ` Drew Adams 2021-03-31 4:38 ` Drew Adams
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.