mawww / kakoune

mawww's experiment for a better code editor
http://kakoune.org
The Unlicense
9.7k stars 705 forks source link

[BUG] cannot use <ret> in *lint-output* buffer #5168

Open lobre opened 2 months ago

lobre commented 2 months ago

Version of Kakoune

1c71fc0c097f14ba857936fb56253c65abbb62d6

Reproducer

Just set a lintcmd, run the linter with :lint, and from the *lint-output* buffer, try to use <ret> to jump.

Outcome

Here is the error that gets appended to the *debug* buffer:

error running hook NormalKey(<ret>)/make-hooks: 1:1: 'make-jump': 2:5: 'evaluate-commands': 2:9: 'evaluate-commands': 3:13: 'try': 3:17: 'execute-keys': nothing selected

Expectations

I guess this is due to the recent abstraction made to jump commands in stdlib.

Additional information

No response

krobelus commented 2 months ago

I can't reproduce a regression. Probably you expect the filetype=grep style behavior where every line is a valid location. Lint output (for better or worse) has forever used filetype=make where make_error_pattern determines what's a valid location (for next/prev but also for jump)

For example here the first one is matched but the second one isn't:

src/main.cc:100:9: error: expected ‘}’ before string constant
  100 |         "» {+u}User{} hook support\n"
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/main.cc:97:8: note: to match this ‘{’
   97 |     }, {
      |        ^

It's possible that we want to relax this (perhaps only for the jump command). I personally have a dedicated shortcut which has some drawbacks I guess The expectation for lint.kak are not very easily defined

lobre commented 1 month ago

You are absolutely right. I was sure that I was in a buffer with filetype=grep.

My current linting error was:

main.go:5:6: main redeclared in this block

And effectively, it does not match with the make_error_pattern. If I manually change the line to:

main.go:5:6: error: main redeclared in this block

It now works. So my bad, this is not a bug.

But as you say, maybe this rule could be relaxed effectively. It might not be necessary to have that level of precision for the jump.

Should I close this issue and this could be tracked elsewhere?