Claude/improve e 013 p fw j4v kyk jwkg4 w xr e qu1
But what about the Nim users who can use an editor invented after 1970 that can jump to the error so that we don't need these verbose code dumps to the terminal?
Sorry, i'll try making it into a cleaner PR soon.
Sorry, i'll try making it into a cleaner PR soon.
I don't want the feature though, it's hacker-news-consensus bullshit: Objectively a bad UX, but nobody dares to complain about it.
can jump to the error so that we don't need these verbose code dumps to the terminal?
Not all errors are read in an editor - many are read in CI or web and other locations where jumping isn't possible - a little bit of context usually goes a long way - from practical experience, this is very valuable
The typical CI log is overwhelming already... It's not a good feature for that either. Especially if you consider that the "context helps" argument equally applies to warnings, not just error messages.
CI log is overwhelming
the long-term way to deal with overwhelming logs is to print less on successes and more on error -then you don't need the (partial) success information to understand the error - this assumes the error provides sufficient context.
warnings
what warnings? (aka a clean codebase does not have them ..)
Objectively a bad UX, but nobody dares to complain about it.
can you elaborate? pointing on exact mismatch is quite useful info, i faced multiple times people who have problems reading current mismatch errors
But what about the Nim users who can use an editor invented after 1970 that can jump to the error so that we don't need these verbose code dumps to the terminal?
Having good error messages with line dump realy useful.
by the way, I often use neovim without lsp. And finding line from message by line number not cool
--hint:Source:on seems to exist already.
by the way, I often use neovim without lsp. And finding line from message by line number not cool
And how exactly does this context help you to navigate to the error? Using the line/col information is not ambiguous for that and the navigation can be automated. And what kind of argument is "see how I waste my time" anyway.
I just tested --hint:Source:on, it works well. Feel free to enable it in your config.
by the way, I often use neovim without lsp. And finding line from message by line number not cool
And how exactly does this context help you to navigate to the error? Using the line/col information is not ambiguous for that and the navigation can be automated. And what kind of argument is "see how I waste my time" anyway.
The source of the error is immediately visible and the eyes immediately cling to the desired line; searching for the required line number is much slower
I just tested
--hint:Source:on, it works well. Feel free to enable it in your config.
I tested it and it realy good, strange that it's not particularly documented
searching for the required line number is much slower
You are not supposed to search for it. Your editor should jump to it. Turbo Pascal in 1990 and earlier could do that.
I don't rely much on nim langserver because it creates multiple (infinite) instances of nimsuggest and make editor very slow
Hmm https://github.com/kobi2187/Nim/blob/a0c3a8cb4968f90af10932207ac4b13bd86de74e/IMPLEMENTATION_EXAMPLE.md Showing inconsistency with the proc by showing difference of arguments type is quite good.
And in general, I’d like the compiler not only to point out the error, but also to show its history and the reason why it occurred. Something like:
On line 5, you import the foo module
import foo
Then you import the bar module
import bar
After that, you call
buz()
However, this is ambiguous, because the procedure is declared in the following modules:
foo.nim:
proc buz*()
bar.nim:
proc buz*(x = 42)