For the longest time I have been ignoring a face change at column 80 in my Java code. The text switches to a pinkish color as shown below. Now it is sufficiently bothersome that I would like to chase down the cause and fix it to essentially match fill mode column (I use 100, the Google Android convention). My first question is: is this particular face change controlled by a variable or by elisp code? Simple searching (within Emacs and external) and experimenting does not reveal the culprit. My second question, and the more difficult (I believe), is: given a piece of text in Emacs using different faces, how do I find the origin of the font-lock expression controlling that text?

Code with face switch to pink at column 80

4 Answers 4


You can use describe-char or C-u C-x = (= what-cursor-position with a prefix arg) to obtain a buffer giving as much information as possible about the character at point : font, syntax, properties and, of course, faces.

If not too unlucky, the name of the face will give you the library name that added it.

  • This is the best answer here, IMO. It won't work for places that you cannot put the cursor (e.g. mode line), but it is the correct initial way to check for the face(s) somewhere.
    – Drew
    May 23, 2016 at 14:10

How embarrassing. A few minutes after asking the question, the solution came to me. I might make the case that the asking of the question led to the solution, though.

In any case, the answer that came to me is that I should find the face description using a character in the pinkish text. This led to using M-x describe-face which put a query into the minibuffer: Describe face (default 'whitespace-line'): Using the default yielded:

Face: whitespace-line (sample) (customize this face)

Documentation: Face used to visualize "long" lines.

See ‘whitespace-line-column’.

Defined in ‘whitespace.el’. ...

So whitespace-line-column is the variable I was looking for, but do not let this stop you from posting an even better answer.


I saw that you already solved this, but I thought that I could share the following anyway:

You can use Font-lock studio (an interactive debugger for font-lock keywords) to single step each font-lock rule using the n command. That way, you can easily see which one caused the problem. If you are lucky and the rule contains a function call (instead of a plain regexp) you have found the culprit. Otherwise, you will have to look through the sources for the package that add the rule.


In addition to what @YoungFrog offered, you can often find what a given face is at places where you cannot put the cursor, by using M-x list-faces-display.

That will show you all faces currently defined, WYSIWYG, and that will usually enable you to narrow the list of faces that it could be.

It can become a bit more complicated when faces are merged (combined) or other things are going on. But this should be your second reflex way to check for a face you see, if you cannot use the method mentioned by YoungFrog.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.