6

Occasionally I have this ugly red underline in my python code. It seems not related to any flymake error/warnings. Does anyone know why it shows and how it can be removed? Thanks!

I am using latest elpy and emacs (24.4) on Mac OSX 10.9

enter image description here

The problem only occurs occasionally (but very annoying). Now it happens again. Here is the output of describe-char on a SPACE character in red underline region:

             position: 848 of 1960 (43%), column: 6
            character: SPC (displayed as SPC) (codepoint 32, #o40, #x20)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x20
               script: latin
               syntax:      which means: whitespace
             category: .:Base, a:ASCII, l:Latin
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x20
            file code: #x20 (encoded by coding system utf-8-unix)
              display: by this font (glyph code)
    mac-ct:-*-Menlo-normal-normal-normal-*-12-*-*-*-m-0-iso10646-1 (#x03)

Character code properties: customize what to show
  name: SPACE
  general-category: Zs (Separator, Space)
  decomposition: (32) (' ')

There are 4 overlays here:
 From 42 to 1961
  semantic             [Show]
 From 400 to 1961
  face                 semantic-unmatched-syntax-face
  semantic             unmatched
 From 517 to 1469
  semantic             [Show]
 From 531 to 1961
  face                 semantic-unmatched-syntax-face
  semantic             unmatched


There are text properties here:
  face                 font-lock-string-face
  fontified            t

[back]
RNA
  • 368
  • 2
  • 10
  • Is it possibly fly*check*? – nanny Mar 27 '15 at 18:30
  • If it's only occasional, and only in Python code, then I guess that rules out a red underline as part of your `default` face definition. ;-) Try bisecting your init file or otherwise turning things (e.g. elpy) off, to see if you can find the culprit. – Drew Mar 27 '15 at 18:50
  • @nanny: I don't have flycheck (unless elpy installed it behind me). – RNA Mar 27 '15 at 22:44
  • @Drew: The problem is that it only occurs occasionally. so it is really hard to find the culprit by trial and error. A clue would be very helpful. – RNA Mar 27 '15 at 22:45
  • 1
    @RNA Whenever that happens, put the point (cursor) on one of the characters with the red underline and do `M-x describe-char`. That will give you all the characteristics of that char, including the face that does that underline adornment (a char could have multiple faces). Please add that info to this question. – Kaushal Modi Mar 28 '15 at 13:59
  • @RNA `flycheck` is part of `elpy`. Please do try and bisect your config to find what the issue is. We can better help you then. – PythonNut Mar 29 '15 at 23:44
  • @kaushalmodi I updated with that output. It is likely caused by "semantic-unmatched-syntax-face"? That face does has red underline. then how can I figure out how this face is triggered? – RNA Apr 04 '15 at 00:53
  • I don't use cedet but I got this by googling: http://www.randomsample.de/cedetdocs/semantic-user/Unmatched-Syntax-Highlighting.html When that happens next time, try doing `M-x semantic-show-unmatched-syntax-mode` – Kaushal Modi Apr 04 '15 at 01:16
  • 1
    I grepped through the emacs source code. The only way that could happen is if you (in your init.el) or some package (in the elpa/ dir) is enabling `semantic-show-unmatched-syntax-mode`. Grep your whole ~/.emacs.d dir. – Kaushal Modi Apr 04 '15 at 02:09
  • Turn of `semantic-unmatched-syntax-mode` or remove it from global Semantic mode hook if you add it. It is mainly used for debugging Semantic grammar files. – Tu Do Apr 04 '15 at 05:53
  • it seems the culprit. I had `(global-semantic-show-unmatched-syntax-mode 1)` in my .emacs file. Thanks to all of you! – RNA Apr 04 '15 at 07:56
  • @RNA I have added an answer to close this open question – Kaushal Modi Apr 06 '15 at 16:56

2 Answers2

8

When you spot a problem in the way how emacs behaves and if that happens only when you load your emacs config (init.el or .emacs) and not when you run emacs -Q, you need to bisect your init to find the culprit as @Drew mentioned in the comments.

Fortunately, you don't have to bisect your init in this case as you have a tangible visual clue of the problem.

The visual problem is that you get the red underlines which you don't want. As it is visual, you can always figure out what's causing that formatting by following these steps:

  1. Move the point to one of that characters that has the unwanted red underline.
  2. Do M-x describe-char.
  3. Find out which faces are active for that character (from the information that the above step prints out).
  4. Grep for that face name in your elpa/ (technically the directory name saved in package-user-dir variable) directory. If that does not yield any results, repeat the grep in the emacs source code lisp/ directory. This step will tell you which package and function(s) assigned that face to that string.
  5. Once you figure out the function name(s) assigning this face, you need to figure out where you are calling that(those) function(s); grep for it(them) in your ~/.emacs.d (technically the directory name saved in user-emacs-directory).

That will tell you which piece of code is enabling those faces.

PS: Though bisecting the init is default way to debug your emacs setup issues.

Kaushal Modi
  • 25,203
  • 3
  • 74
  • 179
1

Following @Kaushal Modi's answer, the offending face, for me, was nobreak-space. I removed the face with:

(set-face-attribute 'nobreak-space nil :underline 'unspecified :inherit 'unspecified)
Lorem Ipsum
  • 4,327
  • 2
  • 14
  • 35