Julia: Custom REPL/IDE completion rules for specific types

Created on 27 Sep 2019  路  1Comment  路  Source: JuliaLang/julia

This stems from a feature request at https://github.com/JuliaData/DataFrames.jl/issues/1965. It would be nice to allow defining custom completion rules for functions based on the types of the first arguments that have been typed. A good example of this is groupby(df, key) in DataFrames: when the user types groupby(df,[TAB], we would like the REPL or the IDE to show the list of columns in the data frame (just like what happens with df.[TAB] thanks to propertynames).

A simple implementation of this would be to have the REPL define a function like complete_nextargs that it would call like this: complete_nextargs(f, firstargs). DataFrames would add methods to that function retuning possible values for the next argument, e.g. REPL.complete_nextargs(::typeof(groupby), firstargs::Tuple{AbstractDataFrame}) = names(firstargs[1]). Of course that wouldn't work if several packages want to define completions for the same type of the first argument (i.e. there would be ambiguities). But at least for types that are owned by the package it would be OK (that's the most common case I guess).

This mechanism would more generally be very useful for enum-like arguments passed as symbols, e.g. r2(model, :McFadden) in StatsBase.

REPL

Most helpful comment

Of course that wouldn't work if several packages want to define completions for the same type of the first argument

I understand it would work, but would depend on the package load order (i.e. the last loaded package would overwrite the method for complete_nextargs for this type in the worst case).

I think it should be acceptable, as the case when this happens should be rare (and technically involve type piracy), especially, as firstargs will probably contain types defined by the package in most cases.

>All comments

Of course that wouldn't work if several packages want to define completions for the same type of the first argument

I understand it would work, but would depend on the package load order (i.e. the last loaded package would overwrite the method for complete_nextargs for this type in the worst case).

I think it should be acceptable, as the case when this happens should be rare (and technically involve type piracy), especially, as firstargs will probably contain types defined by the package in most cases.

Was this page helpful?
0 / 5 - 0 ratings