Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REPLCompletions] follow up #43865, keep input tuple type in MethodCompletion #43946

Merged
merged 1 commit into from
Jan 28, 2022

Conversation

aviatesk
Copy link
Member

MethodCompletion.tt is being used by an external consumer like Juno or
VSCode's runtime completion features to get additional information like
return type, etc.

@aviatesk aviatesk requested a review from vtjnash January 27, 2022 07:36
@@ -515,20 +517,20 @@ function get_type(T, found::Bool, default_any::Bool)
end

# Method completion on function call expression that look like :(max(1))
MAX_METHOD_COMPLETIONS = 40
const MAX_METHOD_COMPLETIONS = Ref(40)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? this just adds more overhead

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we configure this value, it feels "better" if we can do REPL.REPLCompletions.MAX_METHOD_COMPLETIONS[] = 100 instead of @eval REPL.REPLCompletions MAX_METHOD_COMPLETIONS = 100.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not really configurable. It is a function argument though, if desired.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we basically need to copy and paste the definitions of complete_methods etc. If it's not really supposed to be configured, we should probably make it const.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because we make it less convenient to change, does not mean we have to make it const

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If people eventually do need to change it regularly, this will let them try out the idea, then add a contextual parameters object to this code to encapsulate any configurations of interest

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotcha, let's just remove this change.

…ompletion`

`MethodCompletion.tt` is being used by an external consumer like Juno or
VSCode's runtime completion features to get additional information like
return type, etc.

Co-Authored-By: Jameson Nash <[email protected]>
@aviatesk aviatesk merged commit 78b7d76 into master Jan 28, 2022
@aviatesk aviatesk deleted the avi/follow43865 branch January 28, 2022 00:44
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Feb 22, 2022
… `MethodCompletion` (JuliaLang#43946)

`MethodCompletion.tt` is being used by an external consumer like Juno or
VSCode's runtime completion features to get additional information like
return type, etc.
LilithHafner pushed a commit to LilithHafner/julia that referenced this pull request Mar 8, 2022
… `MethodCompletion` (JuliaLang#43946)

`MethodCompletion.tt` is being used by an external consumer like Juno or
VSCode's runtime completion features to get additional information like
return type, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants