Inline errors stop showing after some time

[Tom Solberg]

Hi,

I've been using flycheck-inline for a few weeks, without issues on Windows. However, this week I started using Ubuntu (18.04) as my primary environment and have been having issues with the inline messages disappearing after a while. I primarily use this in Rust, so I cannot say whether it shows up in other modes.

This is what I know so far:

• occurs reliably using Emacs 26.1 on Ubuntu - have not seen the issue on Windows 26.1
• latest version of flycheck-inline installed via (package-install 'flycheck-inline).
• no errors messages are printed, and M-x toggle-debug-on-error does not trigger anything
• toggling the mode off and on again causes the messages to reappear for a while
• flycheck (and helm-flycheck, and the error-lines) are still updating as they should
• so far I have not been able to trigger flycheck-inline to start displaying errors again without manually toggling
• I've only observed it stopping working immediately after a format-save-flycheck cycle. I think it's related to automatic buffer formatting, but I've not found a reproduction sequence yet, so it's hard to verify.

Unfortunately, I've not been able to find out more yet, but I figured I'd post while I continue investigating in case someone else has any ideas or thoughts.

[fmdkdd]

Thanks for the report. The fact that you have the issue on Ubuntu and not on Windows is suspicious.

When that happens to you, you could try stepping through functions in order to determine what exactly is not working. If flycheck is working, then you still have errors and overlays. flycheck-inline just changes flycheck-display-errors-function and uses overlays for displaying the errors inline. Finding out where this goes wrong could be helpful.

Of course, reproduction steps would be best.

Keep us posted!

[Tom Solberg]

As a small update to this issue, I've done some more testing and while I haven't got a reliable reproduction yet I've found some more details.

• Toggling flycheck-inline-mode does not always resolve the problem
• Reverting the buffer does not always resolve the problem (!)
• Large screen movements seem to help with resolving the error state in combination with the above two tricks
  • Specifically, it feels like moving the error line off the visible area and then back again has a high success rate.
• The messages (or so I think) briefly flash before disappearing, for what is most likely a single update. If toggling the mode does not resolve, repeatedly toggling back and forth will cause the messages to flash each time.
• Errors further down in the visible area are more prone to trigger the problematic behavior
  • In particular, I've never seen the issue on the top line of a buffer (which is tagged for "errors in other files" which I use a lot).
• I've done more Python coding over the last week and never observed the issue there. The primary difference in these two modes is that my Python errors are always a single line, while Rust errors are several lines.

[fmdkdd]

Large screen movements seem to help with resolving the error state in combination with the above two tricks
Specifically, it feels like moving the error line off the visible area and then back again has a high success rate.

What desktop environment are you using? The default Ubuntu one?

[Tom Solberg]

I'm using a very standard i3 as my window manager, no desktop environment.

[fmdkdd]

Hmm, I'm also using i3, I've had a bug in Eclipse where the cursor disappears, and the only way to get it back is to move the mouse out of the window and back in. I never encountered this issue with Unity.

With Emacs under i3 I've got flickering which is resolved when toggling fullscreen on and off just once. But I never encountered the inline errors disappearing by themselves.

It might be worth trying out another window manager.