RFC: add and and or suggestions to UndefVarError, per #37469#40545
RFC: add and and or suggestions to UndefVarError, per #37469#40545oscardssmith merged 1 commit intomasterfrom
and and or suggestions to UndefVarError, per #37469#40545Conversation
|
Should this also reference |
stdlib/REPL/src/REPLCompletions.jl
Outdated
| return Completion[], 0:-1, false | ||
| end | ||
|
|
||
| Base.Experimental.register_error_hint(UndefVarError) do io, ex |
There was a problem hiding this comment.
Any reason to put this into the REPL stdlib, whereas e.g. the noncallable number hint is in base? Either seems fine, but I think it would be good to be consistent about this.
There was a problem hiding this comment.
I want it to be unavailable if REPL isn't loaded, since that lets us do more advanced things here (though I should perhaps move it to __init__)
There was a problem hiding this comment.
Should we move the noncallable number one here as well then?
There was a problem hiding this comment.
I'm not entirely sure. On the one hand, we want the default experience to have good errors, even on CI. On the other hand, we don't want to encumber the runtime with complicated error messages that aren't needed, even on CI.
There was a problem hiding this comment.
Since these hint are really only intended for beginners, I would lean towards having them defined by the REPL. Users contributing to packages and looking at CI probably don't benefit much from them.
Co-authored-by: Jerry Ling <proton@jling.dev>
|
@oscardssmith I think there's many possible additions. The goal for this PR was to merge a minimal set, then let others help improve the list. |
|
triage approves. |
|
Was ist discussed whether this should live in the REPL stdlib or in Base? |
|
I guess this is ok but it doesn't work for infix: I think the reason to put this in the repl is that we'd eventually like all interactive, convenient kinds of stuff to be there. This one is a small amount of code, but the full set of error printing logic is pretty complex, and shouldn't be mandatory for all programs. Until then though, the inconsistency may not be worth it. |
Co-authored-by: Jerry Ling <proton@jling.dev> Co-authored-by: Jerry Ling <proton@jling.dev>
Co-authored-by: Jerry Ling <proton@jling.dev> Co-authored-by: Jerry Ling <proton@jling.dev>
Replaces #37471 and closes #37469. In the future, I envision this list becoming much longer, with completions based upon context and spell-checking (either here, or perhaps somewhere like OhMyRepl). But testing this out first to see whether others agree this is a good approach.
Co-authored-by: Jerry Ling (@Moelf)