Um, no, not in a million years. I just saying maybe some convenient shortcut, other than |>, to trigger function completion could be an idea.
1 Like
idk, you need some indication of you’re trying to look for a function, so it’s either |>, or
[cursor](obj) # hit tab
I’m thinking obj[cursor], then pressing <alt-space> for example, maybe user configurable. Are there mechanisms for triggering this kind of user-configurable actions in vs code or the REPL?
too confusing… that’s some mental burden I don’t want users to suffer from. can do in a package for sure
Huh? I don’t even understand what you mean. How would this affect anyone who’s not directly interested in the functionality?
No-one needs to use this, and user-configurable shortcuts aren’t anything new. It just needs some action to hook up to.
it’s a mental burden to make user to remember “oh tab in completion in Julia but if you want to complete function you can’t just do it like 10 other language, you need to hit this specific combo of keys that literally has no other usage”
unlike |>, there’s absolutely no que for why alt-space is needed(and not, ctrl-tab?), at least |> is a pipe operation which is common and it tells julia you’re competing for function, which users can make sense of
if you only use julia and use it all the time, you might as well just remember all the functions you ever need…
1 Like
I think you are completely missing my point. If this is configurable, anyone could trigger completion whichever way they prefer. |> could very well be the default, and only those who care would go to whatever config-file to change it.
BTW, alt-space is a common way to trigger completion (e.g. intellij et al) which is why I thought of that first.
One more thing: obj |> <tab> should probably complete to obj |> foo, not foo(obj), which means the latter should be triggered differently.
Just because you remember them doesn’t mean you want to type them out fully.
1 Like
I think tab is more common than alt-space? Its tab in R studio, VS code, and very common with plugins in vim.
And tab already does completion in the Julia REPL, it’s just for everything in the namespace rather than everything that could actually be parsed and run. Reducing the length of that list in specific contexts is the improvement I’m suggesting we make.
One more thing:
obj |> <tab>should probably complete toobj |> foo, notfoo(obj), which means the latter should be triggered differently.
I agree, |> should end up as a pipe. See my post above, we could hit tab after a bracket to complete foo(obj) if it was just written like a tuple/paren (obj).
1 Like
Yes, maybe, but I’m mentioning this only because it would be useful to configure this according to one’s own preference.
For me, the problem with <tab> for this specific use is ambiguity. If I type obj<tab>, the natural choice is to complete the name obj, not look for applicable functions. obj.<tab> should complete property names. obj |> <tab> is awkward to type, and so is (obj)<tab>.
obj<alt-space> is just handy and widespread for this use, so I thought that is what I, personally, would like to configure as a trigger that deliberately acts differently from <tab>.
1 Like
Ok I get it, you would like a solution that is independent of syntax and just operates directly on the object.
That seems useful and yes it would need a separate key command.
So <alt-space> (or whatever) could complete obj to func(obj) or func(obj, _) or func(_, obj) depending on method arguments? then you could be in some kind of function mode where tab takes you to fill in the next argument if there are multiple. It could force mandatory keywords as well. I can see it getting tricky when there are a lot of method signatures.
(a reason to keep personal likes out of this and choose the “one right way” is now we would have to implement all these things…)
1 Like
I’ll take this moment to draw your attention to @DNF’s complaints that |> is awkward and error-prone to type, and ?(obj)<tab> is strange. My commentary as well.
Might I interest you fine folks in .., such as in my_object..mymethod()? Methods would appear in a dropdown menu as you type them, sorted by relevance, and you’d hit <tab> to complete the suggestion. Thing of beauty. Much wow.
Okay, so inserting the object as a first argument is still getting pushback. I’d argue this isn’t as big a deal as it’s being made out to be, and that it simply can’t be expected that all functions will be written with argument ordering that makes good use of it. But in the contexts where it matters, most methods are written with reasonable argument ordering, and the existence of a handful of poor method definitions isn’t compelling motivation to throw babies out with bathwater.
Inserting the object as a first argument, UFCS-style, seems quite reasonable. And virtually the entire world of people who write programs for a living seems to agree.
You presumably mean the entire world of people who use and prefer OOP languages? 
Anyway, my main point is that I would wish for the functionality and the triggering mechanism to be orthogonal concerns.
I am, BTWm wondering about the implementation of the interface. Looking at the ipython console, which runs in my terminal, <tab>bing brings up an interface like the below, where I can navigate with arrows keys in a popup pane, and select the alternative I like.
Trying the same in the Julia REPL, <tab>bing twice just prints out the alternatives, no navigation:
Is the ipython behaviour something that is possible to implement in the Julia REPL, or are there deeper architectural reasons why the Julia REPL apparently does not offer any such interface. I’ve seen some cool things, like TerminalMenus.jl, and Term.jl, and FoldingTrees.jl, and but nothing like the ‘popup-pane’ of ipython.
Maybe TerminalMenus.jl could be an interface, with some background coloring etc.?
1 Like
In terms of interface, GitHub - tkf/InteractiveCodeSearch.jl: Interactively search Julia code from terminal might be a decent option, but I don’t know how that’s implemented under the hood.
1 Like
There’s no reason we couldn’t have that. See e.g.
1 Like
Your idea is adding new syntax to the language, my idea is simply a plugin for the REPL that works with the status quo.
The problem being your idea is much less likely to be merged no matter what people think of it in this thread.
2 Likes
This can’t and won’t work without a breaking change to the parser, since .. already exists as a function, and binds less tightly than function calls:
julia> Meta.@dump my_object..mymethod()
Expr
head: Symbol call
args: Array{Any}((3,))
1: Symbol ..
2: Symbol my_object
3: Expr
head: Symbol call
args: Array{Any}((1,))
1: Symbol mymethod
that is, this get’s parsed as my_object..(my_method()) instead of (my_object..my_method)()
2 Likes
Indeed, naturally I’ve tried:
..(obj, meth) = (args...; kwargs...) -> meth(obj, args...; kwargs...)
And it works, sorta, except the expression ends up requiring extra parentheses:
(my_object..mymethod)(a, b, c)
which gets very awkward when chaining. Also broadcasting doesn’t work.
Anyway, is it worth defending .. from breaking changes? Is there a way to find out if anyone uses it?
Nobody is going to break compatability just to make people used to class based OO happy. It’s just not going to happen.
5 Likes
5 Likes
Why on earth is this thread still going on about major version-breaking .. changes or piping that is restricted to single-argument functions when CBOOCall.jl was already suggested in that comment? I don’t like making function names properties of a type in a non-OOP language (which is also why I consider this worse than simply inputting the first argument unusually like do-blocks), but if you’re going to do it, that looks like the way to do it. Only thing I don’t like about that package is that I still can’t tell what CBOO stands for.
1 Like