error with void `flycheck-relevant-error-other-file-p`

[yatesco]

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.

[fmdkdd]

Can you report your installed flycheck-version? And flycheck-inline?

[yatesco]

I just downloaded fresh copies and I still get the same problem.

flycheck: v31 flycheck-inline: 20180821.849 emacs: 26.1

[fmdkdd]

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?

[yatesco]

Not intentionally:-), I’ll double check this afternoon when I am next at the computer.

I erased my /elpa cache this morning, so everything is the latest.

Sent from my iPhone

On 3 Sep 2018, at 10:41, fmdkdd notifications@github.com wrote:

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?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[yatesco]

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 :-)).

[fmdkdd]

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).

[cpitclaudel]

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.

[fmdkdd]

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.

[cpitclaudel]

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