Next/previous error should cycle instead of stopping at the end/start of the buffer

[PierreR]

It would be much more convenient if next/previous-error (SPC-e-n, SPC-e-p) would always cycle to the next error instead of stopping at the end/start of the buffer.

In that regard, SPC-e-n for instance will always find an error if there is one.

[StreakyCobra]

Using flycheck-next-error-pos to know if there are further errors (using -1 argument to check backward), and the reset argument of flycheck-next-error to restart at beginning, it should be fairly simple to cycle forward.

For cycling backward, as flycheck-previous-error doesn't have a reset argument to start from the end, a PR should be done to flycheck to support it. It doesn't look to complicate though, changing the second code line of flycheck-next-error-pos to:

(pos (if reset (if (>= n 0) (point-min) (point-max)) (point))))

instead of

(pos (if reset (point-min) (point))))

and adding the reset argument to flycheck-previous-error should do the trick.

[StreakyCobra]

Ping @lunaryorn ☝️ If you want to include proactively the support for backward reset in flycheck to allow backward cycle of errors ☺️ Otherwise someone (maybe me) will PR it!

Also, maybe are you interested to have directly the support for cycling functions in flycheck?

[TheBB]

Whoever does this, make sure to keep the commands also working for non-flycheck errors. They are very useful for e.g. org sparse trees.

[swsnr]

@StreakyCobra Flycheck's error navigation is modelled after the built-in error navigation, and I won't change that for the sake of consistency. For this reason I'll neither add a reset argument to flycheck-previous-error—the built-in previous-error doesn't have that either—nor make the command cycle among errors.

If you'd like to have backwards cycling you have to build that yourself on top of giving negative arguments to flycheck-next-error. I'd appreciate to be given an option to turn that off, though, because personally I prefer the current behaviour. I find it much more predictable.

[PierreR]

As an alternative and maybe easier approach we could have another command that cycle through errors starting from the top of the file. Most of the time I don't care where the errors are, I just want an easy way to cycle amongst them without using an extra list buffer. That might be better because we wouldn't have to change the behavior of next-error (it would jump at the start of the buffer - without recording this in the history - and then call next-error).

[PierreR]

That said, while searching, ndoes cycling so I don't really see why next-error should not ...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!