Yes it does, it uses type inference to determine the return type of a function
call. This way the determination of the argument type is effect free. You could
maybe hook your package into the logic in REPLCompletion.jl in base.
Yes I was also thinking about if evaluating all other arguments is a good
idea. My first thought was about performance and the conclusion was that
when one does work interactively on the REPL, one wants to do this
evaluation anyway. There are, of course issues with mutating functions like
when
The issue here is that you have to evaluate the expression to the left of
the cursor, which could entail running arbitrary code. Which may be fine,
but we haven't taken that step yet.
On Thu, Feb 18, 2016 at 9:02 AM, Tom Breloff wrote:
> Sounds very useful! I have a scenario
I forgot to mention, this is currently targeted at julia 0.5, it needs the
new function types. It should work for nightlies.
On Thursday, February 18, 2016 at 3:23:41 PM UTC+1, Mauro wrote:
>
> > Sounds very useful! I have a scenario that probably fits... When using
> > PyCall I always find
> Sounds very useful! I have a scenario that probably fits... When using
> PyCall I always find myself pressing tab to see what methods are defined on
> a python object:
>
> "obj[:get_something]()["... Crap... Gotta look at the docs...
>
> It would be awesome if you gave a quick how-to for
Sounds very useful! I have a scenario that probably fits... When using
PyCall I always find myself pressing tab to see what methods are defined on
a python object:
"obj[:get_something]()["... Crap... Gotta look at the docs...
It would be awesome if you gave a quick how-to for something like
I want to share an (unregistered) package called CustomREPLComepletions
https://github.com/meggart/CustomREPLCompletions.jl. It hooks into the REPL
completion system and lets you add individual completions depending on the
function surrounding the current cursor.
For example, if after the