Nim icon indicating copy to clipboard operation
Nim copied to clipboard

Claude/improve e 013 p fw j4v kyk jwkg4 w xr e qu1

Open kobi2187 opened this issue 1 month ago • 7 comments

kobi2187 avatar Nov 23 '25 11:11 kobi2187

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?

Araq avatar Nov 23 '25 11:11 Araq

Sorry, i'll try making it into a cleaner PR soon.

kobi2187 avatar Nov 23 '25 12:11 kobi2187

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.

Araq avatar Nov 24 '25 07:11 Araq

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

arnetheduck avatar Nov 24 '25 07:11 arnetheduck

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.

Araq avatar Nov 24 '25 07:11 Araq

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

arnetheduck avatar Nov 24 '25 07:11 arnetheduck

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

blackmius avatar Nov 24 '25 07:11 blackmius

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.

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

by the way, I often use neovim without lsp. And finding line from message by line number not cool

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

--hint:Source:on seems to exist already.

Araq avatar Dec 13 '25 16:12 Araq

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.

Araq avatar Dec 13 '25 16:12 Araq

I just tested --hint:Source:on, it works well. Feel free to enable it in your config.

Araq avatar Dec 13 '25 16:12 Araq

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

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

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

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

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.

Araq avatar Dec 13 '25 16:12 Araq

I don't rely much on nim langserver because it creates multiple (infinite) instances of nimsuggest and make editor very slow

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

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.

ASVIEST avatar Dec 13 '25 16:12 ASVIEST

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)

ASVIEST avatar Dec 13 '25 17:12 ASVIEST