If cursor stays on error the tip should not disappear

[romanofski]

If the error message is long, it would be great if the tip would stay as long open as the cursor stays on the indicated error. Otherwise studying the error message is cumbersome.

Increasing the timeout is a possible work around, but cumbersome if it stays open for too long under errors/warnings which are unimportant and the cursor has been moved already away.

[swsnr]

Hello,

Thank you for giving feedback about this package.

I'm not sure though whether I understood your problem completely. Why can't you increase the timeout? This extension should hide the tooltip when the point moves away from an error, so a longer timeout should not interfere as far as I can see.

Would you mind to give some more details? It'd be great if you could record a little screen cast that demonstrates the issue.

Thank you

[romanofski]

Sorry, for being so ambigious. I appreciate the quick reply. According to your description, I wonder if my pos-tip is not miss-configured (emacs n00b, using spacemacs).

I've made a screen cast for the mentioned workaround. If I set the timeout to 10s (ignore the mouse pointer)

it takes way too long to close the pop-up, thus clobbering additional lines I want to write in.

If I set the timeout shorter, the pop-up won't clobber additional lines any more, but now it even fades out if I keep the cursor on the error. That makes it very hard to study the error/warning.

Cheers!!

[swsnr]

@romanofski Thank you for your reply, particularly for the screencast :heart_eyes: It's really insightful :+1:

Looking at this screencast, I think the issue is not so much that the tooltip stays open for such a long time. Specifically, I see that the "old" tooltip is properly closed when you move to the next line.

As far as I can see, the problem is rather that the "new" tooltip shows "too fast", while you're still working on the current line. In other words, Flycheck shows the error to eagerly.

Would you mind to tell me your current value of flycheck-display-errors-delay? Use SPC h d v flycheck-display-errors-delay to find out.

Would you also mind to try whether increasing that value–try doubling it—leads to better behaviour here? Use SPC : customize-variable RET flycheck-display-errors-delay to change the value quickly and press State -> Set for current session only to set the value only for the currently running Emacs.

[romanofski]

Ok. I've tried increasing flycheck-display-errors-delay. It was set to 0.9 and I bumped it to 2 seconds. This is a bit better. I haven't thought about it from the perspective that it might pop up too quickly, so good thinking. Thanks for the instructions as well - very appreciated.

However, this does seem to make it only slightly better. Once the pop up is displayed, it can still clobber the work space. Made another screencast to illustrate this.

Here I'm removing an obsolete exported function from my module. While that doesn't trigger the pop up, it is actually triggered by moving the next function into place. If I now want to add my bag of other functions I've just defined (perhaps because I just had the most productive time of the day), I still need to wait until the pop up disappears or just type "blindfolded" adding the additional functions.

[cpitclaudel]

Hi @romanofski! Thanks for posting this screencast, this is really helpful.

I can explain why moving the function into place triggers the popup. After removing the obsolete function, the coma before fetchGTFSRealTimeFeed is a syntax error; thus the underline on than function name. Removing the newline and the coma fixes the error, but the syntax checker takes just a bit too long to answer, so the old error is displayed.

What I cannot explain, however, is why the error display remains visible as you move around, since that error does not exist any more. @lunaryorn, am I missing something obvious? On my machine, at least, moving out of an error immediately hides the error tooltip.

This is a wild guess, but could it be that you configured this package using (setq flycheck-display-errors-function #'flycheck-pos-tip-error-messages) instead of (flycheck-pos-tip-mode)?

[romanofski]

Good call @cpitclaudel . It is set to 'flycheck-pos-tip-error-messages downstream at: https://github.com/syl20bnr/spacemacs/blob/master/layers/syntax-checking/packages.el#L123

Customizing the variable and setting it to flycheck-pos-tip-mode fixes the problem. I wonder if that is a problem worth filing against spacemacs?

Thank you very much for pointing this out.

[swsnr]

@romanofski I'm closing this issue then, since it's apparently an upstream configuration issue.

As far as I know, the development version of Spacemacs configures this extension correctly; apparently that change was not back-ported to the official releases. It might be worth to make the Spacemacs maintainers aware of this.

Thank you for your feedback :)

[swsnr]

@romanofski I have opened https://github.com/syl20bnr/spacemacs/issues/4181. Meanwhile you can copy the setup code from the develop branch to a private layer to have a proper setup for flycheck-pos-tip.

Sorry for the hassle, as maintainers of this extension we should have taken more care to make sure that downstream distributions update their releases properly. :disappointed:

[romanofski]

@lunaryorn No worries. All good. Thanks for the instructions to use it on spacemacs master and filing an issue :)