Open GoogleCodeExporter opened 9 years ago
Please consider sorting of matching results: put the names from current ns
first,
those from java - later.
Original comment by idob...@gmail.com
on 22 Mar 2010 at 12:48
Notes from cgrand (french) on java completion:
Sinon pour limiter le scope de la completion.
* définir un set des classes "possibles" référencer les classes de "base"
clojure+java
* à chaque classe nommée dans le code (heuristique gérable), l'ajouter au
set des classes
* à chaque appel de méthode, rajouter au set de classes, toutes les classes
de retours possibles pour des méthodes de ce nom
Original comment by laurent....@gmail.com
on 2 Mar 2011 at 9:08
More french notes (extracted from private email before their content gets lost):
(lpetit):
Pourquoi pas. Il faut alors descendre dans le set des classes nommées dans le
code des librairies tierces, et s'il y a des endroits où elles sont
instanciées par un new, on devrait pouvoir les retrouver effectivement (si
c'est du code qui passe par de l'indirection via factory ou autre spring
container, moins sûr ...).
Raisonnons également par cas d'utilisation. En voici quelques uns :
* je suis en train de dériver une classe abstraite d'un framework via un gen-class. J'ai toutes les chances d'avoir le bon import pour la classe abstraite dans le namespace => gagné pour récupérer les méthodes appelables de la classe parente. Peut-être une heuristique qui consisterait à ajouter les classes qui sont dans le même package pourrait être intéressante, d'ailleurs ...
* je cherche cette "pu..ain" de méthode qui s'appelle je sais plus comment mais qui contient editable dans le nom de la méthode => là je suis prêt à payer un temps un peu plus long de recherche
* je reçois d'une librairie tierce java (ou clojure d'ailleurs) un objet, et je sais qu'un "service" est disponible dessus. Si c'est une méthode java => peut etre que l'heuristique de parser le code source clojure de la librairie tierce me permettra de remonter la classe intéressante.
Original comment by laurent....@gmail.com
on 2 Mar 2011 at 9:09
same exchange (french), cgrand's answer:
Descendre dans les libs tiereces: oui et non.
Oui c'est plus précis.
Non, on regarde juste les tags des vars et on proe pour que l'utilsateur mette
un type hint dans son code lorsque la var n'est pas assez précise. Oui le
typehint est placé trop "tard" pour la 1er complétion.
Idée ! Think different think pepsi !
Et si on attendait avant de faire la complétion. Un fonctionnement un peu
façon correcteur orthographique. L'utilisateur tape un bout approx du nom de
méthode et une fois que l'on connaît le "this", on corrige ou suggère la
complétion.
D'ailleurs le correcteur sur les noms de symboles, je vote pour -- aucune idée
de comment l'impélmenter pour pas foutre tt en l'air avec les locales.
Original comment by laurent....@gmail.com
on 2 Mar 2011 at 9:10
Original comment by laurent....@gmail.com
on 5 May 2011 at 8:50
Original comment by laurent....@gmail.com
on 30 Dec 2011 at 9:19
Original comment by laurent....@gmail.com
on 5 Jul 2012 at 2:27
Original comment by laurent....@gmail.com
on 26 Jul 2012 at 9:24
Original comment by laurent....@gmail.com
on 6 Sep 2012 at 10:59
I would appreciate a "Clojure Cheatsheet" +Auto-Completion Feature.
with could be based on the clojuredocs-QuickRef or the Cheatsheet or probably
for me the most interesting, a map (or a file) which i could manipulate myself,
to make it fit my personal needs
For e.g. if I press Ctrl+Space -> get a list with Topics:
Like
nm - Number Manipulation
cc - Collection Creation
cm - Collection Manipulation
.s - clojure.string
... and so on
then I would type cc ( for Collection Create) I would get the normal
AutoCompletion-List (with docs) from the most common functions for creating any
kind of collection:
like:
list
set
sorted-set
zipmap
hash-map
.. and so on
Original comment by erne.ste...@gmail.com
on 11 Nov 2013 at 7:21
Original issue reported on code.google.com by
laurent....@gmail.com
on 9 Dec 2009 at 3:37