Very cool! By the way, thanks for all the work you have put in to compliment.
Sometimes it's hard to know when/how to thank people. I myself am all too
often guilty of, "Thanks, can I have a new feature or bug fix?"
You, Mr. Emerick, Mr. Batsov -- and many others -- thanks!
I'd start a thank
To anyone who's interested in having precise completion for Java classes –
a feature like this is available in the latest CIDER
snapshot: https://twitter.com/unlog1c/status/1066748173094453248. You can
get a filtered completion by prepending a type tag to the next symbol.
On Friday, October 12,
I agree :-). For me the cost/benefit decision is easy -- I'm using it in a new
interop-heavy project. I posted it here in case others who used cider-nrepl
based tooling may also potentially benefit -- if enough interest maybe I'd take
the extra time to publish it as a library.
Often times I h
Comments inline...
I appreciate the discussion to date!
‐‐‐ Original Message ‐‐‐
On Saturday, October 20, 2018 10:13 AM, Colin Fleming
wrote:
>> I'm curious though, why additional macro / slightly differences from
>> "idiomatic" seems so important to avoid.
>
> I can think of a couple
>
> I'm curious though, why additional macro / slightly differences from
> "idiomatic" seems so important to avoid.
>
I can think of a couple of reasons off the top of my head:
1. It won't work with any tooling that's unaware of it, e.g. Cursive.
2. It's very verbose - it's even worse than
The cost/benefit is hard to work out. Look ahead 7 years - we would have
the ceremonial (jvm... (MyType:baz...)) in some places and the good old
elegant (.baz ...) in others, and the tooling will work just as well with
it. On the other hand, if you routinely do tons of interop with a wide
var
I love Cursive and use the IntelliJ Vim keybindings everyday. Apparently
they have alternate keybindings for those of you from the dark side.
Alan
On Wed, Oct 17, 2018 at 4:19 AM 'somewhat-functional-programmer' via
Clojure wrote:
> I appreciate your thoughtful response -- I wish some of the ot
I appreciate your thoughtful response -- I wish some of the other tooling could
do this level of analysis but I can only imagine the time it took Colin to
implement :-). Like I mentioned in my response to him -- I'm going to have to
seriously consider leaving the cult of emacs not only for Java
It's not really:
(jvm (var.method))
but
(jvm (JavaType:method var))
Because the completion engines get "JavaType:" as a prefix, they can look up
the type via reflection and present a list of methods for *just* that type.
‐‐‐ Original Message ‐‐‐
On Wednesday, October 17, 2018 4:34 AM, Di
I appreciate your detailed response, and you've certainly done great work with
Cursive. I always recommend it to any Java programmer who is starting to learn
Clojure. I will start to more seriously weigh the pros and consadditional of
switching away from emacs. The cult of emacs has had a str
Cursive already allows this with no syntax changes, but it does require
reproducing Clojure's type inference in the editor. Cursive performs this
type inference, so (modulo bugs) it knows the types of basically everything
that the Clojure compiler does (and in fact in some situations can do
better,
How does the new syntax help the tooling figure out the type?
(def var (SomeType.))
(.method var)
Or
(jvm (var.method))
I'm not sure how you narrow down to only the SomeType methods?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
This seems like it could be done using threading.
(-> "my-string"
(.ch<-- completion should give you good results here, for only
String methods
(-> (new MyType)
(.<-- completion should give you only methods of MyType
; One interesting case is the following:
(def foo "hello")
Comments inline... I really appreciate you taking the time to look at this. I
think I am still imprecise in my language -- I hope the comments below doesn't
come across as too tedious :-)...
‐‐‐ Original Message ‐‐‐
On Tuesday, October 16, 2018 7:46 PM, Timothy Baldridge
wrote:
> As
As you say, this is a limitation in the code completer. In Cursive this
problem doesn't exist to this extent, when I type `(.get` the completer
responds with a list of methods and classes that could be completed to that
method, starting with classes in the namespace I'm currently editing.
Yes, thi
Comments inline...
‐‐‐ Original Message ‐‐‐
On Tuesday, October 16, 2018 3:47 PM, 'Tatu Tarvainen' via Clojure
wrote:
> Nice. I like the syntax, I'll try it out.
Thanks -- let me know if the boot command doesn't work... I had to update boot
on one of my boxes to get it to work ("boot
I apologize for diving into a solution in my first email -- let me give a
little more of the background as to what I am trying to accomplish.
I'm proposing an additional syntax for Java interop for the purpose of allowing
support for more precise code-completion of Java fields and methods in Clo
I don't understand why this is needed. Why can't cider code complete on the
normal method format? What's the problem this code is trying to solve?
Timothy
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go
Nice. I like the syntax, I'll try it out.
But it seems unlikely to me that the interop forms would be changed in core
at this late stage.
As metadata tags can be added to symbols, could we write (^String .charAt
"test-string" 0)
It doesn't look as nice as your proposed syntax, but is possible
19 matches
Mail list logo
