error with void `flycheck-relevant-error-other-file-p`
yatesco opened this issue · comments
It seems that the flycheck-relevant-error-other-file isn't defined properly in the version pulled from MELPA:
(use-package flycheck-inline :ensure t) loads OK, but when you point over an error, it throws Flycheck error display error: (void-function flycheck-relevant-error-other-file-p)
If I add the following above use-package then it works, and I get the fantastic inline errors.
(defun flycheck-relevant-error-other-file-p (x)
nil) WARNING: I am a newbie(ish) at this stuff, so it is highly likely I have mucked something up myself.
Can you report your installed flycheck-version? And flycheck-inline?
I just downloaded fresh copies and I still get the same problem.
flycheck: v31
flycheck-inline: 20180821.849
emacs: 26.1
flycheck: v31
flycheck-relevant-error-other-file-p is in version 32, which is unreleased yet. Although, MELPA should get you the latest development version. Are you using the MELPA stable channel?
I was using both Stable and non-stable. Removing Melpa Stable made other things break. Once I have sorted those out I will purse this. Feel free to close this and I can reopen if necessary (I have no idea what housekeeping rules you have :-)).
I'll leave it open because we are in fact targeting the development version of flycheck, and declaring a dependency on flycheck 31, which is incorrect.
@cpitclaudel Will just bumping the dependency to flycheck . 32 in flycheck-inline work? I'm light on details on the process of dependency resolution done by package.el, in conjunction with loading packages from MELPA (in which the version number is actually 20180823.826).
Did we do a v32 release? The problem here seems to be that the latest Flycheck on MELPA is v31.
Once we do that, bumping the dependency should work.
For existing users, we don't even need to bump the dependency: next time they update they'll get the new Flycheck automatically.
Did we do a v32 release?
We didn't. And I was hoping to resolve some UI issues with errors in other files before tagging v32. So my question is: what happens if we still declare a dependency on flycheck . 32 in flycheck-inline, even though v32 has not been tagged yet? Using MELPA unstable, it will always fetch the latest master, so that's a non-issue. But for people using MELPA stable, it should refuse to install flycheck if only the v31 can be found? And when using both stable and unstable, it will do the right thing?
Keep in mind that flycheck-inline is not in MELPA stable. Probably should be, if we just tagged a release as well.
But for people using MELPA stable, it should refuse to install flycheck if only the v31 can be found?
Yup, I think that's what it would do.
And when using both stable and unstable, it will do the right thing?
IIUC, yes