Hello,
As mentioned here, I use flycheck-irony which depends on flycheck.
For some reason, as seen in the link before, all my fringe indicators have the same color.
To make sure that it was not my theme fringe faces or configuration fringe bitmaps that was causing the trouble, I commented them all to have a minimalistic setup that only use flycheck with emacs-lisp-mode and the same happens.
How can I debug this ?
Thanks !
Please try to reproduce the bug in emacs -Q, with no additional packages loaded besides Flycheck. Please do not use Irony, but try to reproduce the bug with a built in syntax checker, and make sure that no themes are loaded.
Also, please show the output of the M-x emacs-version.
Thanks Sebastian,
I'm using emacs 25.1.50.1 on OSX 10.11.
I've disabled all of my config except flycheck, with a hook for emacs-lisp-mode. The same error occurs, so I think irony has nothing to do with it ...

See. On the screenshot, the wave is red, which indicates an error, bit the fringe indicator is orange.
Also, emacs -Q does not load any package.
@jwintz Never mind, I was able to reproduce the issue on Emacs 25.1. However, the fringe colours are correct in Emacs 24.5:

This appears to be a regression in Emacs 25. Please report it to Emacs with M-x report-emacs-bug.
Will do so. Thanks. How do you pop up the flycheck error buffer ?
On 29 nov. 2015, at 11:44, Sebastian Wiesner [email protected] wrote:
@jwintz Never mind, I was able to reproduce the issue on Emacs 25.1. However, the fringe colours are correct in Emacs 24.5:
This appears to be a regression in Emacs 25. Please report it to Emacs with M-x report-emacs-bug.
—
Reply to this email directly or view it on GitHub.
With C-c ! l, see Listing errors.
I've been having this issue too, since Emacs 25.1. Today I spent an afternoon to bisect Emacs' source, and found out that the issue originates from this commit. (github mirror)
That commit caused several funny things, including that the background and the foreground colors in the fringe area were inverted (which was later fixed), and the fringe bitmaps were flipped horizontally (which too was later fixed). However, all the fringes having the same color was never fixed.
I am no expert in Objective-C but I was able to get rid of the problem by reverting the usage of xmb_fg-state variable (part of the changes in aforementioned commit). I patched the code on top of 25.2 and it seemed to fix at least flycheck's behaviour.
diff --git src/nsimage.m src/nsimage.m
index 3f49fc046b..ff7ccef0bf 100644
--- src/nsimage.m
+++ src/nsimage.m
@@ -270,7 +270,6 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
}
}
- xbm_fg = fg;
[self addRepresentation: bmRep];
return self;
}
@@ -298,18 +297,14 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
{
int i, len = s.width*s.height;
int rr = r * 0xff, gg = g * 0xff, bb = b * 0xff;
- unsigned char fgr = (xbm_fg >> 16) & 0xff;
- unsigned char fgg = (xbm_fg >> 8) & 0xff;
- unsigned char fgb = xbm_fg & 0xff;
for (i = 0; i < len; ++i)
- if (planes[0][i] == fgr && planes[1][i] == fgg && planes[2][i] == fgb)
+ if (planes[3][i] != 0)
{
planes[0][i] = rr;
planes[1][i] = gg;
planes[2][i] = bb;
}
- xbm_fg = ((rr << 16) & 0xff) + ((gg << 8) & 0xff) + (bb & 0xff);
}
return self;
diff --git src/nsterm.h src/nsterm.h
index 5d2513aea7..9de7d94be4 100644
--- src/nsterm.h
+++ src/nsterm.h
@@ -643,7 +643,6 @@ char const * nstrace_fullscreen_type_name (int);
NSBitmapImageRep *bmRep; /* used for accessing pixel data */
unsigned char *pixmapData[5]; /* shortcut to access pixel data */
NSColor *stippleMask;
- unsigned long xbm_fg;
}
+ allocInitFromFile: (Lisp_Object)file;
- (void)dealloc;
The reason for the implementation is not completely clear to me, so it is possible that something else breaks (as I mentioned I am no expert in Objective-C, nor in display servers).
I'll write an Emacs bug report to hopefully have someone fix this properly, but for someone already building from source and being annoyed by this issue can give this one a try :)
Emacs devs don't seem to be too excited with fixing OS X -only issues though :/
@nyyManni Thanks for sharing your results. And good luck with the patch!
This issue is now patched on master :)
@nyyManni, Awesome ! Works like a charm :-)
Most helpful comment
This issue is now patched on master :)